From nobody Wed Apr 1 07:07: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 391DE1A8A11 for ; Wed, 1 Apr 2015 07:07:54 -0700 (PDT) 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 UvHNgG7KPHYx for ; Wed, 1 Apr 2015 07:07:49 -0700 (PDT) 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 37A241A9170 for ; Wed, 1 Apr 2015 07:07:47 -0700 (PDT) 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 t31E7jtw031136 for ; Wed, 1 Apr 2015 16:07:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B5DBF204892 for ; Wed, 1 Apr 2015 16:08:38 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AE147204863 for ; Wed, 1 Apr 2015 16:08:38 +0200 (CEST) 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 t31E7baw003892 for ; Wed, 1 Apr 2015 16:07:44 +0200 Message-ID: <551BFBA9.5070103@gmail.com> Date: Wed, 01 Apr 2015 16:07:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> In-Reply-To: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2015 14:07:54 -0000 Le 31/03/2015 07:35, Fred Baker (fred) a écrit : [...] > 1) IPv4-only network > 2) IPv4 with bits of IPv6 here and there, in some combination of overlay and native > 3) IPv4+IPv6 (native) dual stack network > 4) IPv6+IPv4 non-native, translated or overlay (e.g., as a service) > 5) IPv6 with little bits of IPv4 here and there; your printer might be an example > 6) IPv6-only Makes sense. These are qualifiers for networks. One would try to fit in the computers as well, as the printer example. It is customary to see current computers having both an IPv6 stack and an IPv4 stack on them. But some computers only have IPv4, whereas the rest have IPv4 and IPv6 stacks. There are no computers (to my knowledge) which have only IPv6 stacks. Recently we noticed a cellular end-user device which can work only in IPv6 mode, or only in IPv4 mode. But it can not have both an IPv4 address and an IPv6 address on it even though the network to which it connects offers it both simultaneously on same APN. > > In steps 1 and 2, it is an IPv4 network, possibly with some toys in > it playing IPv6. We might have toys playing AppleTalk and DECNet too. > IPv4 is the workhorse, and toys is toys. > > In step 3, every host in the network has an IPv4 address and an IPv6 > address, or constructively could have if it wants one, and every > router is carrying IPv4 routing as well as IPv6 routing. It’s likely > multiplexing IPv4 addresses, and IPv4 is increasingly broken. But the > big question is what applications and providers support IPv6; as long > as a big one (Skype?) is not making the transition, people have a > business reason to keep IPv4 going. As applications become dual > stack, traffic levels approach a 50/50 distribution, barring some > specific reason they would be forced to IPv4 or IPv6. > > Right now, most networks are still in step 1, and those that have a > clue are somewhere between step 2 and step 3. But some are moving, or > at least experimenting, with step 4. I agree. > steps 4-6 are fundamentally about an IPv6 network. I agree, we're not there yet. > In step 4, the network is optimizing configurations and costs by > making IPv4 a translation or an overlay, but IPv4 remains an > important aspect of the network. Obvious examples include anything > listed. IPv4 might reach the host one way or another, or be > translated some distance away, but a client using IPv4 can reach an > IPv4-only server, and it can reply, and part of the path in between > is IPv6-only. > > In step 5, IPv4 has taken a place comparable to AppleTalk; yes, > there’s some there, but where, precisely? And in step 6, we have > finally turned IPv4 off entirely, and with it probably Bisync and > X.25. > > > Now, what assumptions am I making? I believe that an IPv4 packet can > make it end to end until step 5; it might spend part of that as a > translated IPv6 packet or in a tunnel of some kind, but it can get > there. As of step 5, that is no longer the case. Exactly how that > happens is Not My Department. Note that many core networks don’t > describe themselves as IPv4, IPv6, or dual stack networks; they > describe themselves as MPLS networks that carry IP as a payload. > > > Listing LISP... to me, LISP is yet another encapsulation, a tunnel > broker, and one that is particularly complex. It can carry IPv6 > across an IPv4 network or IPv4 over an IPv6 network. Someone > suggested it should be on the list, and it’s on the list. One thing I > actually expect is that the list of technologies we might invite > deployment reports regarding is longer than the list of technologies > people actually use. We might learn something from that. Makes sense. Alex > > > Is anyone’s head exploding yet? > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Apr 1 10:55: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 4E2AF1A1A8E for ; Wed, 1 Apr 2015 10:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTsC8Ez6N5Jr for ; Wed, 1 Apr 2015 10:55:24 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A271A1B0E for ; Wed, 1 Apr 2015 10:55:06 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3528225D3AFE; Wed, 1 Apr 2015 17:55:04 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 845F8C76FDF; Wed, 1 Apr 2015 17:55:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id YyNlGHG8U07q; Wed, 1 Apr 2015 17:55:02 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:506d:b975:b923:4d27] (unknown [IPv6:fde9:577b:c1a9:4410:506d:b975:b923:4d27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 477DBC76FD3; Wed, 1 Apr 2015 17:55:02 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Bjoern A. Zeeb" In-Reply-To: <551BFBA9.5070103@gmail.com> Date: Wed, 1 Apr 2015 17:54:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4A8F9E83-B481-44FC-AD70-BFFF43EC2614@lists.zabbadoz.net> References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2015 17:55:26 -0000 > On 01 Apr 2015, at 14:07 , Alexandru Petrescu = wrote: >=20 > It is customary to see current computers having both an IPv6 stack and = an IPv4 stack on them. But some computers only have IPv4, whereas the = rest have IPv4 and IPv6 stacks. There are no computers (to my = knowledge) which have only IPv6 stacks. One of my desktop systems does (not have IPv4 support anymore; and to my = knowledge you can just disable it on Windows as well, so it=92s not a = big deal anymore). =97=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From nobody Wed Apr 1 16:30: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 2C7D81ACD23 for ; Wed, 1 Apr 2015 16:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 MNd_sBU58e81 for ; Wed, 1 Apr 2015 16:30:46 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 3E9411ACD0A for ; Wed, 1 Apr 2015 16:30:46 -0700 (PDT) Received: by obbec2 with SMTP id ec2so103333720obb.3 for ; Wed, 01 Apr 2015 16:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WSwaltLl3GoqpwcBwe/Ea3AHsZ6RnQOB2EL2HXbRuR4=; b=IVN1i/hXhTF4dYrm392rKYCzOzMyWnyJgKkCLbV09Mc/jG9TuS4qfspRK26/B5HfTs 9rZ3FwoP9aHrvyDmdCZcqQsEY/pR6Sh0KTNB4WZQbMD9ad0NPeBTqzj66zxCLUsJexjN q+zmMNK/Ad3/1pJBzDJjZVqcB4j91q2gEqWB4= 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=WSwaltLl3GoqpwcBwe/Ea3AHsZ6RnQOB2EL2HXbRuR4=; b=HPcDPKCDq1OmA01EpzRcKYkn9rXASmNe9q051K+IzaEnHJ2Kpx8PnCY3MOuzMPMhdm Vhf9n2gsLcytWZpMuIxU42grPomPpGTL4xeHJEU0HbPP3fgUDbjD8W4f1FwVCNeCUbYM FDfjw7uiKBhCcJrAiwJtovcwelIPr52uUv8VAlrCR/PCsZkNcO/jjAJrRdeQMXWd45fg rrPlcImhpRwiKOZu2Q5afJdG5iFC7EKMLxEM/UmANk7iEmo+PKGVmpb9CdDDdMA3jha6 CgudYvVZkcSHoLPazgdBZIiU6V+gLccM8Xzc721rNC91i8O36jiVsEl5Z3tOrvPW/yrN 6J3w== X-Gm-Message-State: ALoCoQn/+GQ9JC7NSH9VCS6+PDNgn6UdWVylznEx+KHsIaUu/qf++TQU0HpVGYl7zEhTHpp8scTV MIME-Version: 1.0 X-Received: by 10.182.88.136 with SMTP id bg8mr43660073obb.86.1427931045685; Wed, 01 Apr 2015 16:30:45 -0700 (PDT) Received: by 10.76.177.229 with HTTP; Wed, 1 Apr 2015 16:30:45 -0700 (PDT) In-Reply-To: <551BFBA9.5070103@gmail.com> References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> Date: Wed, 1 Apr 2015 18:30:45 -0500 Message-ID: From: James Woodyatt To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=089e0111bd76be05e10512b21a32 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Apr 2015 23:30:47 -0000 --089e0111bd76be05e10512b21a32 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 1, 2015 at 9:07 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > > It is customary to see current computers having both an IPv6 stack and an > IPv4 stack on them. But some computers only have IPv4, whereas the rest > have IPv4 and IPv6 stacks. There are no computers (to my knowledge) which > have only IPv6 stacks. > Sigh. Computing platforms where the only network interfaces are 6LoWPAN-over-foo. These exist today, and they are not just laboratory toys. -- james woodyatt Nest Labs, Communications Engineering --089e0111bd76be05e10512b21a32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 1, 2015 at 9:07 AM, Alexandru Petrescu <alexandru.petre= scu@gmail.com> wrote:

It is customary to see current computers having both an IPv6 stack and an I= Pv4 stack on them.=C2=A0 But some computers only have IPv4, whereas the res= t have IPv4 and IPv6 stacks.=C2=A0 There are no computers (to my knowledge)= which have only IPv6 stacks.

Sigh. Computing pla= tforms where the only network interfaces are 6LoWPAN-over-foo. These exist = today, and they are not just laboratory toys.


--
<= div dir=3D"ltr">james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engine= ering
--089e0111bd76be05e10512b21a32-- From nobody Wed Apr 1 23:12: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 2D4451A92E6; Wed, 1 Apr 2015 23:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePFvS3UqYwPB; Wed, 1 Apr 2015 23:12:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2481B1B2B0C; Wed, 1 Apr 2015 23:12:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150402061214.15422.67238.idtracker@ietfa.amsl.com> Date: Wed, 01 Apr 2015 23:12:14 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-07.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, 02 Apr 2015 06:12:17 -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 : Some Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-07.txt Pages : 17 Date : 2015-04-01 Abstract: This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-07 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 Apr 1 23:14: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 D7A341B2B0C for ; Wed, 1 Apr 2015 23:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.181 X-Spam-Level: X-Spam-Status: No, score=0.181 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.982] 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 jnBK1nWC2jRD for ; Wed, 1 Apr 2015 23:14:46 -0700 (PDT) Received: from tor-smtp-02.primus.ca (dsl-67-230-159-6.tor.primus.ca [67.230.159.6]) by ietfa.amsl.com (Postfix) with ESMTP id BB7901A92E6 for ; Wed, 1 Apr 2015 23:14:46 -0700 (PDT) Received: from [179.218.242.119] (helo=philips-macbook.vexwifi.com.br) by tor-smtp-02.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1YdYOr-0007Rg-Qy; Thu, 02 Apr 2015 02:14:46 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20150402061214.15422.67238.idtracker@ietfa.amsl.com> Date: Thu, 2 Apr 2015 02:14:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <537BD385-1316-4908-B94A-0BEF35CC63F9@magma.ca> References: <20150402061214.15422.67238.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - (philips-macbook.vexwifi.com.br) [179.218.242.119] Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-07.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, 02 Apr 2015 06:14:48 -0000 Hi Folks: This new version uses the term "link-local-only" for interfaces with = only link-local addresses, as discussed on the mailing list and in the = Dallas session. - Philip On 2015-04-02, at 2:12 , 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 : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-07.txt > Pages : 17 > Date : 2015-04-01 >=20 > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around = IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Apr 1 23:36: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 0CC9D1B2B29 for ; Wed, 1 Apr 2015 23:36:55 -0700 (PDT) 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 8T-UIjiIWprt for ; Wed, 1 Apr 2015 23:36:53 -0700 (PDT) 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 027721B2B28 for ; Wed, 1 Apr 2015 23:36:52 -0700 (PDT) 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 t326aoeC027338; Thu, 2 Apr 2015 08:36:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AA09C205BE6; Thu, 2 Apr 2015 08:37:45 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9D016200DF0; Thu, 2 Apr 2015 08:37:45 +0200 (CEST) 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 t326aQUJ021228; Thu, 2 Apr 2015 08:36:50 +0200 Message-ID: <551CE36A.50706@gmail.com> Date: Thu, 02 Apr 2015 08:36:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> <4A8F9E83-B481-44FC-AD70-BFFF43EC2614@lists.zabbadoz.net> In-Reply-To: <4A8F9E83-B481-44FC-AD70-BFFF43EC2614@lists.zabbadoz.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 06:36:55 -0000 Sorry to insist on this, just as side note. Le 01/04/2015 19:54, Bjoern A. Zeeb a écrit : >> On 01 Apr 2015, at 14:07 , Alexandru Petrescu >> wrote: >> >> It is customary to see current computers having both an IPv6 stack >> and an IPv4 stack on them. But some computers only have IPv4, >> whereas the rest have IPv4 and IPv6 stacks. There are no >> computers (to my knowledge) which have only IPv6 stacks. > > One of my desktop systems does (not have IPv4 support anymore; In general I can agree with you, in a sense where maybe a computer is not reachable on IPv4 from another computer; maybe part of IPv4 support is no more there. > and to my knowledge you can just disable it on Windows as well, Right - uncheck the IPv4 box, and check IPv6 on a computer Windows 7's "Properties" of the network interface - it works. But, after this, one can still ping 127.0.0.1, the routing table still contains pure IPv4 entries, the domain name (which only exists in IPv4) is still showing in ipconfig /all, the computer is still receiving TCP and TLSv1 re-transmissions from its earlier connections. Worse, the IPv4-only applications report errors which are not explicitely telling there is no such address family. I guess even netsh interface ipv4 add address will work ok. (compared to an IPv4-only computer: routing table does not show anything making think IPv6, etc.) I guess unchecking the IPv4 box simply removes IPv4 addresses from interfaces and stops the DHCP client, maybe puts the interface down; but it will not remove the IPv4 stack from the kernel, will not ARP inform the router it has no more IPv4, will not recompile the apps to remove the IPv4-only socket interfaces, will not forbid adding manually IPv4 addresses. > so it’s not a big deal anymore). I beg to differ, as I see it this is still far away from an ideal where only IPv6 were present in the computer. Alex > > — Bjoern A. Zeeb Charles Haddon > Spurgeon: "Friendship is one of the sweetest joys of life. Many > might have failed beneath the bitterness of their trial had they > not found a friend." > > > From nobody Wed Apr 1 23:43: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 B0E611B2B30 for ; Wed, 1 Apr 2015 23:43:50 -0700 (PDT) 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 qoAmjGS1LrVv for ; Wed, 1 Apr 2015 23:43:48 -0700 (PDT) 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 93DD61B2B28 for ; Wed, 1 Apr 2015 23:43:48 -0700 (PDT) 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 t326hkXv014132; Thu, 2 Apr 2015 08:43:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 61E8C205C9E; Thu, 2 Apr 2015 08:44:41 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4C895205C4C; Thu, 2 Apr 2015 08:44:41 +0200 (CEST) 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 t326haGI009118; Thu, 2 Apr 2015 08:43:46 +0200 Message-ID: <551CE518.7040202@gmail.com> Date: Thu, 02 Apr 2015 08:43:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: James Woodyatt References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 06:43:50 -0000 Le 02/04/2015 01:30, James Woodyatt a écrit : > On Wed, Apr 1, 2015 at 9:07 AM, Alexandru Petrescu > > > wrote: > > > It is customary to see current computers having both an IPv6 stack > and an IPv4 stack on them. But some computers only have IPv4, > whereas the rest have IPv4 and IPv6 stacks. There are no computers > (to my knowledge) which have only IPv6 stacks. > > > Sigh. Computing platforms where the only network interfaces are > 6LoWPAN-over-foo. These exist today, and they are not just laboratory > toys. Right, this is something that deserves consideration. I wonder though whether they are directly connectable to the Internet. Last time I checked a 6lowpan IPv6-only computer it was a reduced IPv6 - one had to go through a form of middle-box to reach it. E.g. one wouldnt ssh into a 6lowpan device, would not manage it directly, but would need a CoAP gw, or a PC attached with USB to be on it. But I will ask around to see the current situation. Alex > > > -- james woodyatt > Nest > Labs, Communications Engineering From nobody Thu Apr 2 01:01: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 6CE5A1B2BD3 for ; Thu, 2 Apr 2015 01:01:49 -0700 (PDT) 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 Oa-GerhmBxQf for ; Thu, 2 Apr 2015 01:01:47 -0700 (PDT) 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 B2F371B2BD1 for ; Thu, 2 Apr 2015 01:01:47 -0700 (PDT) Received: from mb-aye.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3281kWS044083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 08:01:47 GMT (envelope-from joelja@bogus.com) To: Philip Matthews , v6ops list references: <20150402061214.15422.67238.idtracker@ietfa.amsl.com> <537BD385-1316-4908-B94A-0BEF35CC63F9@magma.ca> From: joel jaeggli message-id: <551CF763.6040706@bogus.com> Date: Thu, 2 Apr 2015 01:01:39 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0 mime-version: 1.0 in-reply-to: <537BD385-1316-4908-B94A-0BEF35CC63F9@magma.ca> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qJUxjHc4I6Jf54hf444GP0aBPDt961NdH" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-07.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, 02 Apr 2015 08:01:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qJUxjHc4I6Jf54hf444GP0aBPDt961NdH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/1/15 11:14 PM, Philip Matthews wrote: > Hi Folks: >=20 > This new version uses the term "link-local-only" for interfaces with on= ly link-local addresses, as discussed on the mailing list and in the Dall= as session. Cool, thankss for closing out that line of discussion. > - Philip >=20 > On 2015-04-02, at 2:12 , Internet-Drafts@ietf.org wrote: >=20 >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the IPv6 Operations Working Group of the = IETF. >> >> Title : Some Design Choices for IPv6 Networks >> Authors : Philip Matthews >> Victor Kuarsingh >> Filename : draft-ietf-v6ops-design-choices-07.txt >> Pages : 17 >> Date : 2015-04-01 >> >> Abstract: >> This document presents advice on certain routing-related design >> choices that arise when designing IPv6 networks (both dual-stack and= >> IPv6-only). The intended audience is someone designing an IPv6 >> network who is knowledgeable about best current practices around IPv= 4 >> network design, and wishes to learn the corresponding practices for >> IPv6. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-07 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --qJUxjHc4I6Jf54hf444GP0aBPDt961NdH 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 iEYEARECAAYFAlUc92QACgkQ8AA1q7Z/VrKL6gCdHMbMixqerfpcNiW5TeX6zCDH 9yMAn0MMnQkN02lzec73fi2xD7G/rFop =oiDZ -----END PGP SIGNATURE----- --qJUxjHc4I6Jf54hf444GP0aBPDt961NdH-- From nobody Thu Apr 2 01:32: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 A108B1A8AA9 for ; Thu, 2 Apr 2015 01:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 QvtD8b0dQM-W for ; Thu, 2 Apr 2015 01:31:57 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDFD51A0089 for ; Thu, 2 Apr 2015 01:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1427963516; bh=EdvpEk3iVCRKvZsxWLnnVzPHdRytGHImk7i+feFGsYU=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=OLIeDdu0hJET4KCsYUwgq/adlmPtzbBFkZoJbkt85f6BIuDUxeFdEwfmHYrsk9Qliglp8eVrmrBe2JNh30ffkivWMagG+9cVhlt3I0tLhHJ4GErapLJ4pvYdhAi0AhOviGYTQmM0xmU4Eq7P+lzLJfp0VKl+aHNahGeRgYXvG2HizHy7FdPOVL/UXdQUSYeumPCBo1h1V3PYkM4jDvMGIt/Kh2ZD3qujL+Sx9G73l64zob/trTiEyQvAxCestcgZEC/i16qg0VVXu5tC/MEucHKyvUXAJjVUICeU9l9Rn6o/kxbpqdBggwugKdJjsAxRpA1IM6jV2Oa6fXEXV6Y51Q== Received: from [98.139.215.141] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 08:31:56 -0000 Received: from [98.139.212.208] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 08:30:56 -0000 Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 08:30:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 121771.26053.bm@omp1017.mail.bf1.yahoo.com X-YMail-OSG: sBPXHGUVM1nuvTNF97P0teI1PshIf5wo8RVzNTWgpcuUWdpz8UzgcVTrK4s5KRg comYZ0vObSWxbSElZHNT.rZcpQQA1.Iz86vA6sVA5e7d4LhzIJtG19gbADzB0z6sHUbsXNqd3CrU efXkXLA1Cj9ifwo1tOyDHlg1frl._3S93Tt_8ZX2GUZgaaiO8jc9bONtIHcd4vtB6q9YtC_wsWYQ bpiGlqMUTf0EtmBSgqGXdWhsne4ux6oM_sH5s_VLvVlvMQapkuKoN6m3FvkzEJI02V9hBTSR64ce 5xUXpewRAnP1.Qa70LE4nvPGyf8Ro1IykF0EDj6hniGsl2CiQnvIanPv_5htO4GsR1DM9gyKq8_l vyhjrTna2LNUTNHEOWWybyqaQkG_n585CpTRgZ2v9NdC_kfGmF_LmLTEUCiKyg62dzyWS0NV5UZN ZnOlGhj0DJW29eHwjg8E8RsPbI2DbUiwO6BI9_0yqgp3rq7DUCp5Ctwy1OBKNCOUQUOhktXf1LwN rb4ByNRfls_MLBcvl9A-- Received: by 66.196.80.122; Thu, 02 Apr 2015 08:30:55 +0000 Date: Thu, 2 Apr 2015 08:30:52 +0000 (UTC) From: Mark ZZZ Smith To: joel jaeggli , Philip Matthews , v6ops list Message-ID: <1610390380.4245722.1427963452305.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <551CF763.6040706@bogus.com> References: <551CF763.6040706@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4245721_1757973193.1427963452299" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 08:31:58 -0000 ------=_Part_4245721_1757973193.1427963452299 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, thanks very much. From: joel jaeggli To: Philip Matthews ; v6ops list =20 Sent: Thursday, 2 April 2015, 19:01 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-07.txt =20 On 4/1/15 11:14 PM, Philip Matthews wrote: > Hi Folks: >=20 > This new version uses the term "link-local-only" for interfaces with only= link-local addresses, as discussed on the mailing list and in the Dallas s= ession. Cool, thankss for closing out that line of discussion. > - Philip >=20 > On 2015-04-02, at 2:12 , Internet-Drafts@ietf.org wrote: >=20 >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the IPv6 Operations Working Group of the IE= TF. >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Som= e Design Choices for IPv6 Networks >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Philip M= atthews >>=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=A0 Victor Kuarsingh >> =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-v6op= s-design-choices-07.txt >> =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 17 >> =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-= 04-01 >> >> Abstract: >>=C2=A0 This document presents advice on certain routing-related design >>=C2=A0 choices that arise when designing IPv6 networks (both dual-stack a= nd >>=C2=A0 IPv6-only).=C2=A0 The intended audience is someone designing an IP= v6 >>=C2=A0 network who is knowledgeable about best current practices around I= Pv4 >>=C2=A0 network design, and wishes to learn the corresponding practices fo= r >>=C2=A0 IPv6. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-07 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 > _______________________________________________ > 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 ------=_Part_4245721_1757973193.1427963452299 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, thanks very much.

From: joel jaeggli= <joelja@bogus.com>
To: Philip Matthews <philip_matthews@magma.ca>; v6ops list <v6= ops@ietf.org>
Sent: Thursday, 2 April 2015, 19:01
S= ubject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-= 07.txt

On 4/1/15 11:14 PM, Philip Matthews wrote:
> Hi Folks:
>
> Th= is new version uses the term "link-local-only" for interfaces with only lin= k-local addresses, as discussed on the mailing list and in the Dallas sessi= on.

Cool, thankss for closing out that= line of discussion.




= > - Philip
>
> On 2015-04-02,= at 2:12 , Internet-Drafts@ietf.org wrote:<= br clear=3D"none">>
>>
>&g= t; A New Internet-Draft is available from the on-line Internet-Drafts direc= tories.
>> This draft is a work item of the IPv6 Op= erations Working Group of the IETF.
>>
>>        Title        =   : Some Design Choices for IPv6 Networks
>>&= nbsp;       Authors        : Philip Mat= thews
>>            &= nbsp;             Victor Kuarsingh
>>     Filename        := draft-ietf-v6ops-design-choices-07.txt
>>  &n= bsp;  Pages          : 17
= >>     Date            := 2015-04-01
>>
>> Abstract:=
>>  This document presents advice on certain= routing-related design
>>  choices that aris= e when designing IPv6 networks (both dual-stack and
>&= gt;  IPv6-only).  The intended audience is someone designing an = IPv6
>>  network who is knowledgeable about b= est current practices around IPv4
>>  network= design, and wishes to learn the corresponding practices for
>>  IPv6.
>>
>= >
>> The IETF datatracker status page for this d= raft is:
>> htt= ps://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/
>>
>> There's also a htmlized versi= on available at:
>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07
>>
>> A diff from the previous vers= ion is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-cho= ices-07
>>
>>
>> Please note that it may take a couple of minutes from th= e 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/<= br clear=3D"none">>>
>> _____________________= __________________________
>> v6ops mailing list>> v6ops@ietf.org
>&= gt; https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _________= ______________________________________
> v6ops mailing= list
> v6ops@ietf.org
&= gt; https://www.ietf.org/mailman/listinfo/v6ops
>


______________________________________= _________
v6ops mailing list
= v6ops@ietf.org
https://www.ietf.org/mai= lman/listinfo/v6ops
------=_Part_4245721_1757973193.1427963452299-- From nobody Thu Apr 2 04:04:52 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 BB3571A8A4B for ; Thu, 2 Apr 2015 04:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08MXi2PFMssu for ; Thu, 2 Apr 2015 04:04:48 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8696F1A1B47 for ; Thu, 2 Apr 2015 04:04:48 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5F96325D3A8F; Thu, 2 Apr 2015 11:04:46 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id AE0CAC770C8; Thu, 2 Apr 2015 11:04:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id p75db9zCCeru; Thu, 2 Apr 2015 11:04:43 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AA0F9C76FDC; Thu, 2 Apr 2015 11:04:43 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Bjoern A. Zeeb" In-Reply-To: <551CE36A.50706@gmail.com> Date: Thu, 2 Apr 2015 11:04:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> <4A8F9E83-B481-44FC-AD70-BFFF43EC2614@lists.zabbadoz.net> <551CE36A.50706@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 11:04:50 -0000 > On 02 Apr 2015, at 06:36 , Alexandru Petrescu = wrote: >=20 > Sorry to insist on this, just as side note. >=20 > Le 01/04/2015 19:54, Bjoern A. Zeeb a =E9crit : >>> On 01 Apr 2015, at 14:07 , Alexandru Petrescu >>> wrote: >>>=20 >>> It is customary to see current computers having both an IPv6 stack >>> and an IPv4 stack on them. But some computers only have IPv4, >>> whereas the rest have IPv4 and IPv6 stacks. There are no >>> computers (to my knowledge) which have only IPv6 stacks. >>=20 >> One of my desktop systems does (not have IPv4 support anymore; >=20 > In general I can agree with you, in a sense where maybe a computer is > not reachable on IPv4 from another computer; maybe part of IPv4 = support > is no more there. On FreeBSD I compile it out of my kernel and parts of user space if I = want to. We did this for World IPv6 Day almost 4 years ago: = http://www.prweb.com/releases/2011/6/prweb8529718.htm If you used FreeBSD jails for services you could run them IPv6-only = since FreeBSD 7.2 and you do get =93Address Family Not Supported=94 back = for every IPv4 operation you try to do (7.2 was released in May 2009). = Gosh, been doing this for more than 5 years already. >> and to my knowledge you can just disable it on Windows as well, >=20 > Right - uncheck the IPv4 box, and check IPv6 on a computer Windows 7's > =93Properties" of the network interface - it works. Wrong: netsh interface ipv4 uninstall and reboot and you=92ll not see IPv4 anymore in route print or ipconfig /all and = ping 127.1 will no longer work but error on you. >> so it=92s not a big deal anymore). >=20 > I beg to differ, as I see it this is still far away from an ideal = where > only IPv6 were present in the computer. Well, better start living it today and we can have a lot better = operational discussions on the end-node (client/server systems) side. = I have 7 IPv4 addresses left in use in total for all my infrastructure = (and could condense it to 2 or 3 if I wanted really badly). And the = only reason I keep those is for the ipv4-only world to reach NS/MX/Web. = But that=92s just me. Leave a /27 for a SMB and be good ;-) =97=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From nobody Thu Apr 2 10:44: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 4534D1B2D71 for ; Thu, 2 Apr 2015 10:44:54 -0700 (PDT) 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 75l_b7yGaJKB for ; Thu, 2 Apr 2015 10:44:52 -0700 (PDT) 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 836441B2D6C for ; Thu, 2 Apr 2015 10:44:51 -0700 (PDT) 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 t32HinUY016361; Thu, 2 Apr 2015 19:44:49 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D267D20769B; Thu, 2 Apr 2015 19:45:44 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C6DB72041B0; Thu, 2 Apr 2015 19:45:44 +0200 (CEST) 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 t32HiYxW021120; Thu, 2 Apr 2015 19:44:49 +0200 Message-ID: <551D8001.8060901@gmail.com> Date: Thu, 02 Apr 2015 19:44:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> <4A8F9E83-B481-44FC-AD70-BFFF43EC2614@lists.zabbadoz.net> <551CE36A.50706@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 17:44:54 -0000 Le 02/04/2015 13:04, Bjoern A. Zeeb a écrit : > >> On 02 Apr 2015, at 06:36 , Alexandru Petrescu >> wrote: >> >> Sorry to insist on this, just as side note. >> >> Le 01/04/2015 19:54, Bjoern A. Zeeb a écrit : >>>> On 01 Apr 2015, at 14:07 , Alexandru Petrescu >>>> wrote: >>>> >>>> It is customary to see current computers having both an IPv6 >>>> stack and an IPv4 stack on them. But some computers only have >>>> IPv4, whereas the rest have IPv4 and IPv6 stacks. There are no >>>> computers (to my knowledge) which have only IPv6 stacks. >>> >>> One of my desktop systems does (not have IPv4 support anymore; >> >> In general I can agree with you, in a sense where maybe a computer >> is not reachable on IPv4 from another computer; maybe part of IPv4 >> support is no more there. > > On FreeBSD I compile it out of my kernel and parts of user space if > I want to. We did this for World IPv6 Day almost 4 years ago: > http://www.prweb.com/releases/2011/6/prweb8529718.htm > > If you used FreeBSD jails for services you could run them IPv6-only > since FreeBSD 7.2 and you do get “Address Family Not Supported” back > for every IPv4 operation you try to do (7.2 was released in May > 2009). Gosh, been doing this for more than 5 years already. That's good for BSD then, I am happy for it. Does it remove the 127.0.0.1 from its /etc/hosts too? In linux you can't make the IPv4 stack or any of its features into a module. It's builtin. >>> and to my knowledge you can just disable it on Windows as well, >> >> Right - uncheck the IPv4 box, and check IPv6 on a computer Windows >> 7's “Properties" of the network interface - it works. > > Wrong: > > netsh interface ipv4 uninstall and reboot I'd like to try that. But if it fails can I 'install' it back somehow? (because I already experienced some hangs with checking off IPv4 while wireshark running - for some reasons some apps think that if IPv4 is not there then networking is not there although they are IPv6-capable). > and you’ll not see IPv4 anymore in route print or ipconfig /all and > ping 127.1 will no longer work but error on you. And Windows' hosts file containing 127? >>> so it’s not a big deal anymore). >> >> I beg to differ, as I see it this is still far away from an ideal >> where only IPv6 were present in the computer. > > > Well, better start living it today and we can have a lot better > operational discussions on the end-node (client/server systems) > side. I have 7 IPv4 addresses left in use in total for all my > infrastructure (and could condense it to 2 or 3 if I wanted really > badly). And the only reason I keep those is for the ipv4-only world > to reach NS/MX/Web. But that’s just me. Leave a /27 for a SMB and > be good ;-) Congratulations. I have no BSD here, except for the proprietary derivatives (ios, windows, etc). For all code that I can modify it's linux. Given that I can't turn off IPv4 until linux gives a means to. Do you know whether ios has such a means to turn off fully IPv4? Alex > > — Bjoern A. Zeeb Charles Haddon > Spurgeon: "Friendship is one of the sweetest joys of life. Many > might have failed beneath the bitterness of their trial had they > not found a friend." > > > From nobody Thu Apr 2 10:53: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 B68EF1A870C for ; Thu, 2 Apr 2015 10:53:06 -0700 (PDT) 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 I9ImtGWYzNJz for ; Thu, 2 Apr 2015 10:53:05 -0700 (PDT) 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 0BFAD1A002D for ; Thu, 2 Apr 2015 10:53:03 -0700 (PDT) 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 t32Hr2Hd018967 for ; Thu, 2 Apr 2015 19:53:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A46112076C2 for ; Thu, 2 Apr 2015 19:53:57 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9C1A9207486 for ; Thu, 2 Apr 2015 19:53:57 +0200 (CEST) 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 t32HqkaV017645 for ; Thu, 2 Apr 2015 19:53:02 +0200 Message-ID: <551D81EE.2030403@gmail.com> Date: Thu, 02 Apr 2015 19:52:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> <551CE518.7040202@gmail.com> In-Reply-To: <551CE518.7040202@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 17:53:06 -0000 Le 02/04/2015 08:43, Alexandru Petrescu a écrit : > Le 02/04/2015 01:30, James Woodyatt a écrit : >> On Wed, Apr 1, 2015 at 9:07 AM, Alexandru Petrescu >> > > wrote: >> >> >> It is customary to see current computers having both an IPv6 stack >> and an IPv4 stack on them. But some computers only have IPv4, >> whereas the rest have IPv4 and IPv6 stacks. There are no computers >> (to my knowledge) which have only IPv6 stacks. >> >> >> Sigh. Computing platforms where the only network interfaces are >> 6LoWPAN-over-foo. These exist today, and they are not just >> laboratory toys. > > Right, this is something that deserves consideration. > > I wonder though whether they are directly connectable to the > Internet. Last time I checked a 6lowpan IPv6-only computer it was a > reduced IPv6 - one had to go through a form of middle-box to reach > it. E.g. one wouldnt ssh into a 6lowpan device, would not manage it > directly, but would need a CoAP gw, or a PC attached with USB to be > on it. > > But I will ask around to see the current situation. I asked around for some 6lowpan Contiki situation. We still need to check serial output of modem verbose looking for IPv4 literals. But, in general, contiki does have this ability to only include IPv6, and no IPv4 stack. There are other questions there, though. For example, some contiki devices still use fec0 addresses. IPv6 contiki devices are not reachable by other means than CoAP (there is no TCP or HTTP for example), by using a particular plugin in some browser. You can't telnet or rsh into it. You can't imagine sending a 6lowpan device a pure RA (it must be an RPL ICMP message). You can't connect a 6lowpan-enabled-Router somewhere at an edge of the Internet where prefixes are already /64, because 6lowpan needs /64 as well. I may be wrong in some of these aspects, but for these doubts I still dont think 6lowpan is IPv6, and I dont think 6lowpan devices are on the IPv6 Internet. Or is there an address of an IPv6-only 6lowpan device I could ping6? Alex > > Alex > >> >> >> -- james woodyatt > Nest >> Labs, Communications Engineering > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Apr 2 11:00: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 6D92E1A002D for ; Thu, 2 Apr 2015 11:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 2C9kqEBQDO4z for ; Thu, 2 Apr 2015 11:00:51 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA781A005B for ; Thu, 2 Apr 2015 11:00:51 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id F11823493D1; Thu, 2 Apr 2015 18:00:48 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 69871160066; Thu, 2 Apr 2015 18:08:04 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id D117016005C; Thu, 2 Apr 2015 18:08:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rock.dv.isc.org (Postfix) with ESMTP id 4F6E52C5011F; Fri, 3 Apr 2015 05:00:46 +1100 (EST) To: Alexandru Petrescu From: Mark Andrews References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> <4A8F9E83-B481-44FC-AD70-BFFF43EC2614@lists.zabbadoz.net> <551CE36A.50706@gmail.com> <551D8001.8060901@gmail.com> In-reply-to: Your message of "Thu, 02 Apr 2015 19:44:33 +0200." <551D8001.8060901@gmail.com> Date: Fri, 03 Apr 2015 05:00:46 +1100 Message-Id: <20150402180046.4F6E52C5011F@rock.dv.isc.org> Archived-At: Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 18:00:56 -0000 In message <551D8001.8060901@gmail.com>, Alexandru Petrescu writes: > Le 02/04/2015 13:04, Bjoern A. Zeeb a =E9crit : > > > >> On 02 Apr 2015, at 06:36 , Alexandru Petrescu > >> wrote: > >> > >> Sorry to insist on this, just as side note. > >> > >> Le 01/04/2015 19:54, Bjoern A. Zeeb a =E9crit : > >>>> On 01 Apr 2015, at 14:07 , Alexandru Petrescu > >>>> wrote: > >>>> > >>>> It is customary to see current computers having both an IPv6 > >>>> stack and an IPv4 stack on them. But some computers only have > >>>> IPv4, whereas the rest have IPv4 and IPv6 stacks. There are no > >>>> computers (to my knowledge) which have only IPv6 stacks. > >>> > >>> One of my desktop systems does (not have IPv4 support anymore; > >> > >> In general I can agree with you, in a sense where maybe a computer > >> is not reachable on IPv4 from another computer; maybe part of IPv4 > >> support is no more there. > > > > On FreeBSD I compile it out of my kernel and parts of user space if > > I want to. We did this for World IPv6 Day almost 4 years ago: > > http://www.prweb.com/releases/2011/6/prweb8529718.htm > > > > If you used FreeBSD jails for services you could run them IPv6-only > > since FreeBSD 7.2 and you do get =93Address Family Not Supported=94 back > > for every IPv4 operation you try to do (7.2 was released in May > > 2009). Gosh, been doing this for more than 5 years already. > > That's good for BSD then, I am happy for it. Does it remove the > 127.0.0.1 from its /etc/hosts too? > > In linux you can't make the IPv4 stack or any of its features into a > module. It's builtin. It looks like Linux needs some work then. > >>> and to my knowledge you can just disable it on Windows as well, > >> > >> Right - uncheck the IPv4 box, and check IPv6 on a computer Windows > >> 7's =93Properties" of the network interface - it works. > > > > Wrong: > > > > netsh interface ipv4 uninstall and reboot > > I'd like to try that. But if it fails can I 'install' it back somehow? > > (because I already experienced some hangs with checking off IPv4 while > wireshark running - for some reasons some apps think that if IPv4 is not > there then networking is not there although they are IPv6-capable). Which is a application bug that should be reported. > > and you=92ll not see IPv4 anymore in route print or ipconfig /all and > > ping 127.1 will no longer work but error on you. > > And Windows' hosts file containing 127? Do you want to rip all the A records out of the DNS as well? If the getaddrinfo() is properly written the IPv4 addresses will be filtered from the responses with AI_ADDRCONFIG set so it shouldn't matter if it is still there. > >>> so it=92s not a big deal anymore). > >> > >> I beg to differ, as I see it this is still far away from an ideal > >> where only IPv6 were present in the computer. > > > > > > Well, better start living it today and we can have a lot better > > operational discussions on the end-node (client/server systems) > > side. I have 7 IPv4 addresses left in use in total for all my > > infrastructure (and could condense it to 2 or 3 if I wanted really > > badly). And the only reason I keep those is for the ipv4-only world > > to reach NS/MX/Web. But that=92s just me. Leave a /27 for a SMB and > > be good ;-) > > Congratulations. > > I have no BSD here, except for the proprietary derivatives (ios, > windows, etc). For all code that I can modify it's linux. Given that I > can't turn off IPv4 until linux gives a means to. You have a editor, a compiler and the source. You have the means to do it. Whether you have the skill / inclination to do it is another matter. > Do you know whether ios has such a means to turn off fully IPv4? > > Alex > > > > > =97 Bjoern A. Zeeb Charles Haddon > > Spurgeon: "Friendship is one of the sweetest joys of life. Many > > might have failed beneath the bitterness of their trial had they > > not found a friend." > > > > > > > > > _______________________________________________ > 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 Thu Apr 2 11:09: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 2832D1A0056 for ; Thu, 2 Apr 2015 11:09:37 -0700 (PDT) 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 xuIB3HQb0qLd for ; Thu, 2 Apr 2015 11:09:35 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04731A002D for ; Thu, 2 Apr 2015 11:09:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t32I9WxM009310; Thu, 2 Apr 2015 20:09:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 00C892076BA; Thu, 2 Apr 2015 20:10:28 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E6F4D2074AC; Thu, 2 Apr 2015 20:10:27 +0200 (CEST) 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 t32I8xOF016069; Thu, 2 Apr 2015 20:09:32 +0200 Message-ID: <551D85B7.5030406@gmail.com> Date: Thu, 02 Apr 2015 20:08:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark Andrews References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> <4A8F9E83-B481-44FC-AD70-BFFF43EC2614@lists.zabbadoz.net> <551CE36A.50706@gmail.com> <551D8001.8060901@gmail.com> <20150402180046.4F6E52C5011F@rock.dv.isc.org> In-Reply-To: <20150402180046.4F6E52C5011F@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 18:09:37 -0000 Le 02/04/2015 20:00, Mark Andrews a écrit : [...] >> And Windows' hosts file containing 127? > > Do you want to rip all the A records out of the DNS as well? Right. That is necessary in order to obtain IPv6-only. But it looks like a huge task to remove all A records from DNS. This makes think about removing all 500k IPv4 routes from the DFZ - also a huge task. > If the getaddrinfo() is properly written the IPv4 addresses will be > filtered from the responses with AI_ADDRCONFIG set so it shouldn't > matter if it is still there. That would still be IPv4 taking space on disk; taking bandwidth on network up to Client (AI_ filtering is local, right?). >>>>> so it=92s not a big deal anymore). >>>> >>>> I beg to differ, as I see it this is still far away from an >>>> ideal where only IPv6 were present in the computer. >>> >>> >>> Well, better start living it today and we can have a lot better >>> operational discussions on the end-node (client/server systems) >>> side. I have 7 IPv4 addresses left in use in total for all my >>> infrastructure (and could condense it to 2 or 3 if I wanted >>> really badly). And the only reason I keep those is for the >>> ipv4-only world to reach NS/MX/Web. But that=92s just me. >>> Leave a /27 for a SMB and be good ;-) >> >> Congratulations. >> >> I have no BSD here, except for the proprietary derivatives (ios, >> windows, etc). For all code that I can modify it's linux. Given >> that I can't turn off IPv4 until linux gives a means to. > > You have a editor, a compiler and the source. You have the means to > do it. Whether you have the skill / inclination to do it is another > matter. Ressource may be there, and the pleasure of removing; but reticence worrying doing it too early is there too. Maybe someone somewhere still needs this little IPv4 and it will break otherwise; wouldnt touch it yet. Alex > >> Do you know whether ios has such a means to turn off fully IPv4? >> >> Alex >> >>> >>> =97 Bjoern A. Zeeb Charles >>> Haddon Spurgeon: "Friendship is one of the sweetest joys of >>> life. Many might have failed beneath the bitterness of their >>> trial had they not found a friend." >>> >>> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Apr 2 11:31: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 1CD3A1A016C for ; Thu, 2 Apr 2015 11:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 BiFFyVNokudp for ; Thu, 2 Apr 2015 11:31:30 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 17E911A0266 for ; Thu, 2 Apr 2015 11:31:28 -0700 (PDT) Received: by obvd1 with SMTP id d1so142473123obv.0 for ; Thu, 02 Apr 2015 11:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TX3hCV7i077wZKmQ+4Nwp+VXdF2aPb374IS9hBLZSGg=; b=oB1/OTY9vHWtqm8P+/gRCADzvZjzEbDbc79/35j9K8DQoC/5Ivf2r84Hw0OdWPhX2N 1HUBRRwT5gFr1X7t9ouoeBKiKNK39LrOX3ymel53l1c9cM3PjdhsABSzmP8IhHN0PEXz p279RMdVRHIa80PGUb8FsY23NR7IY9nbdXQ3g= 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=TX3hCV7i077wZKmQ+4Nwp+VXdF2aPb374IS9hBLZSGg=; b=GE5uAB+d9Su5POWt3V3rUMrR8QJI4r2e9EsL4/uJeDTuVuQCNt/r9LEWFA4pPuURD7 bSWofPeCY3G//Bc5yIQGAQQ981smI1o+/3CIOQ7rJghaK0PASevtKM+c+bj89PllLcRW zHFLSJ3A9fvEACF6GWl6+ou8Y4uO0MyTpBijWYCd9UNrSe36i7P3W+5dMKJN92YJlgZr ijq48yYema9p31XTBXr+/p8bHvIsfdWi/hQDtm163cZeQVnvtDkv3+nJriiOAE1ZP2OZ 5tySkjvMRu7Mho8yB21bPO7Xdwr7s1SCtueQo8GsibdSn3lrC459Y/wC1mmTnusTU+0O 568A== X-Gm-Message-State: ALoCoQkHcrNrtgJ5yxL70TFpepCvh41cD86bNxELEyDqZJNm09yvKFocKwGWkRpbm7np7BknMzYM MIME-Version: 1.0 X-Received: by 10.60.179.227 with SMTP id dj3mr48258382oec.29.1427999487501; Thu, 02 Apr 2015 11:31:27 -0700 (PDT) Received: by 10.76.177.229 with HTTP; Thu, 2 Apr 2015 11:31:27 -0700 (PDT) In-Reply-To: <551D81EE.2030403@gmail.com> References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> <551CE518.7040202@gmail.com> <551D81EE.2030403@gmail.com> Date: Thu, 2 Apr 2015 13:31:27 -0500 Message-ID: From: James Woodyatt To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7bd6b21a3140c50512c20a8d Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 18:31:32 -0000 --047d7bd6b21a3140c50512c20a8d Content-Type: text/plain; charset=UTF-8 On Thu, Apr 2, 2015 at 12:52 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > > But, in general, contiki does have this ability to only include IPv6, and > no IPv4 stack. > ConTiki isn't the only 6LoWPAN platform to consider. You could ask members of Thread Group if any of their commercial products in development now are doing this. (You could ask me, but I couldn't possibly comment.) > There are other questions there, though. > [...] > You can't imagine sending a 6lowpan device a pure RA (it must be an > RPL ICMP message). > According to the most recently published technical presentations, Thread networks do not use RPL or RFC 6775. The specification for their border routers is not yet published. > You can't connect a 6lowpan-enabled-Router somewhere at an edge of > the Internet where prefixes are already /64, because 6lowpan needs /64 as > well. > That's right. It's one of the reasons I've been so active in the HOMENET working group. > I may be wrong in some of these aspects, but for these doubts I still dont > think 6lowpan is IPv6, and I dont think 6lowpan devices are on the IPv6 > Internet. > I think you're absolutely wrong to doubt that 6LoWPAN devices can be fully compliant IPv6 nodes reachable via the public Internet. > Or is there an address of an IPv6-only 6lowpan device I could ping6? > I'm fairly certain they must exist in public somewhere. Just not anywhere known to me. Today. -- james woodyatt Nest Labs, Communications Engineering --047d7bd6b21a3140c50512c20a8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 2, 2015 at 12:52 PM, Alexandru Petrescu <alexandru.petr= escu@gmail.com> wrote:

But, in general, contiki does have this ability to only include IPv6,=C2=A0= and no IPv4 stack.

ConTiki isn't th= e only 6LoWPAN platform to consider. You could ask members of Thread Group = <http://www.threadgroup.org/= > if any of their commercial products in development now are doing this.= (You could ask me, but I couldn't possibly comment.)
=C2=A0<= /div>
There are other questions there, though.
[...]
You can't imagine sending a 6lowpan device a pure RA (it must be an RPL= =C2=A0ICMP message).

According to the m= ost recently published technical presentations, Thread networks do not use = RPL or RFC 6775. The specification for their border routers is not yet publ= ished.
=C2=A0
You can't connect a 6lowpan-enabled-Router somewhere at an edge of the= =C2=A0Internet where prefixes are already /64, because 6lowpan needs /64 as= well.

That's right. It's one o= f the reasons I've been so active in the HOMENET working group.
=C2=A0
I may be wrong in some of these aspects, but for these doubts I still=C2=A0= dont think 6lowpan is IPv6, and I dont think 6lowpan devices are on the=C2= =A0IPv6 Internet.

I think you're ab= solutely wrong to doubt that 6LoWPAN devices can be fully compliant IPv6 no= des reachable via the public Internet.
=C2=A0
Or is there an address of an IPv6-only 6lowpan device I could ping6?

I'm fairly certain they must exi= st in public somewhere. Just not anywhere known to me. Today.

--
james woodyatt <= jhw@nestlabs.com>
Nest Labs, Communications Engineering
--047d7bd6b21a3140c50512c20a8d-- From nobody Thu Apr 2 12:23: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 BD22E1A1BA4 for ; Thu, 2 Apr 2015 12:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxSBHSzZBNVv for ; Thu, 2 Apr 2015 12:23:40 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (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 B27DC1A1AB5 for ; Thu, 2 Apr 2015 12:23:40 -0700 (PDT) Received: by pddn5 with SMTP id n5so98451808pdd.2 for ; Thu, 02 Apr 2015 12:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K/UdayYjhUYUf6H1RvqemGSuq0geUKBHEFws/sVzAwQ=; b=fQEHWvbIrVXu3IZfW3DnM8ePdW+cEZ4cHuf+4uIayJibamuJfj/fdmdK5wTwEBpdKm 5MGArK9se8t7/9k4eIG1Ha9IeIhP05n+rKrkk+b/dI/h1Bm79T68RS3DPtZzStlNHmU4 CSb7RNykeU0G70YPUuinkoDaMVU05hp01T+88wBw2ZjUeJle+dp71V4CfkPmD9XleC6R SANExINRoE9HEPDR9lRHCjF6qNXtHUTcphanXJd6F37sUfjmvpbYUGYfawbODqLNHkfQ iHb3cwyf3DJ9hRmck6+Nc1G2dl0lKX2m0WO29MtlzmF5ur05pWJub/TZbHcQEFTCWZZa eJ9w== X-Received: by 10.66.183.47 with SMTP id ej15mr47781802pac.34.1428002620462; Thu, 02 Apr 2015 12:23:40 -0700 (PDT) Received: from ?IPv6:2406:e007:4dd0:1:28cc:dc4c:9703:6781? ([2406:e007:4dd0:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id g9sm6001649pdj.24.2015.04.02.12.23.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 12:23:39 -0700 (PDT) Message-ID: <551D9740.9030305@gmail.com> Date: Fri, 03 Apr 2015 08:23:44 +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.5.0 MIME-Version: 1.0 To: Alexandru Petrescu , Mark Andrews References: <63C03012-C7DD-497E-A1EF-019711E95FD0@cisco.com> <551BFBA9.5070103@gmail.com> <4A8F9E83-B481-44FC-AD70-BFFF43EC2614@lists.zabbadoz.net> <551CE36A.50706@gmail.com> <551D8001.8060901@gmail.com> <20150402180046.4F6E52C5011F@rock.dv.isc.org> <551D85B7.5030406@gmail.com> In-Reply-To: <551D85B7.5030406@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Bjoern A. Zeeb" , v6ops@ietf.org Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Apr 2015 19:23:41 -0000 On 03/04/2015 07:08, Alexandru Petrescu wrote: > Le 02/04/2015 20:00, Mark Andrews a =C3=A9crit : > [...] >>> And Windows' hosts file containing 127? >> >> Do you want to rip all the A records out of the DNS as well? >=20 > Right. That is necessary in order to obtain IPv6-only. You confuse me. Why is it necessary? To the contrary, it is necessary *not* to do this until the last IPv4 user has vanished. You might of course consider a resolver that returns NXDOMAIN for any A query, if you want to hide IPv4 from a local domain. > But it looks > like a huge task to remove all A records from DNS. >=20 > This makes think about removing all 500k IPv4 routes from the DFZ - als= o > a huge task. And equally undesirable. Again, you could locally render all IPv4 routes unreachable, if you really wanted to. Brian From nobody Fri Apr 3 06:44: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 37AB61A92AE; Fri, 3 Apr 2015 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.425 X-Spam-Level: * X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1_3Q_Yp3qMY2; Fri, 3 Apr 2015 06:44:36 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2620A1A8ABD; Fri, 3 Apr 2015 06:44:35 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,517,1422939600"; d="scan'208,217";a="849049143" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Apr 2015 09:30:42 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 3 Apr 2015 09:44:35 -0400 From: "George, Wes" To: Ca By , "Fred Baker (fred)" Date: Fri, 3 Apr 2015 09:44:34 -0400 Thread-Topic: [v6ops] IPv4 trajectory Thread-Index: AdBuFFHyJK3o8nZ3RKykwdIXbZ5ANw== Message-ID: References: <551AF135.3060602@gmail.com> <551B37B9.4090400@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D143FC8D4C060wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG , "sunset4@ietf.org" Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 13:44:40 -0000 --_000_D143FC8D4C060wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRkaW5nIHN1bnNldDQsIHNpbmNlIHRoaXMgbG9va3MgYSBsb3QgbGlrZSBhIGRpc2N1c3Npb24g YWJvdXQgdHVybmluZyBvZmYgSVB2NC4gOi0pDQoNCkZyb206IENhIEJ5IDxjYi5saXN0NkBnbWFp bC5jb208bWFpbHRvOmNiLmxpc3Q2QGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBNYXJjaCAz MSwgMjAxNSBhdCAxMTowNiBQTQ0KVG86ICJGcmVkIEJha2VyIChmcmVkKSIgPGZyZWRAY2lzY28u Y29tPG1haWx0bzpmcmVkQGNpc2NvLmNvbT4+DQpDYzogSVB2NiBPcHMgV0cgPHY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJUHY0IHRy YWplY3RvcnkNCg0KDQoNCk9uIFR1ZXNkYXksIE1hcmNoIDMxLCAyMDE1LCBGcmVkIEJha2VyIChm cmVkKSA8ZnJlZEBjaXNjby5jb208bWFpbHRvOmZyZWRAY2lzY28uY29tPj4gd3JvdGU6DQoNCj4g T24gTWFyIDMxLCAyMDE1LCBhdCA1OjExIFBNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5j YXJwZW50ZXJAZ21haWwuY29tPGphdmFzY3JpcHQ6Oz4+IHdyb3RlOg0KPg0KPiA1LiBUaGVyZWZv cmUsIG1pZ3JhdGUgSVB2NCBzdXBwb3J0IHRvIHJ1biBvdmVyIElQdjYuDQoNCkFnYWluLCBpZiB5 b3Ugd2FudCB0aGUgY2FycmllcuKAmXMgbG9naWMsIGFzayB0aGUgY2Fycmllci4gQnV0IHRvIG1l LCB0aGF0IGRvZXNu4oCZdCBmb2xsb3cuDQoNCk5vdCBhbGwgY29yZSBjYXJyaWVycywgYnV0IGEg c2lnbmlmaWNhbnQgbnVtYmVyIG9mIHRoZW0sIGRvbuKAmXQgdGhpbmsgb2YgdGhlbXNlbHZlcyBh cyBjYXJyeWluZyBJUHY0IG9yIElQdjYgcGVyIHNlLiBUaGV5IHRoaW5rIG9mIHRoZW1zZWx2ZXMg YXMgTVBMUyBob3VzZXMsIHVzaW5nIGp1bWJvZnJhbWVzIHNvIHRoYXQgdGhlIGFkZGl0aW9uIG9m IHRoYXQgaGVhZGVyIHRvIHdoYXRldmVyIHRoZWlyIHBheWxvYWQgaGFwcGVucyB0byBiZSAoYWth IElQdjQgb3IgSVB2NikgZG9lc27igJl0IGhhdmUgYW4gTVRVIHByb2JsZW0uIFdoYXRldmVyIGNv bWVzIGluLCB0aGV5IHRocm93IGl0IGludG8gdGhlIHJpZ2h0IHR1bm5lbCAoYWthIExTUCkgdG8g Z2V0IGl0IHRvIHRoZSByaWdodCBlZ3Jlc3MsIE1QTFMgZ2V0cyBpdCB0aGVyZSwgYW5kIGl0IGdv ZXMgb3V0IHRoZSBvdGhlciBkb29yLg0KDQpZb3XigJlyZSBhcmd1aW5nIGFib3V0IHdoYXQga2lu ZCBvZiB0dW5uZWwgdGhleSBzaG91bGQgdXNlLiBUaGV54oCZcmUgcXVpdGUgaGFwcHkgd2l0aCB0 aGUgb25lIHRoZXkgaGF2ZSwgYW5kIGl04oCZcyBuZWl0aGVyIElQdjQgbm9yIElQdjYuDQpXR10g d2hpbGUgdGhpcyBpcyBzb21ld2hhdCB0cnVlLCBNUExTIGRvZXMgZGVwZW5kIG9uIElQdjQgdG9k YXksIGFuZCAicXVpdGUgaGFwcHkiIGlzIHByb2JhYmx5IG92ZXJzZWxsaW5nIHRoaW5ncy4gTW9y ZSBvbiB0aGF0IGJlbG93Lg0KDQpJIGFtIG5vdCBhIGRmeiBuZXR3b3JrIG9wZXJhdG9yLCBidXQg bXkgbmV0d29yayBoYXMgYW4gaXB2NCBjb250cm9sIHBsYW5lIHRoYXQgaXMgcmZjIDE5MTggYW5k IG9ubHkgdmlzaWJsZSB0byB0aGUgY29udHJvbCBwbGFuZSwgZm9yIHRoZSBtb3N0IHBhcnQuICBN eSBndWVzcyBpcyB0aGF0IG1vc3QgZGZ6IHByb3ZpZGVycyBhcmUgbm90IHByb3Blcmx5IGR1YWwt c3RhY2ssIHRoZXkgYXJlIHVzaW5nIDZwZSBvciA2dnBlLg0KDQpUaGUgZm9yd2FyaW5nIHBsYW5l IGlzIG1wbHMuIEZ1bGwgc3RvcC4NCg0KV0ddIGFzIHdpdGggbW9zdCB0aGluZ3MsIGFzayAxMCBv cGVyYXRvcnMgYW5kIHlvdSdsbCBnZXQgMTUgYW5zd2Vycy4gSSBhbSBub3Qgc3VyZSB3aGV0aGVy IHRoZSBERlogcGFydCBvZiAiREZaIG9wZXJhdG9yIiBtYXR0ZXJzIGluIHRoaXMgZGlzY3Vzc2lv biwgYnV0IGhlcmUncyBteSBzaXR1YXRpb24gKGxhcmdlIE1TTyB3aXRoIGEgYmFja2JvbmUpOg0K T24gbXkgbmV0d29yaywgd2UgYXJlIHByb3Blcmx5IGR1YWwtc3RhY2suIExEUCBpcyBlbmFibGVk IGJlY2F1c2UgTVBMUyBzZXJ2ZXMgdG8gcHJvdmlkZSBhIHNldCBvZiBzZXJ2aWNlcywgbW9zdGx5 IEwyVlBOLiBUaHVzIElQdjQgdW5pY2FzdCBlbmRzIHVwIGJlaW5nIGxhYmVsLXN3aXRjaGVkLiBC dXQgd2UncmUgc3RpbGwgcnVubmluZyBuYXRpdmUgZm9yd2FyZGluZyBmb3IgbXVsdGljYXN0IChv ZiB3aGljaCB0aGVyZSBpcyBxdWl0ZSBhIGxvdCBzaW5jZSBpdCdzIGhvdyB3ZSBkaXN0cmlidXRl IHZpZGVvKSBhbmQgZm9yIElQdjYuDQoNClRoZXJlIGlzIG5vIHByZXNzdXJlIHRvIGV2ZXIgY2hh bmdlIHRoZSBjb21wb3NpdGlvbiBvZiB0aGUgYmFja2JvbmUgc2luY2UgdGhlIGJhY2tib25lIGl0 c2VsZiBpcyBub3Qgc2NhbGluZyBxdWlja2x5IGluIHRlcm1zIG9mIGlwIGFkZHJlc3MgdXNhZ2Uu DQoNCldHXSB5ZXMsIGdyb3d0aCBvZiBhZGRyZXNzIHVzYWdlIGluIHRoZSBiYWNrYm9uZSBpc24n dCB0aGUgZHJpdmVyLiBCdXQgSSBkaXNhZ3JlZSB0aGF0IHRoZXJlJ3Mgbm8gcHJlc3N1cmUuIFRo ZXJlIGlzIGEgbm9uLXRyaXZpYWwgaW5jcmVtZW50YWwgY29zdCBmb3Igb3BlcmF0aW9ucyB0byBt YW5hZ2UgYSBkdWFsLXN0YWNrIG5ldHdvcmsgdnMgYSBzaW5nbGUtc3RhY2sgb25lIGJlY2F1c2Ug bXVjaCBvZiB0aGUgY29uZmlndXJhdGlvbiBhbmQgdHJvdWJsZXNob290aW5nIGlzIGFkZHJlc3Mt ZmFtaWx5IHNwZWNpZmljIGV2ZW4gaWYgdGhlcmUgYXJlIGEgbG90IG9mIHNpbWlsYXJpdGllcyBh bmQgcmV1c2FibGUgYml0cywgYW5kIHRoZXJlIGFyZSBhIHdob2xlIHJhZnQgb2YgaGFyZHdhcmUv c29mdHdhcmUgdGVzdCBjYXNlcyBhcm91bmQga2VlcGluZyBJUHY0IHdvcmtpbmcgdGhhdCBJIGNv dWxkIGV2ZW50dWFsbHkgamV0dGlzb24gaWYgSSBkaWRuJ3QgbmVlZCBJUHY0IG9uIHBhcnRzIG9m IG15IG5ldHdvcmsuIEJ1dCByZWFsbHksIHRoZSBwcmVzc3VyZSB0byBjaGFuZ2UgdGhlIGNvbXBv c2l0aW9uIG9mIHRoZSBiYWNrYm9uZSBjb21lcyBmcm9tIHR3byB0aGluZ3M6DQoNCiAxLiAgSVB2 NCBHVUFzIGFyZSBmb3IgY3VzdG9tZXJzLiBXaGlsZSB0aGVyZSBpc24ndCBhIGxvdCBvZiBJUHY0 IG5lZWRlZCB0byBudW1iZXIgdGhlIGJhY2tib25lLCBkZXBlbmRpbmcgb24gbmV0IGN1c3RvbWVy IGdyb3d0aCByYXRlIGFuZCB0aGUgY29zdCBvZiBhZGRyZXNzZXMsIHRoZSB2YWx1ZSBvZiByZWNs YWltaW5nIHNldmVyYWwgYmxvY2tzIG9mIElQdjQgYWRkcmVzc2VzIGZyb20geW91ciBpbmZyYXN0 cnVjdHVyZSBjb3VsZCBiZSBzaWduaWZpY2FudCAoZG9lcyBpdCBidXkgeW91IGVub3VnaCB0aW1l IHRvIGF2b2lkIHRoYXQgbmV4dCBpbnZlc3RtZW50IGluIGFkZHJlc3NlcyBvciBDR04/KS4gSG93 ZXZlciwgSSBkbyB0aGluayB0aGF0IHRoZSBiYWNrYm9uZSB3aWxsIGJlIGFtb25nIHRoZSBsYXN0 IHBsYWNlcyB0aGF0IHJlY2xhbWF0aW9uIGhhcHBlbnMsIGZvciByZWFzb25zIEknbGwgZGV0YWls IGJlbG93Lg0KIDIuICBSRkMxOTE4IGlzIGFsc28gZXhoYXVzdGVkLCBzbyBpdCdzIG5vdCBhIHZp YWJsZSBhbHRlcm5hdGl2ZS4gSSdtIGRlcGxveWluZyBsYXJnZSBhbW91bnRzIG9mIElQdjYtb25s eSBnZWFyIHRvZGF5IGJlY2F1c2UgSSBoYXZlIE8obWlsbGlvbnMpIG9mIGRldmljZXMgdGhhdCBu ZWVkIGFkZHJlc3NlcyBmb3IgbWFuYWdlbWVudCBhbmQgaW50ZXJuYWwgc3R1ZmYgZm9yIHdoaWNo IEkgY2FuIGVpdGhlciB3YXN0ZSBHVUEsIHJldXNlIFJGQzE5MTggbWFueSB0aW1lcyBhbmQgZGVh bCB3aXRoIHRoZSBhdHRlbmRhbnQgaGVhZGFjaGVzLCBvciBqdXN0IG1vdmUgaXQgdG8gSVB2Ni4N Cg0KVGhlIHByb2JsZW0gd2l0aCB0aGlzIGNvbnZlcnNhdGlvbiBpcyB0aGF0IHdlJ3JlIHN0aWxs IHRyZWF0aW5nIHRoaXMgYXMgYW4gYWxsLW9yLW5vdGhpbmcgZXhlcmNpc2UsIGFuZCB0aHVzIGNv bmZsYXRpbmcgZm9yd2FyZGluZywgY29udHJvbCwgYW5kIG1hbmFnZW1lbnQsIHRob3VnaCBlYWNo IGhhcyBpdHMgb3duIHRpbWVsaW5lIGZvciBtb3ZpbmcgdG8gSVB2Ni1vbmx5LCBhbmQgd2UgYXJl IGFsc28gYXJ0aWZpY2lhbGx5IGNvbnN0cmFpbmluZyB0aGlzIHRvIHNvbWUgZGVmaW5pdGlvbiBv ZiBiYWNrYm9uZSwgcmF0aGVyIHRoYW4gdGhlIG92ZXJhbGwgaW5mcmFzdHJ1Y3R1cmUgaW4gYSBn aXZlbiBjYXJyaWVyLCB3aGljaCBpcyBub3QgaG9tb2dlbm91cyBhbmQgdGh1cyBhbHNvIGhhcyBk aWZmZXJlbnQgdGltZWxpbmVzIGZvciBJUHY2LW9ubHkgdmlhYmlsaXR5LiBGb3IgZXhhbXBsZTog TGFyZ2UgY2FycmllciBXaUZpIGRlcGxveW1lbnRzIGVtcGxveSBBUHMgdGhhdCBhcmUgY2VudHJh bGx5IGNvbnRyb2xsZWQgYW5kIGVuY2Fwc3VsYXRlIGV2ZXJ5IHVzZXIgcGFja2V0IChJUHY0IGFu ZCBJUHY2KSBiYWNrIHRvIGEgV2lGaSBjb3JlICh1c3VhbGx5IHZpYSBHUkUgb3IgTDJUUCkuIFRo ZXJlJ3Mgbm8gcmVhc29uIHdoeSB0aGF0IG5ldHdvcmssIGluY2x1ZGluZyB0aGUgYmFja2JvbmUg dGhhdCBpdCByaWRlcyBvbiwgY291bGRuJ3QgYmUgSVB2Ni1vbmx5IGZyb20gdGhlIEFQIHRvIHRo ZSBjb3JlIHRvbW9ycm93IGFzc3VtaW5nIHRoZSB2ZW5kb3Igc3VwcG9ydCBpcyB0aGVyZSwgYW5k IHRoZSBudW1iZXIgb2YgZGV2aWNlcyBtZWFucyB0aGF0IHJlY2xhaW1pbmcgdGhlIElQdjQgYWRk cmVzc2VzIGluIHVzZSBpcyBhdHRyYWN0aXZlLiBUaGlzIGVzc2VudGlhbGx5IGxvb2tzIGxpa2Ug eW91ciBzdGVwIDQuDQoNCkl0J3MgZ2V0dGluZyBlYXNpZXIgdG8gY29uc2lkZXIgdHJhbnNpdGlv bmluZyB0aGUgbWFuYWdlbWVudCBwbGFuZSB0byBJUHY2LW9ubHkgbm93IHRoYXQgZXF1aXBtZW50 IHZlbmRvcnMgdW5kZXJzdGFuZCB0aGF0IHdlJ3JlIHNlcmlvdXMgYWJvdXQgZG9pbmcgdGhhdCwg YW5kIEkgdGhpbmsgdGhlcmUncyB2YWx1ZSBpbiBiZWluZyBhYmxlIHRvIGRvIGl0LCBiZWNhdXNl IGFzIEkgb2JzZXJ2ZWQgaW4gT3BzZWMgeWVzdGVyZGF5LCB0aGUgQUNMcyB0aGF0IG9wZW4gdXAg ZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBtYW5hZ2VtZW50IHBsYW5lIGZvciBJUHY0IGFyZSBhIG1l c3MsIGxvdHMgb2YgYmxvY2tzLCBsb3RzIG9mIGhvbGVzIHB1bmNoZWQgZm9yIHN5c3RlbXMgdGhh dCBubyBsb25nZXIgZXhpc3QsIGxvdHMgc3R1ZmYgdGhhdCBldmVyeW9uZSBpcyBhZnJhaWQgdG8g dG91Y2ggZm9yIGZlYXIgb2YgYnJlYWtpbmcgc29tZXRoaW5nLiBJUHY2IG9mZmVycyBhIHJlc2V0 IGJ1dHRvbiwgd2hlcmUgeW91IGNhbiBleHBsaWNpdGx5IGlkZW50aWZ5IHdoYXQgbmVlZHMgdG8g YmUgdGFsa2luZyB0byB0aGUgbmV0d29yayBhbmQgcHVyZ2UgdGhlIGNydWZ0LiBJdCBhbHNvIG1h a2VzIGl0IG1vcmUgb2J2aW91cyB3aGVuIHNvbWV0aGluZyBpcyBicm9rZW4gaW4gSVB2NiwgYmVj YXVzZSB5b3VyIG1hbmFnZW1lbnQgdHJhZmZpYyBpcyBydW5uaW5nIG92ZXIgSVB2NiwgdGh1cyBj dXN0b21lci1pbXBhY3RpbmcgaXNzdWVzIGFyZSBsZXNzIGxpa2VseSB0byBiZSBtYXNrZWQgYnkg aGFwcHkgZXllYmFsbHMuIElNTywgaXQncyBhbiBpbnRlZ3JhbCBwYXJ0IG9mIHRoZSB0cmFuc2l0 aW9uIGZyb20gSVB2NiBhcyBhIHRveSAod2hlcmUgaXQncyBvayBpZiBpdCBicmVha3MpIHRvIElQ djYgYXMgbWlzc2lvbi1jcml0aWNhbCBhcyB0aGUgcHJpbWFyeSBwcm90b2NvbCBmb3IgeW91ciBu ZXR3b3JrLiBJZiB5b3UgaW5jcmVtZW50YWxseSBlbmFibGUgSVB2NiBtYW5hZ2VtZW50IHBsYW5l IHNlcnZpY2VzIG92ZXIgdGltZSwgZXZlbnR1YWxseSB5b3UgcmVhY2ggYSBwb2ludCB3aGVyZSBl dmVyeXRoaW5nIHN1cHBvcnRzIElQdjYgYW5kIHlvdSBjYW4gc3RhcnQgcHJ1bmluZyBJUHY0IGF3 YXkuDQoNClRoZSBjaGFsbGVuZ2UgZm9yIGEgdHJhbnNpdCBwcm92aWRlciB3aXRoIHRyYW5zaXRp b25pbmcgdGhlIGJhY2tib25lIHRvIElQdjYtb25seSBvbiB0aGUgY29udHJvbC9mb3J3YXJkaW5n IHBsYW5lcyBpcyB0aGF0IHVudGlsIHlvdSBoYXZlIHNvbWUgc29ydCBvZiBzb2x1dGlvbiB0aGF0 IGVuY2Fwc3VsYXRlcyBJUHY0IHRvIGEgY291cGxlIG9mIGRlZmluZWQgZXhpdCBwb2ludHMsIGFu ZCBzdGlsbCBwcm92aWRlcyBhY2Nlc3MgdG8gdGhlIGZ1bGwgSVB2NCByb3V0aW5nIHRhYmxlLCBl aXRoZXIgdmlhIHJvdXRlIHJlZmxlY3RvcnMgYW5kIG11bHRpaG9wLCBvciBhIGRpcmVjdCBwYXRo LCB5b3UncmUgc3RpbGwgc3R1Y2sgY2FycnlpbmcgdGhlIEJHUCByb3V0ZXMgYXJvdW5kIGF0IGxl YXN0IHNvbWUgcGFydHMgb2YgdGhlIG5ldHdvcmssIGFuZCBJIGRvbid0IHRoaW5rIHRoYXQgeW91 J2xsIGNvbnZpbmNlIGFueW9uZSB0aGF0IGNhcnJ5aW5nIElQdjQgTkxSSSBvdmVyIGFuIElQdjYg QkdQIHNlc3Npb24gaXMgYSBnb29kIGlkZWEgZ2l2ZW4gdGhlIGFtb3VudCBvZiBuZXh0LWhvcCBo ZWFkYWNoZXMgd2UgaGFkIHdpdGggdHJ5aW5nIHRvIGRvIHRoZSBvcHBvc2l0ZS4gVGhvdWdoIGl0 IG1heSBiZSBwb3NzaWJsZSB0byBnbyBJUCB1bm51bWJlcmVkIG9uIHRoZSBXQU4gbGlua3MsIGFu ZCBrZWVwIElQdjQgbG9vcGJhY2tzIGZvciBCR1AgcGVlcmluZywgSSdtIG5vdCBzdXJlIHRoYXQg YnV5cyB5b3UgbXVjaCBieSBpdHNlbGYuIEJlaW5nIGFibGUgdG8gZmluZCBhIHNvbHV0aW9uIHRo YXQgYWxsb3dzIHlvdSB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBwbGFjZXMgdGhhdCBoYXZlIHRv IGNhcnJ5IGEgZnVsbCBJUHY0IHJvdXRpbmcgdGFibGUgZG9lcyBoYXZlIGF0dHJhY3RpdmUgcm91 dGluZyBoYXJkd2FyZSBzY2FsaW5nIGltcGxpY2F0aW9ucywgc28gSSBkbyB0aGluayB0aGF0IHRo aXMgd2lsbCBiZSBzb21ldGhpbmcgY2FycmllcnMgYXJlIGdvaW5nIHRvIGJlIGludGVyZXN0ZWQg aW4sIGV2ZW4gaWYgaXQncyBqdXN0IGEgbW9kaWZpY2F0aW9uIG9mIHRoZSBleGlzdGluZyBsZWFu LWNvcmUgaWRlYXMuDQoNCkFzIGZhciBhcyBNUExTIGlzIGNvbmNlcm5lZCwgb25jZSB0aGUgdXNl ci1wbGFuZSB0cmFmZmljIGlzIGVpdGhlciBJUHY2IG9yIGVuY2Fwc3VsYXRlZCBJUHY0IGFuZCBh bGwgdGhhdCByZW1haW5zIHRoYXQgcmVxdWlyZXMgSVB2NCBpcyBNUExTLWJhc2VkIHNlcnZpY2Vz LCB0aGVyZSB3aWxsIGJlIGEgZGVjaXNpb24gcG9pbnQg4oCTIGRvIHlvdSB0cnkgdG8gbW92ZSB5 b3VyIE1QTFMgY29udHJvbCBwbGFuZSB0byBJUHY2LCBvciBkbyB5b3UgdHJ5IHRvIHJlcGxpY2F0 ZSB0aG9zZSBzZXJ2aWNlcyB1c2luZyBJUHY2IG5hdGl2ZWx5PyBOZWl0aGVyIG9mIHRob3NlIGFy ZSBhbnN3ZXJhYmxlIGF0IHRoZSBtb21lbnQsIGJlY2F1c2UgUkZDNzQzOSBoYXMgYSB3aG9sZSBw dW5jaCBsaXN0IG9mIHRoaW5ncyB0byBmaXggaW4gTVBMUy1sYW5kIHNvIHRoYXQgTVBMUyBpcyBu byBsb25nZXIgZGVwZW5kZW50IG9uIElQdjQsIGFuZCBJUHY2IFNlZ21lbnQgUm91dGluZyBpcyBz dGlsbCBwcmV0dHkgZmFyIGF3YXkgZnJvbSBiZWluZyBhbiBhY2NlcHRhYmxlIGFsdGVybmF0aXZl IHRvIExEUCBmb3Igb2ZmZXJpbmcgTVBMUy1saWtlIHNlcnZpY2VzLiBFaXRoZXIgd2F5LCB0aGlz IGlzIHNvbWV0aGluZyB0aGF0IElFVEYgbmVlZHMgdG8gYmUgd29ya2luZyBvbiwgc28gdGhhdCB0 aGVyZSBhcmUgc29sdXRpb25zIHJlYWR5IGJlZm9yZSBjYXJyaWVyIG5ldHdvcmtzIGdldCB0byB0 aGF0IGRlY2lzaW9uIHBvaW50LiBJRVRGJ3MgdGltZXNjYWxlcyBtZWFuIHRoYXQgd2UgbmVlZCB0 byBiZSBvdXQgYWhlYWQgb2YgdGhpcyBldmVuIGlmIGl0IHNlZW1zIGZhci1mZXRjaGVkIHJpZ2h0 IG5vdy4NCg0KVGhhbmtzLA0KDQpXZXMgR2VvcmdlDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGlu ZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSSBoYXZlIG5v IGNvbnRyb2wgb3ZlciBpdC4NCi0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBp cyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9u Z2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBh ZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBF LW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRp c3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBj b250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJv aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUt bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBw ZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFp bCBhbmQgYW55IHByaW50b3V0Lg0K --_000_D143FC8D4C060wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGRpdj5BZGRpbmcgc3Vuc2V0NCwgc2luY2UgdGhpcyBsb29rcyBhIGxv dCBsaWtlIGEgZGlzY3Vzc2lvbiBhYm91dCB0dXJuaW5nIG9mZiBJUHY0LiA6LSk8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7 IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9U VE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRP TTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9Q OiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1U T1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkNh IEJ5ICZsdDs8YSBocmVmPSJtYWlsdG86Y2IubGlzdDZAZ21haWwuY29tIj5jYi5saXN0NkBnbWFp bC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8 L3NwYW4+VHVlc2RheSwgTWFyY2ggMzEsIDIwMTUgYXQgMTE6MDYgUE08YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtGcmVkIEJha2VyIChmcmVkKSZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWRAY2lzY28uY29tIj5mcmVkQGNpc2NvLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+SVB2 NiBPcHMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8 L3NwYW4+UmU6IFt2Nm9wc10gSVB2NCB0cmFqZWN0b3J5PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGJyPg0KPGJyPg0KT24gVHVlc2RheSwgTWFyY2ggMzEsIDIwMTUsIEZyZWQgQmFr ZXIgKGZyZWQpICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZEBjaXNjby5jb20iPmZyZWRAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGlu Zy1sZWZ0OjFleCI+DQo8YnI+DQomZ3Q7IE9uIE1hciAzMSwgMjAxNSwgYXQgNToxMSBQTSwgQnJp YW4gRSBDYXJwZW50ZXIgJmx0OzxhIGhyZWY9ImphdmFzY3JpcHQ6OyIgb25jbGljaz0iX2UoZXZl bnQsICdjdm1sJywgJ2JyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbScpIj5icmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyA1LiBUaGVy ZWZvcmUsIG1pZ3JhdGUgSVB2NCBzdXBwb3J0IHRvIHJ1biBvdmVyIElQdjYuPGJyPg0KPGJyPg0K QWdhaW4sIGlmIHlvdSB3YW50IHRoZSBjYXJyaWVy4oCZcyBsb2dpYywgYXNrIHRoZSBjYXJyaWVy LiBCdXQgdG8gbWUsIHRoYXQgZG9lc27igJl0IGZvbGxvdy48YnI+DQo8YnI+DQpOb3QgYWxsIGNv cmUgY2FycmllcnMsIGJ1dCBhIHNpZ25pZmljYW50IG51bWJlciBvZiB0aGVtLCBkb27igJl0IHRo aW5rIG9mIHRoZW1zZWx2ZXMgYXMgY2FycnlpbmcgSVB2NCBvciBJUHY2IHBlciBzZS4gVGhleSB0 aGluayBvZiB0aGVtc2VsdmVzIGFzIE1QTFMgaG91c2VzLCB1c2luZyBqdW1ib2ZyYW1lcyBzbyB0 aGF0IHRoZSBhZGRpdGlvbiBvZiB0aGF0IGhlYWRlciB0byB3aGF0ZXZlciB0aGVpciBwYXlsb2Fk IGhhcHBlbnMgdG8gYmUgKGFrYSBJUHY0DQogb3IgSVB2NikgZG9lc27igJl0IGhhdmUgYW4gTVRV IHByb2JsZW0uIFdoYXRldmVyIGNvbWVzIGluLCB0aGV5IHRocm93IGl0IGludG8gdGhlIHJpZ2h0 IHR1bm5lbCAoYWthIExTUCkgdG8gZ2V0IGl0IHRvIHRoZSByaWdodCBlZ3Jlc3MsIE1QTFMgZ2V0 cyBpdCB0aGVyZSwgYW5kIGl0IGdvZXMgb3V0IHRoZSBvdGhlciBkb29yLjxicj4NCjxicj4NCllv deKAmXJlIGFyZ3VpbmcgYWJvdXQgd2hhdCBraW5kIG9mIHR1bm5lbCB0aGV5IHNob3VsZCB1c2Uu IFRoZXnigJlyZSBxdWl0ZSBoYXBweSB3aXRoIHRoZSBvbmUgdGhleSBoYXZlLCBhbmQgaXTigJlz IG5laXRoZXIgSVB2NCBub3IgSVB2Ni48L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2PldHXSB3 aGlsZSB0aGlzIGlzIHNvbWV3aGF0IHRydWUsIE1QTFMgZG9lcyBkZXBlbmQgb24gSVB2NCB0b2Rh eSwgYW5kICZxdW90O3F1aXRlIGhhcHB5JnF1b3Q7IGlzIHByb2JhYmx5IG92ZXJzZWxsaW5nIHRo aW5ncy4gTW9yZSBvbiB0aGF0IGJlbG93LjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDsgYm9yZGVyOm5vbmU7IHBhZGRpbmc6MHB4 OyI+DQo8ZGl2PkkgYW0gbm90IGEgZGZ6IG5ldHdvcmsgb3BlcmF0b3IsIGJ1dCBteSBuZXR3b3Jr IGhhcyBhbiBpcHY0IGNvbnRyb2wgcGxhbmUgdGhhdCBpcyByZmMgMTkxOCBhbmQgb25seSB2aXNp YmxlIHRvIHRoZSBjb250cm9sIHBsYW5lLCBmb3IgdGhlIG1vc3QgcGFydC4mbmJzcDsmbmJzcDtN eSBndWVzcyBpcyB0aGF0IG1vc3QgZGZ6IHByb3ZpZGVycyBhcmUgbm90IHByb3Blcmx5IGR1YWwt c3RhY2ssIHRoZXkgYXJlIHVzaW5nIDZwZSBvciA2dnBlLiAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PlRoZSBmb3J3YXJpbmcgcGxhbmUgaXMgbXBscy4gRnVsbCBzdG9wLiZu YnNwOzwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpXR10g YXMgd2l0aCBtb3N0IHRoaW5ncywgYXNrIDEwIG9wZXJhdG9ycyBhbmQgeW91J2xsIGdldCAxNSBh bnN3ZXJzLiBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIERGWiBwYXJ0IG9mICZxdW90O0RGWiBv cGVyYXRvciZxdW90OyBtYXR0ZXJzIGluIHRoaXMgZGlzY3Vzc2lvbiwgYnV0IGhlcmUncyBteSBz aXR1YXRpb24gKGxhcmdlIE1TTyB3aXRoIGEgYmFja2JvbmUpOjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPk9uIG15IG5ldHdvcmssIHdlIGFyZSBwcm9wZXJseSBk dWFsLXN0YWNrLiBMRFAgaXMgZW5hYmxlZCBiZWNhdXNlIE1QTFMgc2VydmVzIHRvIHByb3ZpZGUg YSBzZXQgb2Ygc2VydmljZXMsIG1vc3RseSBMMlZQTi4gVGh1cyBJUHY0IHVuaWNhc3QgZW5kcyB1 cCBiZWluZyBsYWJlbC1zd2l0Y2hlZC4gQnV0IHdlJ3JlIHN0aWxsIHJ1bm5pbmcgbmF0aXZlIGZv cndhcmRpbmcgZm9yIG11bHRpY2FzdA0KIChvZiB3aGljaCB0aGVyZSBpcyBxdWl0ZSBhIGxvdCBz aW5jZSBpdCdzIGhvdyB3ZSBkaXN0cmlidXRlIHZpZGVvKSBhbmQgZm9yIElQdjYuJm5ic3A7PC9m b250PjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46 MCAwIDAgNDBweDsgYm9yZGVyOm5vbmU7IHBhZGRpbmc6MHB4OyI+DQo8ZGl2PlRoZXJlIGlzIG5v IHByZXNzdXJlIHRvIGV2ZXIgY2hhbmdlIHRoZSBjb21wb3NpdGlvbiBvZiB0aGUgYmFja2JvbmUg c2luY2UgdGhlIGJhY2tib25lIGl0c2VsZiBpcyBub3Qgc2NhbGluZyBxdWlja2x5IGluIHRlcm1z IG9mIGlwIGFkZHJlc3MgdXNhZ2UuDQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldHXSB5ZXMsIGdyb3d0aCBvZiBhZGRyZXNzIHVzYWdlIGlu IHRoZSBiYWNrYm9uZSBpc24ndCB0aGUgZHJpdmVyLiBCdXQgSSBkaXNhZ3JlZSB0aGF0IHRoZXJl J3Mgbm8gcHJlc3N1cmUuIFRoZXJlIGlzIGEgbm9uLXRyaXZpYWwgaW5jcmVtZW50YWwgY29zdCBm b3Igb3BlcmF0aW9ucyB0byBtYW5hZ2UgYSBkdWFsLXN0YWNrIG5ldHdvcmsgdnMgYSBzaW5nbGUt c3RhY2sgb25lIGJlY2F1c2UgbXVjaCBvZiB0aGUgY29uZmlndXJhdGlvbiBhbmQNCiB0cm91Ymxl c2hvb3RpbmcgaXMgYWRkcmVzcy1mYW1pbHkgc3BlY2lmaWMgZXZlbiBpZiB0aGVyZSBhcmUgYSBs b3Qgb2Ygc2ltaWxhcml0aWVzIGFuZCByZXVzYWJsZSBiaXRzLCBhbmQgdGhlcmUgYXJlIGEgd2hv bGUgcmFmdCBvZiBoYXJkd2FyZS9zb2Z0d2FyZSB0ZXN0IGNhc2VzIGFyb3VuZCBrZWVwaW5nIElQ djQgd29ya2luZyB0aGF0IEkgY291bGQgZXZlbnR1YWxseSBqZXR0aXNvbiBpZiBJIGRpZG4ndCBu ZWVkIElQdjQgb24gcGFydHMgb2YNCiBteSBuZXR3b3JrLiBCdXQgcmVhbGx5LCB0aGUgcHJlc3N1 cmUgdG8gY2hhbmdlIHRoZSBjb21wb3NpdGlvbiBvZiB0aGUgYmFja2JvbmUgY29tZXMgZnJvbSB0 d28gdGhpbmdzOjwvZGl2Pg0KPG9sPg0KPGxpPklQdjQgR1VBcyBhcmUgZm9yIGN1c3RvbWVycy4g V2hpbGUgdGhlcmUgaXNuJ3QgYSBsb3Qgb2YgSVB2NCBuZWVkZWQgdG8gbnVtYmVyIHRoZSBiYWNr Ym9uZSwgZGVwZW5kaW5nIG9uIG5ldCBjdXN0b21lciBncm93dGggcmF0ZSBhbmQgdGhlIGNvc3Qg b2YgYWRkcmVzc2VzLCB0aGUgdmFsdWUgb2YgcmVjbGFpbWluZyBzZXZlcmFsIGJsb2NrcyBvZiBJ UHY0IGFkZHJlc3NlcyBmcm9tIHlvdXIgaW5mcmFzdHJ1Y3R1cmUgY291bGQgYmUgc2lnbmlmaWNh bnQNCiAoZG9lcyBpdCBidXkgeW91IGVub3VnaCB0aW1lIHRvIGF2b2lkIHRoYXQgbmV4dCBpbnZl c3RtZW50IGluIGFkZHJlc3NlcyBvciBDR04/KS4gSG93ZXZlciwgSSBkbyB0aGluayB0aGF0IHRo ZSBiYWNrYm9uZSB3aWxsIGJlIGFtb25nIHRoZSBsYXN0IHBsYWNlcyB0aGF0IHJlY2xhbWF0aW9u IGhhcHBlbnMsIGZvciByZWFzb25zIEknbGwgZGV0YWlsIGJlbG93LjwvbGk+PGxpPlJGQzE5MTgg aXMgYWxzbyBleGhhdXN0ZWQsIHNvIGl0J3Mgbm90IGEgdmlhYmxlIGFsdGVybmF0aXZlLiBJJ20g ZGVwbG95aW5nIGxhcmdlIGFtb3VudHMgb2YgSVB2Ni1vbmx5IGdlYXIgdG9kYXkgYmVjYXVzZSBJ IGhhdmUgTyhtaWxsaW9ucykgb2YgZGV2aWNlcyB0aGF0IG5lZWQgYWRkcmVzc2VzIGZvciBtYW5h Z2VtZW50IGFuZCBpbnRlcm5hbCBzdHVmZiBmb3Igd2hpY2ggSSBjYW4gZWl0aGVyIHdhc3RlIEdV QSwgcmV1c2UgUkZDMTkxOA0KIG1hbnkgdGltZXMgYW5kIGRlYWwgd2l0aCB0aGUgYXR0ZW5kYW50 IGhlYWRhY2hlcywgb3IganVzdCBtb3ZlIGl0IHRvIElQdjYuPC9saT48L29sPg0KPGRpdj5UaGUg cHJvYmxlbSB3aXRoIHRoaXMgY29udmVyc2F0aW9uIGlzIHRoYXQgd2UncmUgc3RpbGwgdHJlYXRp bmcgdGhpcyBhcyBhbiBhbGwtb3Itbm90aGluZyBleGVyY2lzZSwgYW5kIHRodXMgY29uZmxhdGlu ZyBmb3J3YXJkaW5nLCBjb250cm9sLCBhbmQgbWFuYWdlbWVudCwgdGhvdWdoIGVhY2ggaGFzIGl0 cyBvd24gdGltZWxpbmUgZm9yIG1vdmluZyB0byBJUHY2LW9ubHksIGFuZCB3ZSBhcmUgYWxzbyBh cnRpZmljaWFsbHkgY29uc3RyYWluaW5nDQogdGhpcyB0byBzb21lIGRlZmluaXRpb24gb2YgYmFj a2JvbmUsIHJhdGhlciB0aGFuIHRoZSBvdmVyYWxsIGluZnJhc3RydWN0dXJlIGluIGEgZ2l2ZW4g Y2Fycmllciwgd2hpY2ggaXMgbm90IGhvbW9nZW5vdXMgYW5kIHRodXMgYWxzbyBoYXMgZGlmZmVy ZW50IHRpbWVsaW5lcyBmb3IgSVB2Ni1vbmx5IHZpYWJpbGl0eS4gRm9yIGV4YW1wbGU6IExhcmdl IGNhcnJpZXIgV2lGaSBkZXBsb3ltZW50cyBlbXBsb3kgQVBzIHRoYXQgYXJlIGNlbnRyYWxseQ0K IGNvbnRyb2xsZWQgYW5kIGVuY2Fwc3VsYXRlIGV2ZXJ5IHVzZXIgcGFja2V0IChJUHY0IGFuZCBJ UHY2KSBiYWNrIHRvIGEgV2lGaSBjb3JlICh1c3VhbGx5IHZpYSBHUkUgb3IgTDJUUCkuIFRoZXJl J3Mgbm8gcmVhc29uIHdoeSB0aGF0IG5ldHdvcmssIGluY2x1ZGluZyB0aGUgYmFja2JvbmUgdGhh dCBpdCByaWRlcyBvbiwgY291bGRuJ3QgYmUgSVB2Ni1vbmx5IGZyb20gdGhlIEFQIHRvIHRoZSBj b3JlIHRvbW9ycm93IGFzc3VtaW5nIHRoZSB2ZW5kb3INCiBzdXBwb3J0IGlzIHRoZXJlLCBhbmQg dGhlIG51bWJlciBvZiBkZXZpY2VzIG1lYW5zIHRoYXQgcmVjbGFpbWluZyB0aGUgSVB2NCBhZGRy ZXNzZXMgaW4gdXNlIGlzIGF0dHJhY3RpdmUuIFRoaXMgZXNzZW50aWFsbHkgbG9va3MgbGlrZSB5 b3VyIHN0ZXAgNC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pkl0J3MgZ2V0dGluZyBl YXNpZXIgdG8gY29uc2lkZXIgdHJhbnNpdGlvbmluZyB0aGUgbWFuYWdlbWVudCBwbGFuZSB0byBJ UHY2LW9ubHkgbm93IHRoYXQgZXF1aXBtZW50IHZlbmRvcnMgdW5kZXJzdGFuZCB0aGF0IHdlJ3Jl IHNlcmlvdXMgYWJvdXQgZG9pbmcgdGhhdCwgYW5kIEkgdGhpbmsgdGhlcmUncyB2YWx1ZSBpbiBi ZWluZyBhYmxlIHRvIGRvIGl0LCBiZWNhdXNlIGFzIEkgb2JzZXJ2ZWQgaW4gT3BzZWMgeWVzdGVy ZGF5LCB0aGUgQUNMcw0KIHRoYXQgb3BlbiB1cCBkaWZmZXJlbnQgcGFydHMgb2YgdGhlIG1hbmFn ZW1lbnQgcGxhbmUgZm9yIElQdjQgYXJlIGEgbWVzcywgbG90cyBvZiBibG9ja3MsIGxvdHMgb2Yg aG9sZXMgcHVuY2hlZCBmb3Igc3lzdGVtcyB0aGF0IG5vIGxvbmdlciBleGlzdCwgbG90cyBzdHVm ZiB0aGF0IGV2ZXJ5b25lIGlzIGFmcmFpZCB0byB0b3VjaCBmb3IgZmVhciBvZiBicmVha2luZyBz b21ldGhpbmcuIElQdjYgb2ZmZXJzIGEgcmVzZXQgYnV0dG9uLCB3aGVyZQ0KIHlvdSBjYW4gZXhw bGljaXRseSBpZGVudGlmeSB3aGF0IG5lZWRzIHRvIGJlIHRhbGtpbmcgdG8gdGhlIG5ldHdvcmsg YW5kIHB1cmdlIHRoZSBjcnVmdC4gSXQgYWxzbyBtYWtlcyBpdCBtb3JlIG9idmlvdXMgd2hlbiBz b21ldGhpbmcgaXMgYnJva2VuIGluIElQdjYsIGJlY2F1c2UgeW91ciBtYW5hZ2VtZW50IHRyYWZm aWMgaXMgcnVubmluZyBvdmVyIElQdjYsIHRodXMgY3VzdG9tZXItaW1wYWN0aW5nIGlzc3VlcyBh cmUgbGVzcyBsaWtlbHkgdG8NCiBiZSBtYXNrZWQgYnkgaGFwcHkgZXllYmFsbHMuIElNTywgaXQn cyBhbiBpbnRlZ3JhbCBwYXJ0IG9mIHRoZSB0cmFuc2l0aW9uIGZyb20gSVB2NiBhcyBhIHRveSAo d2hlcmUgaXQncyBvayBpZiBpdCBicmVha3MpIHRvIElQdjYgYXMgbWlzc2lvbi1jcml0aWNhbCBh cyB0aGUgcHJpbWFyeSBwcm90b2NvbCBmb3IgeW91ciBuZXR3b3JrLiBJZiB5b3UgaW5jcmVtZW50 YWxseSBlbmFibGUgSVB2NiBtYW5hZ2VtZW50IHBsYW5lIHNlcnZpY2VzIG92ZXINCiB0aW1lLCBl dmVudHVhbGx5IHlvdSByZWFjaCBhIHBvaW50IHdoZXJlIGV2ZXJ5dGhpbmcgc3VwcG9ydHMgSVB2 NiBhbmQgeW91IGNhbiBzdGFydCBwcnVuaW5nIElQdjQgYXdheS4mbmJzcDs8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBjaGFsbGVuZ2UgZm9yIGEgdHJhbnNpdCBwcm92aWRlciB3 aXRoIHRyYW5zaXRpb25pbmcgdGhlIGJhY2tib25lIHRvIElQdjYtb25seSBvbiB0aGUgY29udHJv bC9mb3J3YXJkaW5nIHBsYW5lcyBpcyB0aGF0IHVudGlsIHlvdSBoYXZlIHNvbWUgc29ydCBvZiBz b2x1dGlvbiB0aGF0IGVuY2Fwc3VsYXRlcyBJUHY0IHRvIGEgY291cGxlIG9mIGRlZmluZWQgZXhp dCBwb2ludHMsIGFuZCBzdGlsbCBwcm92aWRlcyBhY2Nlc3MgdG8gdGhlDQogZnVsbCBJUHY0IHJv dXRpbmcgdGFibGUsIGVpdGhlciB2aWEgcm91dGUgcmVmbGVjdG9ycyBhbmQgbXVsdGlob3AsIG9y IGEgZGlyZWN0IHBhdGgsIHlvdSdyZSBzdGlsbCBzdHVjayBjYXJyeWluZyB0aGUgQkdQIHJvdXRl cyBhcm91bmQgYXQgbGVhc3Qgc29tZSBwYXJ0cyBvZiB0aGUgbmV0d29yaywgYW5kIEkgZG9uJ3Qg dGhpbmsgdGhhdCB5b3UnbGwgY29udmluY2UgYW55b25lIHRoYXQgY2FycnlpbmcgSVB2NCBOTFJJ IG92ZXIgYW4gSVB2NiBCR1ANCiBzZXNzaW9uIGlzIGEgZ29vZCBpZGVhIGdpdmVuIHRoZSBhbW91 bnQgb2YgbmV4dC1ob3AgaGVhZGFjaGVzIHdlIGhhZCB3aXRoIHRyeWluZyB0byBkbyB0aGUgb3Bw b3NpdGUuIFRob3VnaCBpdCBtYXkgYmUgcG9zc2libGUgdG8gZ28gSVAgdW5udW1iZXJlZCBvbiB0 aGUgV0FOIGxpbmtzLCBhbmQga2VlcCBJUHY0IGxvb3BiYWNrcyBmb3IgQkdQIHBlZXJpbmcsIEkn bSBub3Qgc3VyZSB0aGF0IGJ1eXMgeW91IG11Y2ggYnkgaXRzZWxmLiBCZWluZyBhYmxlDQogdG8g ZmluZCBhIHNvbHV0aW9uIHRoYXQgYWxsb3dzIHlvdSB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBw bGFjZXMgdGhhdCBoYXZlIHRvIGNhcnJ5IGEgZnVsbCBJUHY0IHJvdXRpbmcgdGFibGUgZG9lcyBo YXZlIGF0dHJhY3RpdmUgcm91dGluZyBoYXJkd2FyZSBzY2FsaW5nIGltcGxpY2F0aW9ucywgc28g SSBkbyB0aGluayB0aGF0IHRoaXMgd2lsbCBiZSBzb21ldGhpbmcgY2FycmllcnMgYXJlIGdvaW5n IHRvIGJlIGludGVyZXN0ZWQgaW4sIGV2ZW4NCiBpZiBpdCdzIGp1c3QgYSBtb2RpZmljYXRpb24g b2YgdGhlIGV4aXN0aW5nIGxlYW4tY29yZSBpZGVhcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkFzIGZhciBhcyBNUExTIGlzIGNvbmNlcm5lZCwgb25jZSB0aGUgdXNlci1wbGFuZSB0 cmFmZmljIGlzIGVpdGhlciBJUHY2IG9yIGVuY2Fwc3VsYXRlZCBJUHY0IGFuZCBhbGwgdGhhdCBy ZW1haW5zIHRoYXQgcmVxdWlyZXMgSVB2NCBpcyBNUExTLWJhc2VkIHNlcnZpY2VzLCB0aGVyZSB3 aWxsIGJlIGEgZGVjaXNpb24gcG9pbnQg4oCTIGRvIHlvdSB0cnkgdG8gbW92ZSB5b3VyIE1QTFMg Y29udHJvbCBwbGFuZSB0byBJUHY2LCBvciBkbyB5b3UNCiB0cnkgdG8gcmVwbGljYXRlIHRob3Nl IHNlcnZpY2VzIHVzaW5nIElQdjYgbmF0aXZlbHk/IE5laXRoZXIgb2YgdGhvc2UgYXJlIGFuc3dl cmFibGUgYXQgdGhlIG1vbWVudCwgYmVjYXVzZSBSRkM3NDM5IGhhcyBhIHdob2xlIHB1bmNoIGxp c3Qgb2YgdGhpbmdzIHRvIGZpeCBpbiBNUExTLWxhbmQgc28gdGhhdCBNUExTIGlzIG5vIGxvbmdl ciBkZXBlbmRlbnQgb24gSVB2NCwgYW5kIElQdjYgU2VnbWVudCBSb3V0aW5nIGlzIHN0aWxsIHBy ZXR0eSBmYXINCiBhd2F5IGZyb20gYmVpbmcgYW4gYWNjZXB0YWJsZSBhbHRlcm5hdGl2ZSB0byBM RFAgZm9yIG9mZmVyaW5nIE1QTFMtbGlrZSBzZXJ2aWNlcy4gRWl0aGVyIHdheSwgdGhpcyBpcyBz b21ldGhpbmcgdGhhdCBJRVRGIG5lZWRzIHRvIGJlIHdvcmtpbmcgb24sIHNvIHRoYXQgdGhlcmUg YXJlIHNvbHV0aW9ucyByZWFkeSBiZWZvcmUgY2FycmllciBuZXR3b3JrcyBnZXQgdG8gdGhhdCBk ZWNpc2lvbiBwb2ludC4gSUVURidzIHRpbWVzY2FsZXMgbWVhbiB0aGF0DQogd2UgbmVlZCB0byBi ZSBvdXQgYWhlYWQgb2YgdGhpcyBldmVuIGlmIGl0IHNlZW1zIGZhci1mZXRjaGVkIHJpZ2h0IG5v dy48L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7Ij5XZXMgR2VvcmdlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48 YnI+DQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMjcsIDEy NywgMTI3KTsiPkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBj b21wYW554oCZcyBtYWlsIHNlcnZlciwgSSBoYXZlIG5vIGNvbnRyb2wgb3ZlciBpdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigx MjcsIDEyNywgMTI3KTsiPi0tLS0tLS0tLS0tPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjwvc3Bhbj48YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9Ikdy YXkiIHNpemU9IjEiPlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBp cyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9u Z2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5 DQogZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlz IGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlz IEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhl IGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBF LW1haWwgYW5kIGFueSBwcmludG91dC48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D143FC8D4C060wesleygeorgetwcablecom_-- From nobody Fri Apr 3 07:08: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 353C81AC3A0; Fri, 3 Apr 2015 07:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.365 X-Spam-Level: **** X-Spam-Status: No, score=4.365 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 y2GbW4MSEbps; Fri, 3 Apr 2015 07:08:41 -0700 (PDT) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id CBE1C1AC39C; Fri, 3 Apr 2015 07:08:40 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,517,1422939600"; d="scan'208,217";a="279673582" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Apr 2015 10:01:02 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 3 Apr 2015 10:08:39 -0400 From: "George, Wes" To: Ca By , IPv6 Ops WG Date: Fri, 3 Apr 2015 10:08:38 -0400 Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AdBuF644V3CcDbzaRjSAYhfCS60Dlg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D14414A14C161wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "sunset4@ietf.org" Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 14:08:44 -0000 --_000_D14414A14C161wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdhaW4gK1N1bnNldDQuDQoNCkNhbWVyb24sIHBlcmhhcHMgeW91IHdhbnQgdG8gc3VnZ2VzdCB0 ZXh0IChvciBtb2RpZnkgd2hhdCB5b3UndmUgd3JpdHRlbiBiZWxvdykgdG8gYm9sc3RlciBzZWN0 aW9uIDcgb2YgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3Vuc2V0NC1n YXBhbmFseXNpcy0wNiBpbmNsdWRpbmcgdGhlIGFkZGl0aW9uIG9mIGEgcmVjb21tZW5kYXRpb24g YXJvdW5kIElQdjYtb25seSArIElQdjQgaG9zdCBzb2NrZXQgc3VwcG9ydD8gSSB0aGluayB0aGF0 J2QgYmUgYSB1c2VmdWwgYWRkaXRpb24gdG8gdGhlIGRvY3VtZW50LCBidXQgYW0gYWxzbyBvcGVu IHRvIGEgZGlzY3Vzc2lvbiBpbiBzdW5zZXQ0IGFib3V0IGEgc3RhbmRhbG9uZSBCQ1AgZG9jdW1l bnQgY292ZXJpbmcgdGhpcyBzcGVjaWZpYyBpc3N1ZSB0aGF0IGlzIHNpbXBseSByZWZlcmVuY2Vk IGZyb20gdGhlIGdhcCBhbmFseXNpcy4NCg0KVGhhbmtzLA0KDQpXZXMgR2VvcmdlLCB3ZWFyaW5n IGhpcyBTdW5zZXQ0IFdHIGNoYWlyIGNvd2JveSBoYXQNCg0KDQpGcm9tOiBDYSBCeSA8Y2IubGlz dDZAZ21haWwuY29tPG1haWx0bzpjYi5saXN0NkBnbWFpbC5jb20+Pg0KRGF0ZTogVGh1cnNkYXks IE1hcmNoIDE5LCAyMDE1IGF0IDU6MjcgUE0NClRvOiBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4NClN1YmplY3Q6IFt2Nm9wc10gVGhlIG5lZWQgZm9y IGxvY2FsLWlwdjQgc29ja2V0IHRyYW5zaXRpb24gc29sdXRpb25zIC0tIE5BVDY0L0ROUzY0IHJl bWFpbnMgaW5zdWZmaWNpZW50DQoNCkhpIEZvbGtzLA0KDQpUaGUgcG9pbnQgb2YgdGhpcyBtZXNz YWdlIGlzIHRvIGRpc2N1c3MgdGhlIHVzZSBvZiBJUHY0IGxpdGVyYWxzIGFuZCBob3cgdGhpcyB1 c2UgcmVxdWlyZXMgdHJhbnNpdGlvbiBzb2x1dGlvbnMgc3VjaCBhcyBNQVAsIERTLUxpdGUsIGFu ZCA0NjRYTEFUIC0tIGFsbCBvZiB3aGljaCBwcm92aWRlIGxvY2FsIElQdjQgc29ja2V0IHN1cHBv cnQgdG8gdGhlIGhvc3QuICBJZiB0aGUgcHJpbWFyeSBvcGVyYXRpbmcgZW52aXJvbm1lbnQgb2Yg dGhlIGhvc3QgaXMgdGhlICJpbnRlcm5ldCIsIGFuZCB0aGUgIndlYiIgaXMgYSBoaWdobHkgdmFs dWFibGUgcGFydCBvZiB0aGUgdGhhdCBvcGVyYXRpbmcgZW52aXJvbm1lbnQsIHRoZW4gbG9jYWwg SVB2NCBzb2NrZXQgc3VwcG9ydCBpcyBzdGlsbCByZXF1aXJlZC4NCg0KU3BlY2lmaWNhbGx5LCB0 aGlzIG5vdGUgYnVpbGRzIHRoZSBjYXNlIHRoYXQgTkFUNjQvRE5TNjQgYWxvbmUgaXMgc3RpbGwg KGF0IHRoaXMgdGltZSkgbm90IGEgc3VmZmljaWVudCBzb2x1dGlvbiBmb3IgY29uc3VtZXIgSW50 ZXJuZXQgYWNjZXNzIGJ5IGNyZWF0aW5nIGFuIElQdjYtb25seSBuZXR3b3JrIGFzIGRlc2NyaWJl ZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0NCNzZWN0aW9uLTIuMQ0KDQpF bXBpcmljYWxseSwgaXQgaXMgY29tbW9ubHkga25vdyB0aGF0IElQdjQgYWRkcmVzc2VzIGFyZSB1 c2VkIG9uIHRoZSBJbnRlcm5ldCwgZGVzcGl0ZSB0aGUgZ3VpZGFuY2UgaW4gUkZDMTk1OCAoaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzE5NTgjc2VjdGlvbi00KS4gIE9uZSBjb21tb24g ZXhhbXBsZSBpcyBlbnRlcnByaXNlIFZQTiBzZXJ2aWNlcy4NCg0KUXVhbnRpdGF0aXZlbHksIGl0 IGlzIGVhc3kgdG8gZ2VuZXJhdGUgaW5mb3JtYXRpb24gYWJvdXQgaG93IGZyZXF1ZW50bHkgSVB2 NCBhZGRyZXNzIGxpdGVyYWxzIGFyZSB1c2VkIG9uIHRoZSB3ZWIuDQoNClNldmVyYWwgeWVhcnMg YWdvLCBkcmFmdC13aW5nLWJlaGF2ZS1odHRwLWlwLWFkZHJlc3MtbGl0ZXJhbHMtMDIgc2hhcmVk IGEgc2ltcGxlIG1ldGhvZCB0byBnYXRoZXJpbmcgdGhlIGRhdGEgYW5kIHJlcG9ydGVkIHRoYXQg Mi4zOCUgb2YgdGhlIHRvcCAxIG1pbGxpb24gd2ViIHBhZ2VzIGhhdmUgSVB2NCBsaXRlcmFscyBp biB0aGVpciBob21lcGFnZS4gIEkgcmUtcmFuIGEgc2ltaWxhciB0ZXN0IHRoaXMgd2VlayB0aGF0 IHlpZWxkZWQgMS4zOSUgb2YgdGhlIHRvcCAxIG1pbGxpb24gd2ViIHBhZ2VzIGhhdmluZyBJUHY0 IGxpdGVyYWxzLiAgIE15IHRlc3QsIGxpa2UgRGFuJ3MsIG9ubHkgbG9va3MgYXQgdGhlIEhUTUwg b24gdGhlIGhvbWUgcGFnZSBhbmQgdGh1cyB1bmRlci1jb3VudHMgbGl0ZXJhbHMgaW4gZGVlcGVy IGxpbmtzIG9yIGxvYWRlZCB2aWEgQ1NTLCBYTUwsIG9yIEphdmFzY3JpcHQuDQoNClRocm91Z2gg b3RoZXIgbWFudWFsIHRlc3RpbmcgIGkgaGF2ZSBzZWVuIGNhdGFzdHJvcGhpYyBmYWlsdXJlIGlu IEFtYXpvbidzIHZpZGVvIHN0cmVhbWluZyBzZXJ2aWNlIHdpdGggdGhlbSBwYXNzaW5nIGxpdGVy YWxzIGluIFhNTC4gIEZhY2Vib29rIHBhc3NlcyBJUHY0IGxpdGVyYWxzIGluIEphdmFzY3JpcHQs IGJ1dCBpcyBub3QgaW1wYWN0aW5nIHRoZSBwYWdlIGxvYWQuDQoNCkkgcG9zdGVkIElQdjQgbGl0 ZXJhbHMgZm91bmQgaW4gdGhlIEhUTUwgaG9tZXBhZ2Ugb2YgdGhlc2UgMiwyMjAgb2YgdGhlIHRv cCAxMDAsMDAwIEFsZXhhIGRvbWFpbnMgaGVyZSBodHRwczovL3NpdGVzLmdvb2dsZS5jb20vc2l0 ZS90bW9pcHY2L2lwdjRsaXRlcmFscw0KDQpNeSBjb25jbHVzaW9uIGlzIHRoYXQgaXQgaXMgbm90 IGZlYXNpYmxlIGZvciBhIG5ldHdvcmsgb3BlcmF0b3IgdG8gZGVwbG95IGEgcHVyZWx5IElQdjYt b25seSBzb2NrZXQgc29sdXRpb24uICBBcyBoYXMgYmVlbiBwcmV2aW91c2x5IGV4cGxvcmVkLCBh Ym91dCAyMCUgb2YgdGhlIGFwcHMgaW4gdGhlIEdvb2dsZSBhbmQgQXBwbGUgImFwcCBzdG9yZSIg Y2Fubm90IGZ1bmN0aW9uIG9uIElQdjYtb25seSArIE5BVDY0L0ROUzY0LiAgRXZlbiBpZiB0aGVz ZSAiYXBwIHN0b3JlcyIgd2VyZSBwb2xpY2VkIHRvIGZvcmNlIGFsbCBhcHBsaWNhdGlvbnMgdG8g YmUgQWRkcmVzcyBGYW1pbHkgYWdub3N0aWMsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBwb2xpY2Ug dGhlIHdvcmxkIHdpZGUgd2ViIG9yIGVudGVycHJpc2UgVlBOIG9yIFNJUCBQaG9uZXMuICBBbnkg bmV0d29yayBvcGVyYXRvciB0aGF0IGF0dGVtcHQgdG8gZG8gdGhpcyB3b3VsZCBoYXZlIHRvIGFj Y2VwdCBhdCBsZWFzdCAxLjM5JSBmYWlsdXJlIHRvIHRoZSB0b3RhbCB3ZWIgYW5kIHBlcmhhcHMg YWNjZXB0IGZhaWx1cmUgdG8gc29tZSBtYWpvciBzZXJ2aWNlcyAobGlrZSBBbWF6b24gc3RyZWFt aW5nKS4NCg0KSSBiZWxpZXZlIHdlIGFyZSBiZXlvbmQgdGhlIHBvaW50IG9mIGJsYW1pbmcgdGhl IHdvcmxkIGZvciB1c2luZyBJUHY0IGxpdGVyYWxzIC8gcmVmZXJyYWxzLiAgV2UganVzdCBuZWVk IHRvIGJlIHJlYWxpc3RpYyB0aGF0IGludGVybmV0IHNlcnZpY2UgcmVxdWlyZXMgSVB2NCBzb2Nr ZXRzLCBhbmQgdGh1cyBSRkM2MTQ0ICMyLjEgaXMgbm90IHRvZGF5IGEgY29uc3VtZXIgZ3JhZGUg c2VydmljZS4gIEEgd2lsZCBndWVzcyBpcyB0aGF0IGl0IHRoaXMgc2l0dWF0aW9uIHdpbGwgbm90 IG1lYW5pbmdmdWxseSBpbXByb3ZlIChyaXNrIHJlZHVjZWQgdG8gfjApIGZvciAxMCsgeWVhcnMu DQoNClRob3VnaHRzPw0KDQpDQg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1l IFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdl ZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGlt ZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24s IGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2Yg YW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkg ZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBw cmludG91dC4NCg== --_000_D14414A14C161wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+QWdh aW4gJiM0MztTdW5zZXQ0LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2Ft ZXJvbiwgcGVyaGFwcyB5b3Ugd2FudCB0byBzdWdnZXN0IHRleHQgKG9yIG1vZGlmeSB3aGF0IHlv dSd2ZSB3cml0dGVuIGJlbG93KSB0byBib2xzdGVyIHNlY3Rpb24gNyBvZiZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXN1bnNldDQtZ2FwYW5hbHlz aXMtMDYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXN1bnNldDQtZ2Fw YW5hbHlzaXMtMDY8L2E+Jm5ic3A7aW5jbHVkaW5nDQogdGhlIGFkZGl0aW9uIG9mIGEgcmVjb21t ZW5kYXRpb24gYXJvdW5kIElQdjYtb25seSAmIzQzOyBJUHY0IGhvc3Qgc29ja2V0IHN1cHBvcnQ/ IEkgdGhpbmsgdGhhdCdkIGJlIGEgdXNlZnVsIGFkZGl0aW9uIHRvIHRoZSBkb2N1bWVudCwgYnV0 IGFtIGFsc28gb3BlbiB0byBhIGRpc2N1c3Npb24gaW4gc3Vuc2V0NCBhYm91dCBhIHN0YW5kYWxv bmUgQkNQIGRvY3VtZW50IGNvdmVyaW5nIHRoaXMgc3BlY2lmaWMgaXNzdWUgdGhhdCBpcyBzaW1w bHkgcmVmZXJlbmNlZA0KIGZyb20gdGhlIGdhcCBhbmFseXNpcy4mbmJzcDs8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij5X ZXMgR2VvcmdlLCB3ZWFyaW5nIGhpcyBTdW5zZXQ0IFdHIGNoYWlyIGNvd2JveSBoYXQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQt YWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Q2EgQnkgJmx0OzxhIGhyZWY9Im1haWx0 bzpjYi5saXN0NkBnbWFpbC5jb20iPmNiLmxpc3Q2QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgTWFyY2gg MTksIDIwMTUgYXQgNToyNyBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPklQdjYgT3BzIFdHICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmci PnY2b3BzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U3ViamVjdDogPC9zcGFuPlt2Nm9wc10gVGhlIG5lZWQgZm9yIGxvY2FsLWlwdjQgc29ja2V0 IHRyYW5zaXRpb24gc29sdXRpb25zIC0tIE5BVDY0L0ROUzY0IHJlbWFpbnMgaW5zdWZmaWNpZW50 PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+SGkgRm9sa3Ms DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgcG9pbnQgb2YgdGhpcyBtZXNzYWdlIGlzIHRv IGRpc2N1c3MgdGhlIHVzZSBvZiBJUHY0IGxpdGVyYWxzIGFuZCBob3cgdGhpcyB1c2UgcmVxdWly ZXMgdHJhbnNpdGlvbiBzb2x1dGlvbnMgc3VjaCBhcyBNQVAsIERTLUxpdGUsIGFuZCA0NjRYTEFU IC0tIGFsbCBvZiB3aGljaCBwcm92aWRlIGxvY2FsIElQdjQgc29ja2V0IHN1cHBvcnQgdG8gdGhl IGhvc3QuJm5ic3A7IElmIHRoZSBwcmltYXJ5IG9wZXJhdGluZyBlbnZpcm9ubWVudCBvZiB0aGUN CiBob3N0IGlzIHRoZSAmcXVvdDtpbnRlcm5ldCZxdW90OywgYW5kIHRoZSAmcXVvdDt3ZWImcXVv dDsgaXMgYSBoaWdobHkgdmFsdWFibGUgcGFydCBvZiB0aGUgdGhhdCBvcGVyYXRpbmcgZW52aXJv bm1lbnQsIHRoZW4gbG9jYWwgSVB2NCBzb2NrZXQgc3VwcG9ydCBpcyBzdGlsbCByZXF1aXJlZC48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNwZWNpZmljYWxseSwgdGhpcyBub3RlIGJ1 aWxkcyB0aGUgY2FzZSB0aGF0IE5BVDY0L0ROUzY0IGFsb25lIGlzIHN0aWxsIChhdCB0aGlzIHRp bWUpIG5vdCBhIHN1ZmZpY2llbnQgc29sdXRpb24gZm9yIGNvbnN1bWVyIEludGVybmV0IGFjY2Vz cyBieSBjcmVhdGluZyBhbiBJUHY2LW9ubHkgbmV0d29yayBhcyBkZXNjcmliZWQgaW4mbmJzcDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE0NCNzZWN0aW9uLTIuMSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTQ0I3NlY3Rp b24tMi4xPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RW1waXJpY2FsbHksIGl0 IGlzIGNvbW1vbmx5IGtub3cgdGhhdCBJUHY0IGFkZHJlc3NlcyBhcmUgdXNlZCBvbiB0aGUgSW50 ZXJuZXQsIGRlc3BpdGUgdGhlIGd1aWRhbmNlIGluIFJGQzE5NTggKDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMxOTU4I3NlY3Rpb24tNCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMxOTU4I3NlY3Rpb24tNDwvYT4pLiZuYnNwOyBP bmUgY29tbW9uIGV4YW1wbGUNCiBpcyBlbnRlcnByaXNlIFZQTiBzZXJ2aWNlcy48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlF1YW50aXRhdGl2ZWx5LCBpdCBpcyBlYXN5IHRvIGdlbmVy YXRlIGluZm9ybWF0aW9uIGFib3V0IGhvdyBmcmVxdWVudGx5IElQdjQgYWRkcmVzcyBsaXRlcmFs cyBhcmUgdXNlZCBvbiB0aGUgd2ViLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2PlNldmVyYWwgeWVhcnMgYWdvLCBkcmFmdC13aW5nLWJlaGF2ZS1odHRwLWlwLWFkZHJlc3Mt bGl0ZXJhbHMtMDIgc2hhcmVkIGEgc2ltcGxlIG1ldGhvZCB0byBnYXRoZXJpbmcgdGhlIGRhdGEg YW5kIHJlcG9ydGVkIHRoYXQgMi4zOCUgb2YgdGhlIHRvcCAxIG1pbGxpb24gd2ViIHBhZ2VzIGhh dmUgSVB2NCBsaXRlcmFscyBpbiB0aGVpciBob21lcGFnZS4mbmJzcDsgSSByZS1yYW4gYSBzaW1p bGFyIHRlc3QgdGhpcyB3ZWVrIHRoYXQgeWllbGRlZCAxLjM5JQ0KIG9mIHRoZSB0b3AgMSBtaWxs aW9uIHdlYiBwYWdlcyBoYXZpbmcgSVB2NCBsaXRlcmFscy4gJm5ic3A7IE15IHRlc3QsIGxpa2Ug RGFuJ3MsIG9ubHkgbG9va3MgYXQgdGhlIEhUTUwgb24gdGhlIGhvbWUgcGFnZSBhbmQgdGh1cyB1 bmRlci1jb3VudHMgbGl0ZXJhbHMgaW4gZGVlcGVyIGxpbmtzIG9yIGxvYWRlZCB2aWEgQ1NTLCBY TUwsIG9yIEphdmFzY3JpcHQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aHJvdWdoIG90aGVyIG1hbnVhbCB0ZXN0aW5nICZuYnNwO2kgaGF2ZSBzZWVuIGNhdGFzdHJvcGhp YyBmYWlsdXJlIGluIEFtYXpvbidzIHZpZGVvIHN0cmVhbWluZyBzZXJ2aWNlIHdpdGggdGhlbSBw YXNzaW5nIGxpdGVyYWxzIGluIFhNTC4mbmJzcDsgRmFjZWJvb2sgcGFzc2VzIElQdjQgbGl0ZXJh bHMgaW4gSmF2YXNjcmlwdCwgYnV0IGlzIG5vdCBpbXBhY3RpbmcgdGhlIHBhZ2UgbG9hZC48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgcG9zdGVkIElQdjQgbGl0ZXJhbHMgZm91bmQg aW4gdGhlIEhUTUwgaG9tZXBhZ2Ugb2YgdGhlc2UgMiwyMjAgb2YgdGhlIHRvcCAxMDAsMDAwIEFs ZXhhIGRvbWFpbnMgaGVyZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vc2l0ZXMuZ29vZ2xlLmNvbS9z aXRlL3Rtb2lwdjYvaXB2NGxpdGVyYWxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zaXRlcy5n b29nbGUuY29tL3NpdGUvdG1vaXB2Ni9pcHY0bGl0ZXJhbHM8L2E+PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5NeSBjb25jbHVzaW9uIGlzIHRoYXQgaXQgaXMgbm90IGZlYXNpYmxlIGZv ciBhIG5ldHdvcmsgb3BlcmF0b3IgdG8gZGVwbG95IGEgcHVyZWx5IElQdjYtb25seSBzb2NrZXQg c29sdXRpb24uJm5ic3A7IEFzIGhhcyBiZWVuIHByZXZpb3VzbHkgZXhwbG9yZWQsIGFib3V0IDIw JSBvZiB0aGUgYXBwcyBpbiB0aGUgR29vZ2xlIGFuZCBBcHBsZSAmcXVvdDthcHAgc3RvcmUmcXVv dDsgY2Fubm90IGZ1bmN0aW9uIG9uIElQdjYtb25seSAmIzQzOyBOQVQ2NC9ETlM2NC4mbmJzcDsg RXZlbg0KIGlmIHRoZXNlICZxdW90O2FwcCBzdG9yZXMmcXVvdDsgd2VyZSBwb2xpY2VkIHRvIGZv cmNlIGFsbCBhcHBsaWNhdGlvbnMgdG8gYmUgQWRkcmVzcyBGYW1pbHkgYWdub3N0aWMsIGl0IGlz IG5vdCBwb3NzaWJsZSB0byBwb2xpY2UgdGhlIHdvcmxkIHdpZGUgd2ViIG9yIGVudGVycHJpc2Ug VlBOIG9yIFNJUCBQaG9uZXMuJm5ic3A7IEFueSBuZXR3b3JrIG9wZXJhdG9yIHRoYXQgYXR0ZW1w dCB0byBkbyB0aGlzIHdvdWxkIGhhdmUgdG8gYWNjZXB0IGF0IGxlYXN0IDEuMzklIGZhaWx1cmUN CiB0byB0aGUgdG90YWwgd2ViIGFuZCBwZXJoYXBzIGFjY2VwdCBmYWlsdXJlIHRvIHNvbWUgbWFq b3Igc2VydmljZXMgKGxpa2UgQW1hem9uIHN0cmVhbWluZykuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5JIGJlbGlldmUgd2UgYXJlIGJleW9uZCB0aGUgcG9pbnQgb2YgYmxhbWluZyB0 aGUgd29ybGQgZm9yIHVzaW5nIElQdjQgbGl0ZXJhbHMgLyByZWZlcnJhbHMuJm5ic3A7IFdlIGp1 c3QgbmVlZCB0byBiZSByZWFsaXN0aWMgdGhhdCBpbnRlcm5ldCBzZXJ2aWNlIHJlcXVpcmVzIElQ djQgc29ja2V0cywgYW5kIHRodXMgUkZDNjE0NCAjMi4xIGlzIG5vdCB0b2RheSBhIGNvbnN1bWVy IGdyYWRlIHNlcnZpY2UuJm5ic3A7IEEgd2lsZCBndWVzcyBpcyB0aGF0IGl0DQogdGhpcyBzaXR1 YXRpb24gd2lsbCBub3QgbWVhbmluZ2Z1bGx5IGltcHJvdmUgKHJpc2sgcmVkdWNlZCB0byB+MCkg Zm9yIDEwJiM0MzsgeWVhcnMuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ VGhvdWdodHM/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DQjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQgZmFj ZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBp bmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0 IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWls IGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2Vu IGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlz IEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5k IGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_D14414A14C161wesleygeorgetwcablecom_-- From nobody Fri Apr 3 07:23:41 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 A7DE31AC3A1 for ; Fri, 3 Apr 2015 07:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 DkgsS6ZMl6Lj for ; Fri, 3 Apr 2015 07:23:37 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 21AA41AC3AF for ; Fri, 3 Apr 2015 07:23:36 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,518,1422939600"; d="scan'208,217";a="670030616" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Apr 2015 10:09:07 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 3 Apr 2015 10:23:36 -0400 From: "George, Wes" To: James Woodyatt , IPv6 Ops WG Date: Fri, 3 Apr 2015 10:23:35 -0400 Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AdBuGcVjAu23NHBPQDajF0wuBStrkA== Message-ID: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D14415744C168wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 14:23:39 -0000 --_000_D14415744C168wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBKYW1lcyBXb29keWF0dCA8amh3QG5lc3RsYWJzLmNvbTxtYWlsdG86amh3QG5lc3Rs YWJzLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgYXQgNjoyMyBQTQ0KVG86 IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFt2Nm9wc10gVGhlIG5lZWQgZm9yIGxvY2FsLWlwdjQgc29ja2V0IHRyYW5zaXRp b24gc29sdXRpb25zIC0tIE5BVDY0L0ROUzY0IHJlbWFpbnMgaW5zdWZmaWNpZW50DQoNClRoZXJl IGlzIG9ubHkgb25lIHRoaW5nIGFwcGx5aW5nIGFueSBwcmVzc3VyZSBvZiBhbnkga2luZCB0byBk ZXZlbG9wZXJzIGN1cnJlbnRseSB1c2luZyBJUHY0IGxpdGVyYWxzIGluIHRoZWlyIGFwcGxpY2F0 aW9uIHByb3RvY29sczogdGhhdCB0aGVpciBhcHBsaWNhdGlvbnMgRkFJTCBvbiBBcHBsZSBvcGVy YXRpbmcgc3lzdGVtcyB3aGVuIHRob3NlIGRldmljZXMgY29ubmVjdCB0byBJUHY2LW9ubHkrTkFU NjQgbmV0d29ya3MuDQoNCklmIEFwcGxlIGNhdmVzIG9uIHRoaXMsIGFzIGV2ZXJ5IG90aGVyIG1h am9yIHZlbmRvciBvZiBtb2JpbGUgZGV2aWNlIG9wZXJhdGluZyBzeXN0ZW1zIGhhcyBhbHJlYWR5 IGNhdmVkLCB0aGVuIGRldmVsb3BlcnMgd2lsbCBjb250aW51ZSB0byByZWx5IG9uIHRoZSB2aWFi aWxpdHkgb2YgSVB2NCBsaXRlcmFscyBhcyBhIHByb3RvY29sIGVsZW1lbnQgZm9yIHRoZSBmb3Jl c2VlYWJsZSBmdXR1cmUuIFRob3NlIGFwcGxpY2F0aW9ucyB0aGF0IGRvIHNvIHdpbGwgY29udGlu dWUgc2hpcHBpbmcgd2l0aCBhIHJlbGlhbmNlIG9uIDQ2NFhMQVQgZm9yIHllYXJzIHRvIGNvbWUs IGFuZCB0aGV5IHdpbGwgY29udGludWUgdG8gYmUgdXNlZCBpbiBjcml0aWNhbCBwcm9jZXNzZXMg Zm9yIHllYXJzIGFmdGVyIHRoYXQgd2hlbiB0aGV5IGFyZSBubyBsb25nZXIgdW5kZXIgbWFpbnRl bmFuY2UuIFRoZXJlIGFyZSBwZW9wbGUgdG9kYXkgc2NydWJiaW5nIHdlYiBwYWdlcyBhbmQgYXBw bGljYXRpb24gcHJvdG9jb2xzIG9mIHRoZWlyIElQdjQgbGl0ZXJhbHMsIGFuZCB0aGV5IGFyZSBt YWlubHkgbW90aXZhdGVkIHRvIGNvbnRpbnVlIGRvaW5nIHRoaXMgYnkgdGhlIG5lZWQgdG8gZGVh bCB3aXRoIHRoZSBmYWN0IHRoYXQgNDY0WExBVCBpc24ndCB1bml2ZXJzYWxseSBkZXBsb3llZCBv biBhbGwgdGhlIG1ham9yIG1vYmlsZSBwbGF0Zm9ybXMgeWV0LiBBcHBsZSBpcyB0aGUgbGFzdCBu b3Rld29ydGh5IGhvbGRvdXQuDQoNClB1Ymxpc2hpbmcgYSBCQ1AgdGhhdCBlbnRhaWxzIHRlbGxp bmcgZGV2ZWxvcGVycyB0aGF0IElQdjQgbGl0ZXJhbHMgYXJlIGxlZ2l0aW1hdGUgZm9yIHVzZSBh cyBhcHBsaWNhdGlvbiBwcm90b2NvbCBlbGVtZW50cyBpcyB1bm5lY2Vzc2FyeSBhbmQgY291bnRl ci1wcm9kdWN0aXZlIHRvIHRoZSBpbnRlcmVzdHMgb2YgdGhlIElFVEYgaW4gcHJvbW90aW5nIGFk b3B0aW9uIG9mIElQdjYuIEluc3RlYWQgaXQgd291bGQgY29tbXVuaWNhdGUgdG8gZGV2ZWxvcGVy cyB0aGF0IElFVEYgaXMgY2FwaXR1bGF0aW5nIG9uIElQdjYsIHRoYXQgaXQgZG9lc24ndCByZWFs bHkgYmVsaWV2ZSBpbiBpdCBhbnltb3JlLCBhbmQgYXBwbGljYXRpb24gZGV2ZWxvcGVycyBzaG91 bGQgZmVlbCBzYWZlIGlnbm9yaW5nIGl0IGZvciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlLg0KDQpX R10gaW50ZXJlc3RpbmdseSwgbW9zdCBvZiB0aGUgYWJvdmUgc3RhdGVtZW50IHN0aWxsIHdvcmtz IGlmIHlvdSBkbyAlcy9JUHY0IExpdGVyYWxzL0Fkb2JlIEZsYXNoL2csIHRob3VnaCBBbmRyb2lk IGhhcyBob3BwZWQgb24gdGhhdCBwYXJ0aWN1bGFyIGJhbmR3YWdvbiB0b28uDQoNCllvdSdyZSBz aW1wbHkgYWR2b2NhdGluZyBmb3IgcHVzaGluZyB0aGlzIHByb2JsZW0gYW5kIHRoZXJlZm9yZSBh bGwgZWZmb3J0cyB0byBtb3RpdmF0ZSBwZW9wbGUgdG8gc3RvcCB1c2luZyBJUHY0IGxpdGVyYWxz IGJhY2sgb250byB0aGUgY2FycmllcnMsIGJlY2F1c2UgeW91IGtub3cgZnVsbCB3ZWxsIHRoYXQg dW5saWtlIEFwcGxlL0FuZHJvaWQgZGlkIHdpdGggZmxhc2gsIHRoZSBjYXJyaWVycyBhcmVuJ3Qg Z29pbmcgdG8gaW50ZW50aW9uYWxseSBicmVhayB0aGVpciB1c2VyJ3MgZXhwZXJpZW5jZSB0byBw cm92ZSBhIHBvaW50IHVudGlsIHRoZSByaXNrIGlzIHZhbmlzaGluZ2x5IHNtYWxsLCBzbyB0aGV5 IHNpbXBseSB3b24ndCBkZXBsb3kgSVB2Ni1vbmx5K05BVDY0LCBiZWNhdXNlIGRvaW5nIHNvIHdp bGwgbWFrZSB0aGUgcGhvbmUgcmluZy4NCg0KUGVyaGFwcyBpZiBBcHBsZSBiZWxpZXZlcyB0aGF0 IHRoZSBkZXZlbG9wZXJzIG5lZWQgbW9yZSBtb3RpdmF0aW9uLCB0aGVyZSBzaG91bGQgYmUgZXhw bGljaXQgZ3VpZGFuY2UgaW4gdGhlIEFwcCBzdG9yZSBndWlkZWxpbmVzIHRoYXQgYXBwcyB1c2lu ZyBJUHY0IGxpdGVyYWxzLCBldmVuIG9uIHRoZSBzZXJ2ZXIgc2lkZSwgYXJlIHVuYWNjZXB0YWJs ZT8gKHllcywgSSByZWFsaXplIHlvdSBubyBsb25nZXIgd29yayB0aGVyZSBKYW1lcykuIExvcmVu em8sIGRvZXMgQW5kcm9pZCBoYXZlIHN1Y2ggZ3VpZGFuY2U/IEV2ZW4gd2l0aCA0NjR4bGF0IHN1 cHBvcnQsIGlmIHRoYXQncyB0aGVyZSwgdGhlbiB3ZSdyZSBjb250aW51aW5nIHRoZSBwcmVzc3Vy ZSBvbiBmaXhpbmcgaXQgd2hpbGUgYWNrbm93bGVkZ2luZyB0aGUgb3BlcmF0aW9uYWwgcmVhbGl0 eSBvZiBtYWtpbmcgYSBkZWNlbnQgdXNlciBleHBlcmllbmNlIHVudGlsIGl0J3MgZml4ZWQgcHJv cGVybHkuDQoNCldlcyBHZW9yZ2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUg V2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2Vk LCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1l IFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBh cmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwg Y29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBh bmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQg bWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBk ZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHBy aW50b3V0Lg0K --_000_D14415744C168wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFw dDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElO Ry1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5KYW1lcyBXb29keWF0dCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpod0BuZXN0bGFicy5jb20iPmpod0BuZXN0bGFicy5jb208L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1 cnNkYXksIE1hcmNoIDI2LCAyMDE1IGF0IDY6MjMgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5JUHY2IE9wcyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2 b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3Y2b3BzXSBUaGUgbmVlZCBmb3Ig bG9jYWwtaXB2NCBzb2NrZXQgdHJhbnNpdGlvbiBzb2x1dGlvbnMgLS0gTkFUNjQvRE5TNjQgcmVt YWlucyBpbnN1ZmZpY2llbnQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj5UaGVyZSBpcyBvbmx5IG9uZSB0aGlu ZyBhcHBseWluZyBhbnkgcHJlc3N1cmUgb2YgYW55IGtpbmQgdG8gZGV2ZWxvcGVycyBjdXJyZW50 bHkgdXNpbmcgSVB2NCBsaXRlcmFscyBpbiB0aGVpciBhcHBsaWNhdGlvbiBwcm90b2NvbHM6IHRo YXQgdGhlaXIgYXBwbGljYXRpb25zIEZBSUwgb24gQXBwbGUgb3BlcmF0aW5nIHN5c3RlbXMgd2hl biB0aG9zZSBkZXZpY2VzIGNvbm5lY3QgdG8gSVB2Ni1vbmx5JiM0MztOQVQ2NA0KIG5ldHdvcmtz LjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPklmIEFwcGxlIGNhdmVzIG9uIHRoaXMsIGFzIGV2ZXJ5IG90aGVyIG1h am9yIHZlbmRvciBvZiBtb2JpbGUgZGV2aWNlIG9wZXJhdGluZyBzeXN0ZW1zIGhhcyBhbHJlYWR5 IGNhdmVkLCB0aGVuIGRldmVsb3BlcnMgd2lsbCBjb250aW51ZSB0byByZWx5IG9uIHRoZSB2aWFi aWxpdHkgb2YgSVB2NCBsaXRlcmFscyBhcyBhIHByb3RvY29sIGVsZW1lbnQgZm9yIHRoZSBmb3Jl c2VlYWJsZSBmdXR1cmUuIFRob3NlDQogYXBwbGljYXRpb25zIHRoYXQgZG8gc28gd2lsbCBjb250 aW51ZSBzaGlwcGluZyB3aXRoIGEgcmVsaWFuY2Ugb24gNDY0WExBVCBmb3IgeWVhcnMgdG8gY29t ZSwgYW5kIHRoZXkgd2lsbCBjb250aW51ZSB0byBiZSB1c2VkIGluIGNyaXRpY2FsIHByb2Nlc3Nl cyBmb3IgeWVhcnMgYWZ0ZXIgdGhhdCB3aGVuIHRoZXkgYXJlIG5vIGxvbmdlciB1bmRlciBtYWlu dGVuYW5jZS4gVGhlcmUgYXJlIHBlb3BsZSB0b2RheSBzY3J1YmJpbmcgd2ViIHBhZ2VzDQogYW5k IGFwcGxpY2F0aW9uIHByb3RvY29scyBvZiB0aGVpciBJUHY0IGxpdGVyYWxzLCBhbmQgdGhleSBh cmUgbWFpbmx5IG1vdGl2YXRlZCB0byBjb250aW51ZSBkb2luZyB0aGlzIGJ5IHRoZSBuZWVkIHRv IGRlYWwgd2l0aCB0aGUgZmFjdCB0aGF0IDQ2NFhMQVQgaXNuJ3QgdW5pdmVyc2FsbHkgZGVwbG95 ZWQgb24gYWxsIHRoZSBtYWpvciBtb2JpbGUgcGxhdGZvcm1zIHlldC4gQXBwbGUgaXMgdGhlIGxh c3Qgbm90ZXdvcnRoeSBob2xkb3V0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxi cj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPlB1Ymxpc2hpbmcgYSBCQ1AgdGhh dCBlbnRhaWxzIHRlbGxpbmcgZGV2ZWxvcGVycyB0aGF0IElQdjQgbGl0ZXJhbHMgYXJlIGxlZ2l0 aW1hdGUgZm9yIHVzZSBhcyBhcHBsaWNhdGlvbiBwcm90b2NvbCBlbGVtZW50cyBpcyB1bm5lY2Vz c2FyeSBhbmQgY291bnRlci1wcm9kdWN0aXZlIHRvIHRoZSBpbnRlcmVzdHMgb2YgdGhlIElFVEYg aW4gcHJvbW90aW5nIGFkb3B0aW9uIG9mIElQdjYuIEluc3RlYWQgaXQNCiB3b3VsZCBjb21tdW5p Y2F0ZSB0byBkZXZlbG9wZXJzIHRoYXQgSUVURiBpcyBjYXBpdHVsYXRpbmcgb24gSVB2NiwgdGhh dCBpdCBkb2Vzbid0IHJlYWxseSBiZWxpZXZlIGluIGl0IGFueW1vcmUsIGFuZCBhcHBsaWNhdGlv biBkZXZlbG9wZXJzIHNob3VsZCBmZWVsIHNhZmUgaWdub3JpbmcgaXQgZm9yIHRoZSBmb3Jlc2Vl YWJsZSBmdXR1cmUuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsZWFyPSJh bGwiPg0KPGRpdj5XR10gaW50ZXJlc3RpbmdseSwgbW9zdCBvZiB0aGUgYWJvdmUgc3RhdGVtZW50 IHN0aWxsIHdvcmtzIGlmIHlvdSBkbyAlcy9JUHY0IExpdGVyYWxzL0Fkb2JlIEZsYXNoL2csIHRo b3VnaCBBbmRyb2lkIGhhcyBob3BwZWQgb24gdGhhdCBwYXJ0aWN1bGFyIGJhbmR3YWdvbiB0b28u PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ WW91J3JlIHNpbXBseSBhZHZvY2F0aW5nIGZvciBwdXNoaW5nIHRoaXMgcHJvYmxlbSBhbmQgdGhl cmVmb3JlIGFsbCBlZmZvcnRzIHRvIG1vdGl2YXRlIHBlb3BsZSB0byBzdG9wIHVzaW5nIElQdjQg bGl0ZXJhbHMgYmFjayBvbnRvIHRoZSBjYXJyaWVycywgYmVjYXVzZSB5b3Uga25vdyBmdWxsIHdl bGwgdGhhdCB1bmxpa2UgQXBwbGUvQW5kcm9pZCBkaWQgd2l0aCBmbGFzaCwgdGhlIGNhcnJpZXJz IGFyZW4ndCBnb2luZyB0byBpbnRlbnRpb25hbGx5DQogYnJlYWsgdGhlaXIgdXNlcidzIGV4cGVy aWVuY2UgdG8gcHJvdmUgYSBwb2ludCB1bnRpbCB0aGUgcmlzayBpcyB2YW5pc2hpbmdseSBzbWFs bCwgc28gdGhleSBzaW1wbHkgd29uJ3QgZGVwbG95IElQdjYtb25seSYjNDM7TkFUNjQsIGJlY2F1 c2UgZG9pbmcgc28gd2lsbCBtYWtlIHRoZSBwaG9uZSByaW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+UGVyaGFwcyBpZiBBcHBsZSBiZWxpZXZlcyB0aGF0IHRoZSBkZXZlbG9wZXJz IG5lZWQgbW9yZSBtb3RpdmF0aW9uLCB0aGVyZSBzaG91bGQgYmUgZXhwbGljaXQgZ3VpZGFuY2Ug aW4gdGhlIEFwcCBzdG9yZSBndWlkZWxpbmVzIHRoYXQgYXBwcyB1c2luZyBJUHY0IGxpdGVyYWxz LCBldmVuIG9uIHRoZSBzZXJ2ZXIgc2lkZSwgYXJlIHVuYWNjZXB0YWJsZT8gKHllcywgSSByZWFs aXplIHlvdSBubyBsb25nZXIgd29yayB0aGVyZSBKYW1lcykuDQogTG9yZW56bywgZG9lcyBBbmRy b2lkIGhhdmUgc3VjaCBndWlkYW5jZT8gRXZlbiB3aXRoIDQ2NHhsYXQgc3VwcG9ydCwgaWYgdGhh dCdzIHRoZXJlLCB0aGVuIHdlJ3JlIGNvbnRpbnVpbmcgdGhlIHByZXNzdXJlIG9uIGZpeGluZyBp dCB3aGlsZSBhY2tub3dsZWRnaW5nIHRoZSBvcGVyYXRpb25hbCByZWFsaXR5IG9mIG1ha2luZyBh IGRlY2VudCB1c2VyIGV4cGVyaWVuY2UgdW50aWwgaXQncyBmaXhlZCBwcm9wZXJseS48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlcyBHZW9yZ2U8L2Rpdj4NCjxicj4NCjxocj4NCjxm b250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+VGhpcyBFLW1haWwgYW5kIGFu eSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Ig c3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlz IEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCiBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlv biB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRv DQogdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdp bmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NCjwv Zm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D14415744C168wesleygeorgetwcablecom_-- From nobody Fri Apr 3 07:35: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 C5F8F1A9068 for ; Fri, 3 Apr 2015 07:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pLEcez5iH_8 for ; Fri, 3 Apr 2015 07:35:44 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (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 307311A903B for ; Fri, 3 Apr 2015 07:35:44 -0700 (PDT) Received: by wgin8 with SMTP id n8so23099716wgi.0 for ; Fri, 03 Apr 2015 07:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iJWPKbFksikEoyVgRmknoPJZszEd7MZBwLD1buadu8Y=; b=Km27D4nRZGg+VHvA7iB/8cULsm5Znc3biaJxiwDlOKHtKiknkA+9Rp12R9LezJWtXM UwwYCyCAod81ctaPgCaC5J24qW73k4olYedAwvoBjdV6y5zxFqVRIc5j5LWOWPQyn9Va 0otxC14rs7prF4yGC1qtiVjCKG512VCXfX5WuSyjVfkcpc2+qQ+AwbflK/SDlFSLWyDK sOklE6WwAizR7P5BhUSAzov8bZWGTfep3t+gVPGFVuWQKmK+CbM/Danohwayn2ort4u/ q8kQwIgoVrJvx2n2zquTpmx02lCWkQOojKAQnh6x/N/zhGKui9QY7hNhOmpDHpgkBvLf PvTg== MIME-Version: 1.0 X-Received: by 10.180.74.198 with SMTP id w6mr31885912wiv.69.1428071742934; Fri, 03 Apr 2015 07:35:42 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Fri, 3 Apr 2015 07:35:42 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Fri, 3 Apr 2015 07:35:42 -0700 Message-ID: From: Ca By To: "George, Wes" Content-Type: multipart/alternative; boundary=f46d043749a5f393b90512d2dc69 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 14:35:46 -0000 --f46d043749a5f393b90512d2dc69 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 7:23 AM, George, Wes wrote: > > From: James Woodyatt > Date: Thursday, March 26, 2015 at 6:23 PM > To: IPv6 Ops WG > Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions > -- NAT64/DNS64 remains insufficient > > There is only one thing applying any pressure of any kind to developers > currently using IPv4 literals in their application protocols: that their > applications FAIL on Apple operating systems when those devices connect to > IPv6-only+NAT64 networks. > > If Apple caves on this, as every other major vendor of mobile device > operating systems has already caved, then developers will continue to rely > on the viability of IPv4 literals as a protocol element for the foreseeable > future. Those applications that do so will continue shipping with a > reliance on 464XLAT for years to come, and they will continue to be used in > critical processes for years after that when they are no longer under > maintenance. There are people today scrubbing web pages and application > protocols of their IPv4 literals, and they are mainly motivated to continue > doing this by the need to deal with the fact that 464XLAT isn't universally > deployed on all the major mobile platforms yet. Apple is the last > noteworthy holdout. > > Publishing a BCP that entails telling developers that IPv4 literals are > legitimate for use as application protocol elements is unnecessary and > counter-productive to the interests of the IETF in promoting adoption of > IPv6. Instead it would communicate to developers that IETF is capitulating > on IPv6, that it doesn't really believe in it anymore, and application > developers should feel safe ignoring it for the foreseeable future. > > WG] interestingly, most of the above statement still works if you do > %s/IPv4 Literals/Adobe Flash/g, though Android has hopped on that > particular bandwagon too. > > You're simply advocating for pushing this problem and therefore all > efforts to motivate people to stop using IPv4 literals back onto the > carriers, because you know full well that unlike Apple/Android did with > flash, the carriers aren't going to intentionally break their user's > experience to prove a point until the risk is vanishingly small, so they > simply won't deploy IPv6-only+NAT64, because doing so will make the phone > ring. > > Perhaps if Apple believes that the developers need more motivation, > there should be explicit guidance in the App store guidelines that apps > using IPv4 literals, even on the server side, are unacceptable? (yes, I > realize you no longer work there James). Lorenzo, does Android have such > guidance? Even with 464xlat support, if that's there, then we're continuing > the pressure on fixing it while acknowledging the operational reality of > making a decent user experience until it's fixed properly. > > Wes George > > Talk is cheap, so are guidelines. If it works, it ships. We have been waving the guidelines that people should turn on ipv6 for years, they don't work. Anyone who has turned on ipv6 has done it because they saw a straight-line to risk and cost mitigation. And again, there are ipv4 literals on major top 100, top 1000, top 1M websites.... App store guidelines and even hard requirements won't fix the free and open web. Releasing guidelines was soooo 2005. And, soooo ineffective at making real ipv6-only ipv4-socket-free deployment possible. In fact, we are pretty sure no major (or minor) network or operating environment of any sort is ipv4-free. Meaning, nobody has even started. Conclusion: IPv4 sockets need to be supported on hosts that operate in IPv6-only networks. CB > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --f46d043749a5f393b90512d2dc69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 3, 2015 at 7:23 AM, George, Wes <wesley.george@twc= able.com> wrote:

From: James Woodyatt <jhw@nestlabs.com>
Date: Thursday, March 26, 2015 at 6= :23 PM
To: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re= : [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS6= 4 remains insufficient

There is only one thing applying any pressure of= any kind to developers currently using IPv4 literals in their application = protocols: that their applications FAIL on Apple operating systems when tho= se devices connect to IPv6-only+NAT64 networks.

If Apple caves on this, as every other major ven= dor of mobile device operating systems has already caved, then developers w= ill continue to rely on the viability of IPv4 literals as a protocol elemen= t for the foreseeable future. Those applications that do so will continue shipping with a reliance on 464XLAT = for years to come, and they will continue to be used in critical processes = for years after that when they are no longer under maintenance. There are p= eople today scrubbing web pages and application protocols of their IPv4 literals, and they are mainly moti= vated to continue doing this by the need to deal with the fact that 464XLAT= isn't universally deployed on all the major mobile platforms yet. Appl= e is the last noteworthy holdout.

Publishing a BCP that entails telling developers= that IPv4 literals are legitimate for use as application protocol elements= is unnecessary and counter-productive to the interests of the IETF in prom= oting adoption of IPv6. Instead it would communicate to developers that IETF is capitulating on IPv6, that it= doesn't really believe in it anymore, and application developers shoul= d feel safe ignoring it for the foreseeable future.

WG] interestingly, most of the above statement still works if you do %= s/IPv4 Literals/Adobe Flash/g, though Android has hopped on that particular= bandwagon too.

You're simply advocating for pushing this problem and therefore al= l efforts to motivate people to stop using IPv4 literals back onto the carr= iers, because you know full well that unlike Apple/Android did with flash, = the carriers aren't going to intentionally break their user's experience to prove a point until the risk is vanis= hingly small, so they simply won't deploy IPv6-only+NAT64, because doin= g so will make the phone ring.

Perhaps if Apple believes that the developers need more motivation, th= ere should be explicit guidance in the App store guidelines that apps using= IPv4 literals, even on the server side, are unacceptable? (yes, I realize = you no longer work there James). Lorenzo, does Android have such guidance? Even with 464xlat support, if th= at's there, then we're continuing the pressure on fixing it while a= cknowledging the operational reality of making a decent user experience unt= il it's fixed properly.

Wes George

Talk is cheap, so are gui= delines.=C2=A0 If it works, it ships.=C2=A0 We have been waving the guideli= nes that people should turn on ipv6 for years, they don't work.=C2=A0 A= nyone who has turned on ipv6 has done it because they saw a straight-line t= o risk and cost mitigation.

And again, there are i= pv4 literals on major top 100, top 1000, top 1M websites.... App store guid= elines and even hard =C2=A0requirements won't fix the free and open web= .

Releasing guidelines was soooo 2005. And, soooo = ineffective at making real ipv6-only ipv4-socket-free deployment possible.= =C2=A0 In fact, we are pretty sure no major (or minor) network or operating= environment of any sort is ipv4-free.

Meaning, no= body has even started.

Conclusion: =C2=A0IPv4 sock= ets need to be supported on hosts that operate in IPv6-only networks.
=

CB=C2=A0
This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.

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


--f46d043749a5f393b90512d2dc69-- From nobody Fri Apr 3 10:34:52 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 D9A181ACDFF; Fri, 3 Apr 2015 10:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.5 X-Spam-Level: X-Spam-Status: No, score=-114.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 I8FAA1udovrP; Fri, 3 Apr 2015 10:34:46 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4881ACDFE; Fri, 3 Apr 2015 10:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58378; q=dns/txt; s=iport; t=1428082486; x=1429292086; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WoXRvoSiKdpVUMQY8RrZ0RT107rk8zZOwULvoWofQkw=; b=j9zrDuZoqc3eZrxE3gs8+6yQNErEs1S/akdkYEYrxZPT+iVyHSDJRE9m CEpNpzI45uZFAAMfevzXvZzCixpShJV30jax/lILDWGQ3UzjhIirq+eWF 1RwRhhx0Wm+VrhKQlMNYTZpGgNZyklTFGGQ1oEuNNVABitSXHi1BFnAwL I=; X-Files: transition.xml, transition.txt, transition.html, signature.asc : 13207, 13426, 27796, 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DgBQAozh5V/4ENJK1cgkhDUlwFgxDAV4IEhXMKAoEvTAEBAQEBAX6EHwEBBBoJBEAGDBACAQgSJgEJAgIyFw4CBA4FDoghDbUZmA0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXiymEFhEBJxgSBwmCXy+BFgWGU4gJgg+BboEzVIQKggGBHREpgnuMMoNIIoNvbwGBCjl/AQEB X-IronPort-AV: E=Sophos;i="5.11,518,1422921600"; d="xml'217?asc'217?html'217,217?txt'217,217?scan'217,217,208,217"; a="408976421" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 03 Apr 2015 17:34:44 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t33HYiO1009444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Apr 2015 17:34:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.67]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 3 Apr 2015 12:34:44 -0500 From: "Fred Baker (fred)" To: "George, Wes" Thread-Topic: [v6ops] IPv4 trajectory Thread-Index: AQHQbjR4SwYTQhluR0mkL23V7qY82g== Date: Fri, 3 Apr 2015 17:34:43 +0000 Message-ID: <028FC16B-8D26-4CDE-8F17-19148B20B99C@cisco.com> References: <551AF135.3060602@gmail.com> <551B37B9.4090400@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_21832243-2299-4097-964E-D62C1CC7BF87"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG , "sunset4@ietf.org" Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 17:34:51 -0000 --Apple-Mail=_21832243-2299-4097-964E-D62C1CC7BF87 Content-Type: multipart/mixed; boundary="Apple-Mail=_5CF6462A-9F96-45D5-B33E-C3DF553015CF" --Apple-Mail=_5CF6462A-9F96-45D5-B33E-C3DF553015CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dumb question. There were at least a couple of comments early in the = thread about =E2=80=9Cwe should have an ID that says this=E2=80=9D. I = hacked one together, basically an updated version of the email. (1) are we interested enough to actually have a draft, or does it just = seem cute? (2) if we=E2=80=99re interested enough to have a draft, what working = group? (3) if we=E2=80=99re interested enough to have a draft, it seems to me = that I should have 1-3 co-authors, from SP, enterprise, and perhaps CDN = environments, that can comment with some authority about the process and = considerations in their environments. I would want the co-authors to add = text as they deem it appropriate. See attached. --Apple-Mail=_5CF6462A-9F96-45D5-B33E-C3DF553015CF Content-Disposition: attachment; filename=transition.xml Content-Type: application/xml; name="transition.xml" Content-Transfer-Encoding: 7bit Ruminations on the IPv4->IPv6 Transition Cisco Systems
Santa Barbara 93117 California USA fred@cisco.com
Operations and Management IPv6 Operations This note presents the author's perspective on the transition.
Seven years after its writing, the Basic Transition Mechanisms for IPv6 Hosts and Routers, seems a little naive. The model proposed was that the Internet, and any of its component networks, would go through three essential phases: IPv4-only network IPv4+IPv6 Dual Stack network IPv6-only Network In fairness, the authors were trying to describe the transition in broad terms, so the naiveté is excusable. However, reality appears to be more like: IPv4-only network IPv4 with lab experiments or isolated IPv6 networks without IPv6-capable services IPv4 with in some combination of overlay and native IPv6 deployment IPv4+IPv6 (native) dual stack network IPv6+IPv4 non-native, translated or overlay (e.g., as a service) IPv6 with little bits of IPv4 here and there IPv6-only Even that is to some extent naive; only the smallest of networks can change overnight. Real networks change in a piecemeal fashion. So in a network that is somewhere in the process of transition probably has components in each of those phases.
There are a variety of transition technologies available in either commerical or open source implementation. The following is a fairly comprehensive list, but may be partial. 464XLAT: Combination of Stateful and Stateless Translation Translation between IPv4 and a configured native IPv6 address ( ) Mapping of Address and Port with Encapsulation (MAP) Mapping of Address and Port using Double Translation (MAP-T) Stateless Single Translation to an IPv4-embedded IPv6 Address () Stateful Single Translation to an IPv6 Address () Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion Lightweight 4over6: An Extension to the DS-Lite Architecture LISP (4 over 6, )
As noted in , the network appears to go through about seven steps or phases.
The first step is the existing IPv4 Internet.
With the publication of the original IPv6 Specification, and especially with its successor, researchers started learning about the technology. On March 30 1995, they set up the first interconnection between two independent IPv6 implementations, between sipper.pa-x.dec.com and ottawa.inria.fr. Several academic and research networks such as Renater, HEANET, and Internet2, deployed the technology in a trial mode. Many networks continue to kick the tires, lacking a business requirement to go to the next step.
The third phase is wider trial deployment. This often involves IPv6/IPv4 tunnels, local network deployment, 6rd, or ISATAP.
The fourth step is Dual Stack deployment. This calls for careful definition, as there are cheap versions that stop at "we turned them both on, but of course IPv4 is the one we depend on". In a Dual Stack deployment, either protocol is useful and usable for any purpose; it is feasible to turn IPv4 off for any supported service. It is retained because of specific applications, equipment, or constituencies that would object.
The network begins to overcome the objections, and turn IPv4 off for some set of equipment or applications. Content exists that must be reached on IPv4-only networks including the general Internet, and not all services within the network may be fully IPv6-capable. For that reason, IPv4 must be maintained. But to reduce costs or to manage the shrinking IPv4 address space, IPv4 is carried via translation or encapsulation, using technologies such as those mentioned in .
As IPv6 proves viable, the overlay or translation system gets turned off. At this point, IPv4 assumes a legacy status, comparable to AppleTalk or DECNet.
IPv4 has been turned off everywhere. It is cold in hell, and some IT managers are having it pried out of their cold, dead hands.
The steps in fall broadly into three groups: IPv4 networks, perhaps with some toys, IPv6 networks with mitigations for issues related to IPv4, and the Dual Stack Network. What may not be obvious is that the transition from IPv4 with trial IPv6 deployment to IPv6 with legacy IPv4 deployment has a choice: one can go through Dual Stack or Simulated Dual Stack phases, but there is no need to go through both. Dual Stack will be easier, in the sense that for an instant both technologies are feasible and then IPv4 is turned off. However, it may be more expensive. We are beginning to see networks opt for IPv6 with an IPv4 translation or overlay, whatever problems that may bring.
This memo asks the IANA for no new parameters.
What - are my insecurities showing?
Privacy was not considered in the writing of this memo.
April 2015
--Apple-Mail=_5CF6462A-9F96-45D5-B33E-C3DF553015CF Content-Disposition: attachment; filename=transition.txt Content-Type: text/plain; name="transition.txt" Content-Transfer-Encoding: quoted-printable IPv6 Operations F. Baker Internet-Draft Cisco Systems Intended status: Standards Track March 31, 2015 Expires: October 2, 2015 Ruminations on the IPv4->IPv6 Transition draft-baker-v6ops-transition-ruminations-00 Abstract This note present's the author's perspective on the transition. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 2, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Baker Expires October 2, 2015 [Page 1] =0C Internet-Draft IPv4->IPv6 Transition March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Transition Technologies: IPv4 as a Service . . . . . . . . . 3 3. Steps in the transition . . . . . . . . . . . . . . . . . . . 4 3.1. IPv4-only network . . . . . . . . . . . . . . . . . . . . 4 3.2. IPv4 with scattered IPv6 experiments . . . . . . . . . . 4 3.3. IPv4+non-native IPv6, translated or overlay (e.g., as a service) . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. IPv4+IPv6 native dual stack network . . . . . . . . . . . 4 3.5. IPv6+non-native IPv4, translated or overlay (e.g., as a service) . . . . . . . . . . . . . . . . . . . . . . . . 4 3.6. IPv6 with scattered legacy IPv4 . . . . . . . . . . . . . 5 3.7. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Ruminations . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 9. Informative References . . . . . . . . . . . . . . . . . . . 5 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Seven years after its writing, the Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213], seems a little naive. The model proposed was that the Internet, and any of its component networks, would go through three essential phases: 1. IPv4-only network 2. IPv4+IPv6 Dual Stack network 3. IPv6-only Network In fairness, the authors were trying to describe the transition in broad terms, so the naivete is excusable. However, reality appears to be more like: 1. IPv4-only network 2. IPv4 with lab experiments or isolated IPv6 networks without IPv6-capable services 3. IPv4 with in some combination of overlay and native IPv6 deployment Baker Expires October 2, 2015 [Page 2] =0C Internet-Draft IPv4->IPv6 Transition March 2015 4. IPv4+IPv6 (native) dual stack network 5. IPv6+IPv4 non-native, translated or overlay (e.g., as a service) 6. IPv6 with little bits of IPv4 here and there 7. IPv6-only Even that is to some extent naive; only the smallest of networks can change overnight. Real networks change in a piecemeal fashion. So in a network that is somewhere in the process of transition probably has components in each of those phases. 2. Transition Technologies: IPv4 as a Service There are a variety of transition technologies available in either commerical or open source implementation. The following is a fairly comprehensive list, but may be partial. o 464XLAT: Combination of Stateful and Stateless Translation [RFC6877] o Translation between IPv4 and a configured native IPv6 address ([I-D.ietf-v6ops-siit-dc] [I-D.ietf-v6ops-siit-dc-2xlat] [I-D.anderson-v6ops-siit-eam]) o Mapping of Address and Port with Encapsulation (MAP) [I-D.ietf-softwire-map] o Mapping of Address and Port using Double Translation (MAP-T) [I-D.ietf-softwire-map-t] o Stateless Single Translation to an IPv4-embedded IPv6 Address ([RFC6145]) o Stateful Single Translation to an IPv6 Address ([RFC6146]) o Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [RFC6333] o Lightweight 4over6: An Extension to the DS-Lite Architecture [I-D.ietf-softwire-lw4over6] o LISP (4 over 6, [I-D.ietf-lisp-introduction]) Baker Expires October 2, 2015 [Page 3] =0C Internet-Draft IPv4->IPv6 Transition March 2015 3. Steps in the transition As noted in Section 1, the network appears to go through about seven steps or phases. 3.1. IPv4-only network The first step is the existing IPv4 Internet. 3.2. IPv4 with scattered IPv6 experiments With the publication of the original IPv6 Specification [RFC1883], and especially with its successor [RFC2460], researchers started learning about the technology. On March 30 1995, they set up the first interconnection between two independent IPv6 implementations, between sipper.pa-x.dec.com and ottawa.inria.fr. Several academic and research networks such as Renater, HEANET, and Internet2, deployed the technology in a trial mode. Many networks continue to kick the tires, lacking a business requirement to go to the next step. 3.3. IPv4+non-native IPv6, translated or overlay (e.g., as a service) The third phase is wider trial deployment. This often involves IPv6/ IPv4 tunnels, local network deployment, 6rd [RFC5569], or ISATAP [RFC5214]. 3.4. IPv4+IPv6 native dual stack network The fourth step is Dual Stack deployment. This calls for careful definition, as there are cheap versions that stop at "we turned them both on, but of course IPv4 is the one we depend on". In a Dual Stack deployment, either protocol is useful and usable for any purpose; it is feasible to turn IPv4 off for any supported service. It is retained because of specific applications, equipment, or constituencies that would object. 3.5. IPv6+non-native IPv4, translated or overlay (e.g., as a service) The network begins to overcome the objections, and turn IPv4 off for some set of equipment or applications. Content exists that must be reached on IPv4-only networks including the general Internet, and not all services within the network may be fully IPv6-capable. For that reason, IPv4 must be maintained. But to reduce costs or to manage the shrinking IPv4 address space, IPv4 is carried via translation or encapsulation, using technologies such as those mentioned in Section 2. Baker Expires October 2, 2015 [Page 4] =0C Internet-Draft IPv4->IPv6 Transition March 2015 3.6. IPv6 with scattered legacy IPv4 As IPv6 proves viable, the overlay or translation system gets turned off. At this point, IPv4 assumes a legacy status, comparable to AppleTalk or DECNet. 3.7. IPv6-only IPv4 has been turned off everywhere. It is cold in hell, and some IT managers are having it pried out of their cold, dead hands. 4. Ruminations The steps in Section 3 fall broadly into three groups: IPv4 networks, perhaps with some toys, IPv6 networks with mitigations for issues related to IPv4, and the Dual Stack Network. What may not be obvious is that the transition from IPv4 with trial IPv6 deployment (Section 3.3) to IPv6 with legacy IPv4 deployment (Section 3.6) has a choice: one can go through Dual Stack (Section 3.4) or Simulated Dual Stack (Section 3.5) phases, but there is no need to go through both. Dual Stack will be easier, in the sense that for an instant both technologies are feasible and then IPv4 is turned off. However, it may be more expensive. We are beginning to see networks opt for IPv6 with an IPv4 translation or overlay, whatever problems that may bring. 5. IANA Considerations This memo asks the IANA for no new parameters. 6. Security Considerations What - are my insecurities showing? 7. Privacy Considerations Privacy was not considered in the writing of this memo. 8. Acknowledgements 9. Informative References [I-D.anderson-v6ops-siit-eam] tore, t., "Explicit Address Mappings for Stateless IP/ICMP Translation", draft-anderson-v6ops-siit-eam-03 (work in progress), January 2015. Baker Expires October 2, 2015 [Page 5] =0C Internet-Draft IPv4->IPv6 Transition March 2015 [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-12 (work in progress), February 2015. [I-D.ietf-softwire-lw4over6] Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS- Lite Architecture", draft-ietf-softwire-lw4over6-13 (work in progress), November 2014. [I-D.ietf-softwire-map-t] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", draft-ietf-softwire-map-t-08 (work in progress), December 2014. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", draft-ietf-softwire-map-12 (work in progress), November 2014. [I-D.ietf-v6ops-siit-dc-2xlat] tore, t., "SIIT-DC: Dual Translation Mode", draft-ietf- v6ops-siit-dc-2xlat-00 (work in progress), January 2015. [I-D.ietf-v6ops-siit-dc] tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments", draft-ietf-v6ops-siit-dc-00 (work in progress), December 2014. [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. Baker Expires October 2, 2015 [Page 6] =0C Internet-Draft IPv4->IPv6 Transition March 2015 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013. Appendix A. Change Log Initial Version: April 2015 Author's Address Fred Baker Cisco Systems Santa Barbara, California 93117 USA Email: fred@cisco.com Baker Expires October 2, 2015 [Page 7] --Apple-Mail=_5CF6462A-9F96-45D5-B33E-C3DF553015CF Content-Disposition: attachment; filename=transition.html Content-Type: text/html; name="transition.html" Content-Transfer-Encoding: 7bit Ruminations on the IPv4->IPv6 Transition
IPv6 Operations F. Baker
Internet-Draft Cisco Systems
Intended status: Standards Track March 31, 2015
Expires: October 2, 2015

Ruminations on the IPv4->IPv6 Transition
draft-baker-v6ops-transition-ruminations-00

Abstract

This note present's the author's perspective on the transition.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 2, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Seven years after its writing, the Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213], seems a little naive. The model proposed was that the Internet, and any of its component networks, would go through three essential phases:

  1. IPv4-only network
  2. IPv4+IPv6 Dual Stack network
  3. IPv6-only Network

In fairness, the authors were trying to describe the transition in broad terms, so the naiveté is excusable. However, reality appears to be more like:

  1. IPv4-only network
  2. IPv4 with lab experiments or isolated IPv6 networks without IPv6-capable services
  3. IPv4 with in some combination of overlay and native IPv6 deployment
  4. IPv4+IPv6 (native) dual stack network
  5. IPv6+IPv4 non-native, translated or overlay (e.g., as a service)
  6. IPv6 with little bits of IPv4 here and there
  7. IPv6-only

Even that is to some extent naive; only the smallest of networks can change overnight. Real networks change in a piecemeal fashion. So in a network that is somewhere in the process of transition probably has components in each of those phases.

2. Transition Technologies: IPv4 as a Service

There are a variety of transition technologies available in either commerical or open source implementation. The following is a fairly comprehensive list, but may be partial.

3. Steps in the transition

As noted in Section 1, the network appears to go through about seven steps or phases.

3.1. IPv4-only network

The first step is the existing IPv4 Internet.

3.2. IPv4 with scattered IPv6 experiments

With the publication of the original IPv6 Specification [RFC1883], and especially with its successor [RFC2460], researchers started learning about the technology. On March 30 1995, they set up the first interconnection between two independent IPv6 implementations, between sipper.pa-x.dec.com and ottawa.inria.fr. Several academic and research networks such as Renater, HEANET, and Internet2, deployed the technology in a trial mode.

Many networks continue to kick the tires, lacking a business requirement to go to the next step.

3.3. IPv4+non-native IPv6, translated or overlay (e.g., as a service)

The third phase is wider trial deployment. This often involves IPv6/IPv4 tunnels, local network deployment, 6rd [RFC5569], or ISATAP [RFC5214].

3.4. IPv4+IPv6 native dual stack network

The fourth step is Dual Stack deployment. This calls for careful definition, as there are cheap versions that stop at "we turned them both on, but of course IPv4 is the one we depend on". In a Dual Stack deployment, either protocol is useful and usable for any purpose; it is feasible to turn IPv4 off for any supported service. It is retained because of specific applications, equipment, or constituencies that would object.

3.5. IPv6+non-native IPv4, translated or overlay (e.g., as a service)

The network begins to overcome the objections, and turn IPv4 off for some set of equipment or applications. Content exists that must be reached on IPv4-only networks including the general Internet, and not all services within the network may be fully IPv6-capable. For that reason, IPv4 must be maintained. But to reduce costs or to manage the shrinking IPv4 address space, IPv4 is carried via translation or encapsulation, using technologies such as those mentioned in Section 2.

3.6. IPv6 with scattered legacy IPv4

As IPv6 proves viable, the overlay or translation system gets turned off. At this point, IPv4 assumes a legacy status, comparable to AppleTalk or DECNet.

3.7. IPv6-only

IPv4 has been turned off everywhere. It is cold in hell, and some IT managers are having it pried out of their cold, dead hands.

4. Ruminations

The steps in Section 3 fall broadly into three groups: IPv4 networks, perhaps with some toys, IPv6 networks with mitigations for issues related to IPv4, and the Dual Stack Network. What may not be obvious is that the transition from IPv4 with trial IPv6 deployment [step3] to IPv6 with legacy IPv4 deployment [step6] has a choice: one can go through Dual Stack [step4] or Simulated Dual Stack [step5] phases, but there is no need to go through both. Dual Stack will be easier, in the sense that for an instant both technologies are feasible and then IPv4 is turned off. However, it may be more expensive. We are beginning to see networks opt for IPv6 with an IPv4 translation or overlay, whatever problems that may bring.

5. IANA Considerations

This memo asks the IANA for no new parameters.

6. Security Considerations

What - are my insecurities showing?

7. Privacy Considerations

Privacy was not considered in the writing of this memo.

8. Acknowledgements

9. Informative References

[I-D.anderson-v6ops-siit-eam] tore, t., "Explicit Address Mappings for Stateless IP/ICMP Translation", Internet-Draft draft-anderson-v6ops-siit-eam-03, January 2015.
[I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", Internet-Draft draft-ietf-lisp-introduction-12, February 2015.
[I-D.ietf-softwire-lw4over6] Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y. and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", Internet-Draft draft-ietf-softwire-lw4over6-13, November 2014.
[I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T. and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", Internet-Draft draft-ietf-softwire-map-12, November 2014.
[I-D.ietf-softwire-map-t] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S. and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", Internet-Draft draft-ietf-softwire-map-t-08, December 2014.
[I-D.ietf-v6ops-siit-dc] tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments", Internet-Draft draft-ietf-v6ops-siit-dc-00, December 2014.
[I-D.ietf-v6ops-siit-dc-2xlat] tore, t., "SIIT-DC: Dual Translation Mode", Internet-Draft draft-ietf-v6ops-siit-dc-2xlat-00, January 2015.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC5214] Templin, F., Gleeson, T. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC6145] Li, X., Bao, C. and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P. and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J. and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6877] Mawatari, M., Kawashima, M. and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013.

Appendix A. Change Log

Initial Version:
April 2015

Author's Address

Fred Baker Cisco Systems Santa Barbara, California 93117 USA EMail: fred@cisco.com
--Apple-Mail=_5CF6462A-9F96-45D5-B33E-C3DF553015CF-- --Apple-Mail=_21832243-2299-4097-964E-D62C1CC7BF87 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 iQEVAwUBVR7K559ieig10VPpAQIrDQgAhcbvb4iBfsMyECB4fgoxfQbf3o9UvdKm gl8CHB28CYHinClMc9F+n/mcDbHOHgs3ND5KsBhsFI2UdBYGXuaAacunzFEIMJfB B5IcMUbDElWUo6OyLSDM4+KHxzNjyfjzbnwoJP+PzciBj6WVQDyCg5zRHnL45Og2 ikIy7g1ZatoyHnDFzj6LegEBzkMdWMGUxhU3PvvEKBGCx4/pIWv3T2UNEhq8o4EE fV9aBpGNliUistlJbNukmv6Foq8jyHixlD064igiMusLda8gMouzKPKf4+hEg/Aj UsiEm/QFCsUFWdQUdBFzKowhAwIu7ZAGr26a91ND8ehbaUdy+34thQ== =8Vx6 -----END PGP SIGNATURE----- --Apple-Mail=_21832243-2299-4097-964E-D62C1CC7BF87-- From nobody Fri Apr 3 11:08: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 EE5161ACE9B for ; Fri, 3 Apr 2015 11:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 VGmPZNEPgtZS for ; Fri, 3 Apr 2015 11:07:58 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 0562F1ACE97 for ; Fri, 3 Apr 2015 11:07:57 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so172496162obb.1 for ; Fri, 03 Apr 2015 11:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/tmzHqmRKZQ0AdqMHhRYtjuPvxfuDGz9ygogkEr5L0k=; b=AiLB5h2eAIm3P97AkrWSQCvfdQWQNN/Olh9wLHJRoktUX6kMcow183rJFQykuJkFaw Mdra/ZPQsf5j3eZP0P0Sb4r8KVvY22E//vYpOi9LkIA9Whv9Kl9RQ/0ShjDEFxTcCQdZ ZMgmCbYWOidJdQOGzE+Wx8NKG+yUSyuOm4eXk= 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=/tmzHqmRKZQ0AdqMHhRYtjuPvxfuDGz9ygogkEr5L0k=; b=Ei1Nc0Rq1o8qwWzOEnaPLcXqwR6yJIiAaOmv4r33dt1tHSKl3HtkB4ngXoCmXUMiSo giu5mJu2yvY/pAH9h/H51oU4BzUehq2LlD2PJxnKf8/kQi/xG6GU93RTMnt9D4CfYLHB 0dXM6UqE6Ychqb2BzmmLhzIb4LOk1H/nsUyeqZ2isLUZPaF1fFLrmXk4nl7b4OdmzwqF nlR9ZS58YwDAwd7P65mzuTEtgZHZuzo6ue1fjd546Ampsy3D/9e7iDNXZp9GlFIvNYx0 OveAOrtXRVAGX9X1ynju4QWv5V2rD98lBrddJWplnEzzcQXDGWHTRMK0cxWQVWoZETcW lJsw== X-Gm-Message-State: ALoCoQkB7MsowAddaMCMd9ZFZTlMuvZeISycdcxQr4VKzxw7dBMV4QGr5Sh5bSF0RZ8VReoZPUox MIME-Version: 1.0 X-Received: by 10.182.128.33 with SMTP id nl1mr4212552obb.3.1428084477289; Fri, 03 Apr 2015 11:07:57 -0700 (PDT) Received: by 10.76.177.229 with HTTP; Fri, 3 Apr 2015 11:07:56 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Fri, 3 Apr 2015 13:07:56 -0500 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=e89a8ff2544cfaa63b0512d5d31c Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 18:07:59 -0000 --e89a8ff2544cfaa63b0512d5d31c Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 9:35 AM, Ca By wrote: > > > Conclusion: IPv4 sockets need to be supported on hosts that operate in > IPv6-only networks. > That's an overly general statement, which is why I'm pushing back. A more specific statement you could make is that the IPv4 programming interfaces need to be supported on general-purpose multi-program hosts that operate on IPv6-only networks which bear a strong resemblance to yours. Phrase it that way, however, and the case for a BCP from IETF seems less pressing. -- james woodyatt Nest Labs, Communications Engineering --e89a8ff2544cfaa63b0512d5d31c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 9:35 AM, Ca By <cb.list6@gmail.com> wrot= e:

Conclusion: =C2=A0IPv4 soc= kets need to be supported on hosts that operate in IPv6-only networks.

Tha= t's an overly general statement, which is why I'm pushing back. A m= ore specific statement you could make is that the IPv4 programming interfac= es need to be supported on general-purpose multi-program hosts that operate= on IPv6-only networks which bear a strong resemblance to yours. Phrase it = that way, however, and the case for a BCP from IETF seems less pressing.


--
james woodyatt <jhw@nestlabs.com>
Nest = Labs, Communications Engineering
--e89a8ff2544cfaa63b0512d5d31c-- From nobody Fri Apr 3 11:36: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 D4CE91ACF54 for ; Fri, 3 Apr 2015 11:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLW6PKOWzILe for ; Fri, 3 Apr 2015 11:36:00 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 EA4541ACF19 for ; Fri, 3 Apr 2015 11:35:59 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 02CD9281FF6 for ; Fri, 3 Apr 2015 13:35:59 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 71650281FBA; Fri, 3 Apr 2015 13:35:58 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 1BAE42F4F46; Fri, 3 Apr 2015 14:33:20 -0400 (EDT) Received: from pwn401ea105.ent.corp.bcbsm.com (unknown [10.64.102.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id 0D2872F4F2B; Fri, 3 Apr 2015 14:33:20 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Fri, 3 Apr 2015 14:35:57 -0400 From: "Ackermann, Michael" To: "Fred Baker (fred)" , "George, Wes" Thread-Topic: [v6ops] IPv4 trajectory Thread-Index: AQHQa7mTXPWqu6Iz/0yBevSA7yI3ep03OGKAgABM6QCAAAcmgIAABesAgAAq1oCAA9cMAIAAQE2A///DKTA= Date: Fri, 3 Apr 2015 18:35:56 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CD9A435@PWN401EA160.ent.corp.bcbsm.com> References: <551AF135.3060602@gmail.com> <551B37B9.4090400@gmail.com> <028FC16B-8D26-4CDE-8F17-19148B20B99C@cisco.com> In-Reply-To: <028FC16B-8D26-4CDE-8F17-19148B20B99C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.83.71] x-tm-as-product-ver: SMEX-10.2.0.3262-7.500.1018-21446.003 x-tm-as-result: No--44.631800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 56e118ee-9d7a-40a5-a9d6-00a8fc6fa044 X-VPM-MSG-ID: 73bbf28f-09ed-45fc-9967-3f4aa40a2cea X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 Archived-At: Cc: IPv6 Ops WG , "sunset4@ietf.org" Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 18:36:06 -0000 SEkgRnJlZA0KDQpUaGFua3MgZm9yIHdyaXRpbmcgdGhpcyBhbmQgaXQgd2hpbGUgdGhpcyB0 eXBlIG9mIGRvY3VtZW50ICBtYXkgbm90IHNlZW0gY3JpdGljYWwgb3IgdmFsdWFibGUgIHRv IG1hbnkgb24gdGhpcyBtYWlsaW5nIGxpc3QsICBpdCB3aWxsIGJlIGhlbHBmdWwgdG8gbWFu eSBvZiB1cyBlbnRlcnByaXNlcyB3aG8gYXJlICBjdXJyZW50bHkgc3R1Y2sgYmV0d2VlbiAz LjIgYW5kIDMuMywgIHdpdGhvdXQgYSBuZXh0IHN0ZXAgY2xlYXJseSBpbiBzaXRlLiAgICAo YW5kIHVuZm9ydHVuYXRlbHksICBibGlzc2Z1bGx5IGNvbnRlbnQgdG8gc3RheSB0aGVyZSku ICANCg0KVG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBsb2dpY2FsIHRyYW5zaXRpb24gcGhhc2Vz IHNob3VsZCBiZSBhbmQgdG8gcHJvdmlkZSAgc29tZSByZWxhdGl2ZSBndWlkYW5jZSBvbiBp bXBsZW1lbnRhdGlvbiBjaG9pY2VzLCB3aWxsIGJlIGVmZmVjdGl2ZSBpbiBtb3RpdmF0aW5n IG1hbnkgb2YgdXMgY3VycmVudGx5IGxvb2tpbmcgZm9yIGV4Y3VzZXMgdG8gIkRvIE5vdGhp bmciIGluIHRoZSBJUHY2IGRlcGxveW1lbnQgIHNwYWNlLiAgDQoNCldoZW4geW91IHNhaWQ6 DQoNCiIgIE1hbnkgbmV0d29ya3MgY29udGludWUgdG8ga2ljayB0aGUgdGlyZXMsIGxhY2tp bmcgYSBidXNpbmVzcw0KICAgcmVxdWlyZW1lbnQgdG8gZ28gdG8gdGhlIG5leHQgc3RlcC4i DQoNClRoaXMgaXMgc3BvdCBvbiBhbmQgcmVhbGx5IGhpdHMgIGhvbWUgZm9yIG1hbnkgb2Yg dXMgZW50ZXJwcmlzZXMuICAgIFdlIGN1cnJlbnRseSBoYXZlIElQdjYgb24gIG91ciBjbGll bnRzIGFuZCBzZXJ2ZXJzIChtb3N0bHkgYmVjYXVzZSBpdCBpcyBlYXNpZXIgdGhhbiB0cnlp bmcgdG8gZmlndXJlIG91dCBob3cgdG8gcmVtb3ZlIGl0KSwgb24gbG9jYWwgbGlua3Mgb25s eS4gICBXZSBhbHNvIGhhdmUgSVB2NiBpbiBsYWJzICAgICAgICAgIEJ1dCBubyBJUHY2ICB0 cmFmZmljIGNyb3NzaW5nIGFueSBsYXllciAzICBib3VuZGFyaWVzIG9yIGJlaW5nIHRyYW5z ZmVycmVkIHRvIGFueSBtZWFuaW5nZnVsIGRlc3RpbmF0aW9ucyAgKHByb2R1Y3Rpb24gYXBw bGljYXRpb25zLCBpbnRlci1vcmdhbml6YXRpb25hbCBzZXJ2ZXJzLCAgSW50ZXJuZXQgc2l0 ZXMsICAgZXRjLiApLiAgICAgIA0KDQpTbyBhc3Npc3RhbmNlLCBhZHZpY2UsIGd1aWRhbmNl LCBlbmNvdXJhZ2VtZW50IG9yIGhvd2V2ZXIgeW91IG1heSBjYXRlZ29yaXplIHRoaXMgZG9j dW1lbnQsICBpdCB3b3VsZCAgYmUgaGVscGZ1bCB0byB0aG9zZSBvZiB1cyBjdXJyZW50bHkg ZGVhbGluZyB3aXRoIG91ciBmZWFycyBvZiBkb2luZyBzb21ldGhpbmcgbWVhbmluZ2Z1bCB3 aXRoIElQdjYuICAJDQoNCg0KSU1ITywgIGlmIHRoaXMgZHJhZnQgbW92ZXMgZm9yd2FyZCwg ICBWNk9QUyB3b3VsZCBhcHBlYXIgdG8gYmUgdGhlIGFwcHJvcHJpYXRlIFdHLiAgIFdpdGgg c3VwcG9ydCBmcm9tIFN1bnNldFY0IC4gDQoNCklmIHlvdSBkbyBjb250aW51ZSB3aXRoIHRo aXMgZHJhZnQsICBJIHdvdWxkIGJlIG1vcmUgdGhhbiB3aWxsaW5nIHRvIGFzc2lzdCBpbiBh bnkgd2F5IHlvdSBkZWVtIGFwcHJvcHJpYXRlLiAgDQoNCg0KU28sIHRoYW5rcyBhZ2FpbiBm b3IgZG9pbmcgdGhpcy4gIA0KDQpNaWtlICANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEZyZWQgQmFrZXIgKGZyZWQpDQpTZW50OiBGcmlkYXksIEFwcmlsIDAzLCAyMDE1 IDE6MzUgUE0NClRvOiBHZW9yZ2UsIFdlcw0KQ2M6IElQdjYgT3BzIFdHOyBzdW5zZXQ0QGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJUHY0IHRyYWplY3RvcnkNCg0KRHVtYiBx dWVzdGlvbi4gVGhlcmUgd2VyZSBhdCBsZWFzdCBhIGNvdXBsZSBvZiBjb21tZW50cyBlYXJs eSBpbiB0aGUgdGhyZWFkIGFib3V0IOKAnHdlIHNob3VsZCBoYXZlIGFuIElEIHRoYXQgc2F5 cyB0aGlz4oCdLiBJIGhhY2tlZCBvbmUgdG9nZXRoZXIsIGJhc2ljYWxseSBhbiB1cGRhdGVk IHZlcnNpb24gb2YgdGhlIGVtYWlsLg0KDQooMSkgYXJlIHdlIGludGVyZXN0ZWQgZW5vdWdo IHRvIGFjdHVhbGx5IGhhdmUgYSBkcmFmdCwgb3IgZG9lcyBpdCBqdXN0IHNlZW0gY3V0ZT8N CigyKSBpZiB3ZeKAmXJlIGludGVyZXN0ZWQgZW5vdWdoIHRvIGhhdmUgYSBkcmFmdCwgd2hh dCB3b3JraW5nIGdyb3VwPw0KKDMpIGlmIHdl4oCZcmUgaW50ZXJlc3RlZCBlbm91Z2ggdG8g aGF2ZSBhIGRyYWZ0LCBpdCBzZWVtcyB0byBtZSB0aGF0IEkgc2hvdWxkIGhhdmUgMS0zIGNv LWF1dGhvcnMsIGZyb20gU1AsIGVudGVycHJpc2UsIGFuZCBwZXJoYXBzIENETiBlbnZpcm9u bWVudHMsIHRoYXQgY2FuIGNvbW1lbnQgd2l0aCBzb21lIGF1dGhvcml0eSBhYm91dCB0aGUg cHJvY2VzcyBhbmQgY29uc2lkZXJhdGlvbnMgaW4gdGhlaXIgZW52aXJvbm1lbnRzLiBJIHdv dWxkIHdhbnQgdGhlIGNvLWF1dGhvcnMgdG8gYWRkIHRleHQgYXMgdGhleSBkZWVtIGl0IGFw cHJvcHJpYXRlLg0KDQpTZWUgYXR0YWNoZWQuDQoNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRv IHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlz IGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwg YnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVj ZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFu eSBjb3BpZXMuCiAKIEJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJs dWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25z IGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUg U2hpZWxkIEFzc29jaWF0aW9uLgo= From nobody Fri Apr 3 11:47: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 451A11ACF5D for ; Fri, 3 Apr 2015 11:47:25 -0700 (PDT) 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 edi7pKMwC2e5 for ; Fri, 3 Apr 2015 11:47:24 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E351ACF58 for ; Fri, 3 Apr 2015 11:47:24 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t33IknTw025030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Apr 2015 11:46:49 -0700 (PDT) Message-ID: <551EE019.3040100@isi.edu> Date: Fri, 03 Apr 2015 11:46:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brian E Carpenter , "Fred Baker (fred)" , Alexandru Petrescu References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no> <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com> <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com> <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> In-Reply-To: <55161E85.8020806@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] why IPv6 EHs in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 18:47:25 -0000 On 3/27/2015 8:22 PM, Brian E Carpenter wrote: >>> I understand the security risk, I think; that’s discussed in RFC >>> 5095. I’ll note, however, that the RFC doesn’t address “routing >>> headersâ€; it addresses “routing headers of type 0â€. The Segment >>> Routing header is a Routing Header, and trashing all Segment >>> Routing traffic because we have an issue with RH0 traffic seems a >>> trifle extreme. > > This is laid out precisely in RFC 7045*, so you can tell any operator > that trashes all RH packets that they are in violation and the protocol > police are very angry with them. > > Brian While I appreciate that screaming to operators isn't going to do much, we need to find a way to encourage the operators to *ask for their money back* from vendors who claim support for IPv6 but don't actually support IPv6. That's the lever we should find a way to pull. Joe From nobody Fri Apr 3 13:56: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 75ACC1A1B8E for ; Fri, 3 Apr 2015 13:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 0qZeiOvYqBW9 for ; Fri, 3 Apr 2015 13:56:39 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 2B0ED1A1B65 for ; Fri, 3 Apr 2015 13:56:39 -0700 (PDT) Received: by obbec2 with SMTP id ec2so183467703obb.3 for ; Fri, 03 Apr 2015 13:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UmWR7hkFMFYfXL+cQQH/Gn4M13iEsu7166CBtRguHZ0=; b=Xayl8YrQPffyH/icB8QO/D5L+U2aMWToCeSdRwk4L1i3gZwq62Qu4z+pe6a1v+pNf/ RBaR0p7+I3lbQYdbE8XsfKf41ZbwCPfueCfPbSahVEeeWMhhNLRlwYIGCj3mkEUm5D85 Q7LNmok0dJpS+3ti5EHlbUXvW+xzUbx2NK1Ww= 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=UmWR7hkFMFYfXL+cQQH/Gn4M13iEsu7166CBtRguHZ0=; b=d9bHPWFLUYLrW4gKWYhwB4tiu5+MiErDh5oao/NDUX/L1feM3IbWVFfJG/eHpNmj/y t6y4mh2cj7slNnm5hYFebp4H9ZpbXdw3OASqRmlTsiSfAkWEFSbehvnj0agmwtcTR4Wi ZyE0HX1lmu8UEiQ2R094V1ZXs5BpmAdNK/rhYP0qqs04qnTdPLVVk+I/5Dw0C0GGq78/ YKUPyz3p6MZfJScMKpMWOPKt9I9+OUq6j+5H6xmz2YvWwfmE09vT5hlmMcbPdURQ1r5V OPUOUNavn7t0jq84eeoITKMaWo4E+9aEsaP7iLBDTb6yEnXAtFQuXtJwO2l4TUp2fo0j dobA== X-Gm-Message-State: ALoCoQmz0nCxpcSHEtoxv5QIsO44EjNT9eO9rZlKdOg5mmo5U8vv1VTizy2NmQAg+suVLMQ5uu6q MIME-Version: 1.0 X-Received: by 10.60.116.102 with SMTP id jv6mr5035708oeb.50.1428094598675; Fri, 03 Apr 2015 13:56:38 -0700 (PDT) Received: by 10.76.177.229 with HTTP; Fri, 3 Apr 2015 13:56:38 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Fri, 3 Apr 2015 15:56:38 -0500 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=089e0115ef4042981e0512d82f42 Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 20:56:40 -0000 --089e0115ef4042981e0512d82f42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 3, 2015 at 9:23 AM, George, Wes wrote: > Interestingly, most of the above statement still works if you do > %s/IPv4 Literals/Adobe Flash/g, though Android has hopped on that > particular bandwagon too. > That analogy *IS* interesting, isn't it? Can you imagine what the reaction would be if carriers had responded to the introduction of handsets without support for Flash by insisting that the HTML5 solution for replacing Flash be available only to handsets that also support Flash programming interfaces as a translation layer in the platform? You're simply advocating for pushing this problem and therefore all efforts > to motivate people to stop using IPv4 literals back onto the carriers [..= .] > I see myself advocating against permitting the carriers to escape responsibility. As I view it, they snoozed while operating systems people worked diligently to make dual-stack hosts ready for the transition. Now they'd like an easy escape=E2=80=94 asking for host operating systems and applications to maintain the transitional state indefinitely, while they make a clean break to green fields now. If there is a good and fair reason to shift these burdens from the carriers onto others, then I'm failing to recognize it. I'm not saying there isn't one. Just that I don't know what it could be. --=20 james woodyatt Nest Labs, Communications Engineering --089e0115ef4042981e0512d82f42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 9:23 AM, George, Wes <wesley.george@twcable.com= > wrote:
Interestingly, most of the above statement still works if you do %s/IP= v4 Literals/Adobe Flash/g, though Android has hopped on that particular ban= dwagon too.

That an= alogy *IS* interesting, isn't it? Can you imagine what the reaction wou= ld be if carriers had responded to the introduction of handsets without sup= port for Flash by insisting that the HTML5 solution for replacing Flash be = available only to handsets that also support Flash programming interfaces a= s a translation layer in the platform?

You're simply advocating for pushing this problem and therefore al= l efforts to motivate people to stop using IPv4 literals back onto the carr= iers [...]

I see myself advocat= ing against permitting the carriers to escape responsibility. As I view it,= they snoozed while operating systems people worked diligently to make dual= -stack hosts ready for the transition. Now they'd like an easy escape= =E2=80=94 asking for host operating systems and applications to maintain th= e transitional state indefinitely, while they make a clean break to green f= ields now.

If there is a good and fair reason to s= hift these burdens from the carriers onto others, then I'm failing to r= ecognize it. I'm not saying there isn't one. Just that I don't = know what it could be.


--
james woodyatt <jhw@nestlabs.com>
Nest= Labs, Communications Engineering
--089e0115ef4042981e0512d82f42-- From nobody Fri Apr 3 13:57: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 A21C01A19E3 for ; Fri, 3 Apr 2015 13:57:45 -0700 (PDT) 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 NO7pTabnztQU for ; Fri, 3 Apr 2015 13:57:44 -0700 (PDT) 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 738E21A0217 for ; Fri, 3 Apr 2015 13:57:44 -0700 (PDT) Received: by igcau2 with SMTP id au2so107281311igc.0 for ; Fri, 03 Apr 2015 13:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I99vPwyYXwQ3dzNwY+9TBTUzM17wzrIoMBSKdRUa2/k=; b=OC8GADUzDcRiWM6rL7PQbUEhTML3TFV95F3fj+Dundl1jNzFKjtwkHYzdL6nC2zFKX SETDzlC8V/BjJesGVAj0FezOx3zuY2Zd8b7cWf7oidRUju4WL+MT+spOUQ3ji1/Qpkiy C1+2ejymMH1C4JYxhtSgEyJTXHkkg7RBIVbFBgmtClcCd5jtdCDHOhebGE3596Jogsp/ 4fpqTv7LbNk3ADUxjmzxtvoJzUaJLgqUNCYq8BGaCDN+OPPTw+d1lPoUdeJHSm+Z5b5C 52Schf+LCk9v6erK/GJ63AOW33Lxa9T10SWfo4wyZoOSrDzL7huWg0Dbj2c5anOAbWLh xeJA== 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=I99vPwyYXwQ3dzNwY+9TBTUzM17wzrIoMBSKdRUa2/k=; b=juqpShqVf6YRQqdL9ekdM5Fb4UocftKgtuwtcWFvYv8roS6Rum853/rkGNfOJ2Q3v3 aXlMygSaLDyd7kbxLnPpIJnZWaCq6phEpDdO7UIF1tW64JF6Zz6JWqQ9iluLQQs/ytvL pwb4mOtd3qYDkaZV39/GjTA3oRHxM9mzqVAumUEats0k2fUJ30nJMglt74uGPJCLOHIi Dqiiq5sfI+UBZByIjxdYXbO8DKowTEa9xsIR0INVR1yuDVBPcelK4OFXy4tLidQMd6fX uF9+1l7phL/VBYEkiphRSpxnDJUGylXmQ2Elb9D7NEZVNf1IFutMQV06mXPMhDdXofEv w98g== X-Gm-Message-State: ALoCoQn/IQltYkikdFVyS3h85R9x/jN522aWvlzFKd/+viFvw/Zj/IkeJM2TaX2TVDmsVeNpxFMP MIME-Version: 1.0 X-Received: by 10.107.34.210 with SMTP id i201mr6552723ioi.1.1428094663839; Fri, 03 Apr 2015 13:57:43 -0700 (PDT) Received: by 10.64.195.75 with HTTP; Fri, 3 Apr 2015 13:57:43 -0700 (PDT) Received: by 10.64.195.75 with HTTP; Fri, 3 Apr 2015 13:57:43 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Sat, 4 Apr 2015 05:57:43 +0900 Message-ID: From: Lorenzo Colitti To: James Woodyatt Content-Type: multipart/alternative; boundary=001a114031a024f2790512d83364 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 20:57:45 -0000 --001a114031a024f2790512d83364 Content-Type: text/plain; charset=UTF-8 On 4 Apr 2015 3:08 am, "James Woodyatt" wrote: > That's an overly general statement, which is why I'm pushing back. A more specific statement you could make is that the IPv4 programming interfaces need to be supported on general-purpose multi-program hosts that operate on IPv6-only networks which bear a strong resemblance to yours. James, what do you purpose as a better alternative? Suppose that, as you say, not all popular OSes implement 464xlat. Aren't we just changing the outcome from "we'll never get away from IPv4-only socket calls" to "we'll never get away from running IPv4"? If so, how is that better? You could well argue that for as long as IPv4 is around, we'll never get rid of IPv4 socket calls either, because it's impossible for anyone to impose a "thou shalt not write an IPv4-only app" policy without placing themselves at a competitive disadvantage. Cheers, Lorenzo --001a114031a024f2790512d83364 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 4 Apr 2015 3:08 am, "James Woodyatt" <jhw@nestlabs.com> wrote:

> That's an overly general statement, which is why I&= #39;m pushing back. A more specific statement you could make is that the IP= v4 programming interfaces need to be supported on general-purpose multi-pro= gram hosts that operate on IPv6-only networks which bear a strong resemblan= ce to yours.

James,

what do you purpose as a better alternative?

Suppose that, as you say, not all popular OSes implement 464= xlat. Aren't we just changing the outcome from "we'll never ge= t away from IPv4-only socket calls" to "we'll never get away = from running IPv4"? If so, how is that better?

You could well argue that for as long as IPv4 is around, we&= #39;ll never get rid of IPv4 socket calls either, because it's impossib= le for anyone to impose a "thou shalt not write an IPv4-only app"= policy without placing themselves at a competitive disadvantage.

Cheers,
Lorenzo

--001a114031a024f2790512d83364-- From nobody Fri Apr 3 14:10: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 D22F11A1C03 for ; Fri, 3 Apr 2015 14:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enxFXwPBwTAD for ; Fri, 3 Apr 2015 14:10:32 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6821A19F2 for ; Fri, 3 Apr 2015 14:10:31 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 9BB9725D3A95; Fri, 3 Apr 2015 21:10:29 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id E5DEEC77048; Fri, 3 Apr 2015 21:10:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id EGx8LHksx-si; Fri, 3 Apr 2015 21:10:27 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:7448:67fa:8f81:c515] (unknown [IPv6:fde9:577b:c1a9:4410:7448:67fa:8f81:c515]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D2E0BC77047; Fri, 3 Apr 2015 21:10:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Bjoern A. Zeeb" In-Reply-To: Date: Fri, 3 Apr 2015 21:10:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <04B1F6B3-C406-4592-9BE9-04BF4099455C@lists.zabbadoz.net> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 21:10:34 -0000 > On 03 Apr 2015, at 20:57 , Lorenzo Colitti wrote: >=20 > On 4 Apr 2015 3:08 am, "James Woodyatt" wrote: >=20 > > That's an overly general statement, which is why I'm pushing back. A = more specific statement you could make is that the IPv4 programming = interfaces need to be supported on general-purpose multi-program hosts = that operate on IPv6-only networks which bear a strong resemblance to = yours. >=20 > James, >=20 > what do you purpose as a better alternative? >=20 > Suppose that, as you say, not all popular OSes implement 464xlat. = Aren't we just changing the outcome from "we'll never get away from = IPv4-only socket calls" to "we'll never get away from running IPv4"? If = so, how is that better? >=20 > You could well argue that for as long as IPv4 is around, we'll never = get rid of IPv4 socket calls either, because it's impossible for anyone = to impose a "thou shalt not write an IPv4-only app" policy without = placing themselves at a competitive disadvantage. Ok, so we need a monthly global =E2=80=9Cwe=E2=80=99ll get rid of all = these 512k IPv4 prefixes in BGP for you=E2=80=9D-day and the problem = will be solved by christmas. It=E2=80=99s probably good enough if 5 = major transport networks will do it once for a start, very much like 5 = major content players started making loud noises 10 years to late for = IPv6. June 6 2016? Who=E2=80=99s in for a long weekend? If you can say crazy things, so can I. =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From nobody Fri Apr 3 14:15: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 D2ED71A1A80 for ; Fri, 3 Apr 2015 14:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqrKeEx494Uy for ; Fri, 3 Apr 2015 14:15:15 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 D6EBD1A1A65 for ; Fri, 3 Apr 2015 14:15:14 -0700 (PDT) Received: by widdi4 with SMTP id di4so117479973wid.0 for ; Fri, 03 Apr 2015 14:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BDqXczM64f0YpeSEAYEvT9F9x5GcDFIniiRXoWRtuzE=; b=Z4sdaoIBls9dD/EcRJfImT4D2YQxUs/3CSBqC5gf+7kI41o/vJGI94oh24oSJxLHR1 rSuYox1Eu3Z/bhTPP3tI80IFujIW8yWLHK5XAArdOy3yTDMK0UXGrxijQijYhyN8FilO lV0WhcWvL7mYH8suNlHzzUWa3MwXru9doXPVF6q+WkhpZ+WeEKwssdloxzKyn1zWoLsp MqdfFQjLP+Nf5eF5Zft0lmOUXBFRHUoz7Y2qPC5lHBD7zAMOQdxnWSM8zxz4GBuWWIg0 adjAxYN+yV5+QGpYrowmDGYJyeG6ddKamLVgtDcGKiWKuk3tR974tgS6HkWYMwH4ca16 QApg== MIME-Version: 1.0 X-Received: by 10.180.95.10 with SMTP id dg10mr660142wib.41.1428095713507; Fri, 03 Apr 2015 14:15:13 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Fri, 3 Apr 2015 14:15:13 -0700 (PDT) In-Reply-To: <04B1F6B3-C406-4592-9BE9-04BF4099455C@lists.zabbadoz.net> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> <04B1F6B3-C406-4592-9BE9-04BF4099455C@lists.zabbadoz.net> Date: Fri, 3 Apr 2015 14:15:13 -0700 Message-ID: From: Ca By To: "Bjoern A. Zeeb" Content-Type: multipart/alternative; boundary=f46d04447f83b57ea40512d87195 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 21:15:17 -0000 --f46d04447f83b57ea40512d87195 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 3, 2015 at 2:10 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > > On 03 Apr 2015, at 20:57 , Lorenzo Colitti wrote: > > > > On 4 Apr 2015 3:08 am, "James Woodyatt" wrote: > > > > > That's an overly general statement, which is why I'm pushing back. A > more specific statement you could make is that the IPv4 programming > interfaces need to be supported on general-purpose multi-program hosts th= at > operate on IPv6-only networks which bear a strong resemblance to yours. > > > > James, > > > > what do you purpose as a better alternative? > > > > Suppose that, as you say, not all popular OSes implement 464xlat. Aren'= t > we just changing the outcome from "we'll never get away from IPv4-only > socket calls" to "we'll never get away from running IPv4"? If so, how is > that better? > > > > You could well argue that for as long as IPv4 is around, we'll never ge= t > rid of IPv4 socket calls either, because it's impossible for anyone to > impose a "thou shalt not write an IPv4-only app" policy without placing > themselves at a competitive disadvantage. > > Ok, so we need a monthly global =E2=80=9Cwe=E2=80=99ll get rid of all the= se 512k IPv4 > prefixes in BGP for you=E2=80=9D-day and the problem will be solved by ch= ristmas. > It=E2=80=99s probably good enough if 5 major transport networks will do i= t once for > a start, very much like 5 major content players started making loud noise= s > 10 years to late for IPv6. June 6 2016? Who=E2=80=99s in for a long wee= kend? > > If you can say crazy things, so can I. > > On my mobile network, this is really not that crazy of a statement at all. I just need one more mobile OS vendor to implement 464XLAT and IPv6-only will be every device of any consequence by default in the store. CB > =E2=80=94 > Bjoern A. Zeeb Charles Haddon Spurgeon: > "Friendship is one of the sweetest joys of life. Many might have failed > beneath the bitterness of their trial had they not found a friend." > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d04447f83b57ea40512d87195 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 3, 2015 at 2:10 PM, Bjoern A. Zeeb <bzeeb-lis= ts@lists.zabbadoz.net> wrote:

> On 03 Apr 2015, at 20:57 , Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On 4 Apr 2015 3:08 am, "James Woodyatt" <jhw@nestlabs.com> wrote:
>
> > That's an overly general statement, which is why I'm push= ing back. A more specific statement you could make is that the IPv4 program= ming interfaces need to be supported on general-purpose multi-program hosts= that operate on IPv6-only networks which bear a strong resemblance to your= s.
>
> James,
>
> what do you purpose as a better alternative?
>
> Suppose that, as you say, not all popular OSes implement 464xlat. Aren= 't we just changing the outcome from "we'll never get away fro= m IPv4-only socket calls" to "we'll never get away from runni= ng IPv4"? If so, how is that better?
>
> You could well argue that for as long as IPv4 is around, we'll nev= er get rid of IPv4 socket calls either, because it's impossible for any= one to impose a "thou shalt not write an IPv4-only app" policy wi= thout placing themselves at a competitive disadvantage.

Ok, so we need a monthly global =E2=80=9Cwe=E2=80=99ll get rid = of all these 512k IPv4 prefixes in BGP for you=E2=80=9D-day and the problem= will be solved by christmas.=C2=A0 It=E2=80=99s probably good enough if 5 = major transport networks will do it once for a start, very much like 5 majo= r content players started making loud noises 10 years to late for IPv6.=C2= =A0 June 6 2016?=C2=A0 Who=E2=80=99s in for a long weekend?

If you can say crazy things, so can I.



<= /div>
On my mobile network, this is really not that crazy of a statemen= t at all.

I just need one more mobile OS vendor to= implement 464XLAT and IPv6-only will be every device of any consequence by= default in the store.

CB=C2=A0
=E2=80=94
Bjoern A. Zeeb=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Charles Haddon = Spurgeon:
"Friendship is one of the sweetest joys of life.=C2=A0 Many might have= failed
=C2=A0beneath the bitterness of their trial=C2=A0 had they not found a frie= nd."

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

--f46d04447f83b57ea40512d87195-- From nobody Fri Apr 3 14:15: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 D39C71A87BD for ; Fri, 3 Apr 2015 14:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_4g3D-S3KpD for ; Fri, 3 Apr 2015 14:15:19 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 B104A1A875A for ; Fri, 3 Apr 2015 14:15:19 -0700 (PDT) Received: by obbec2 with SMTP id ec2so183912493obb.3 for ; Fri, 03 Apr 2015 14:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=inGpjzZH8mjxQmvwLUGYfPnjMM8Bev5O4G2Qlo4OCbE=; b=hCxyXS8y0aP37pL1wQge37en+Jndc16RECGCNEW7w9+7J0gvtNgmXDv0Gn2G1+4RZv yxWB3eEn44a2wtMRpPnc+MdocwFUNYyhwLrMN43HxFhXXKRO0XjuxZv/zv0EGOhO223y BUbYTAM9I4qx2aMCZ08TV43JnwLa/jdeozreg= 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=inGpjzZH8mjxQmvwLUGYfPnjMM8Bev5O4G2Qlo4OCbE=; b=KKxDBJXJth4sH2S63EjktZO5rl+Xo+R37/WT7efrVKqQpatpmW0JC2fJrNGz9Fymax UFJFXzoWaZKLOy0YUfHrPgWNeOWxDG4etlOa76euy2XLJHrW5fA1efmIuj4u6qRB9rQi u2ODk7T7XFgeHy0i7Pl0IV4iZOMomCJ3UpJAfUKi3P6ZY3YGpvDx2rjoeHjl/W9wJHWW YlAWlnOUJ30yfXpxdks1e5ZvYo7ksrXBv05G+UbabzVphULhFt88CVFtyR78m+8sBhLY SgU3nF8ExtLpm2+sRSQ4BrNzUtJpdrfLm81PGKnPE+/NKji+PG1dbDSfHJ/5rmU9nwGV J3Fg== X-Gm-Message-State: ALoCoQnSS6TYuAgPzn9Sr63IqslgnLu8n04gzGc1e/ZM08a4iAMCre/T4UiAiuW/+Ls16wyOHWLD MIME-Version: 1.0 X-Received: by 10.182.215.133 with SMTP id oi5mr5072433obc.55.1428095719159; Fri, 03 Apr 2015 14:15:19 -0700 (PDT) Received: by 10.76.177.229 with HTTP; Fri, 3 Apr 2015 14:15:18 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Fri, 3 Apr 2015 16:15:18 -0500 Message-ID: From: James Woodyatt To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11c254340bce520512d872ed Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 21:15:28 -0000 --001a11c254340bce520512d872ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 3, 2015 at 3:57 PM, Lorenzo Colitti wrote: > what do you purpose as a better alternative? > I propose that IETF decline the invitation to publish a BCP to the effect that host OS implementations should include a CLAT function. Aren't we just changing the outcome from "we'll never get away from > IPv4-only socket calls" to "we'll never get away from running IPv4"? I think the former entails the latter. I think we get away from running IPv4 by deliberately and carefully removing support for IPv4 from application developers and users in a way that continuously makes forward progress at a manageable and predictable expense. If we deploy CLAT everywhere, then we will be making IPv4 more difficult to displace by removing support for it in the network. You could well argue that for as long as IPv4 is around, we'll never get > rid of IPv4 socket calls either, because it's impossible for anyone to > impose a "thou shalt not write an IPv4-only app" policy without placing > themselves at a competitive disadvantage. Is it really impossible? Because that's exactly what Facebook did=E2=80=94 = impose a "thou shalt not use IPv4" policy on its internal developers, and it doesn't look to me like it put them at a competitive disadvantage. Have you looked at Google+ lately? In fact, I suspect they might have found it more difficult if the majority of their developers were using workstations that had CLAT implementations in their operating systems. Taking away IPv4 was a critical step for them, according to what their delegation to the World IPv6 Congress reported earlier this month. If their developers could have still written IPv4 applications and relied on the system to translate it into IPv6 on their interior networks, then I think it would have greatly complicated transition. --=20 james woodyatt Nest Labs, Communications Engineering --001a11c254340bce520512d872ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 3:57 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:

what do = you purpose as a better alternative?=C2=A0

= I propose that IETF decline the invitation to publish a BCP to the effect t= hat host OS implementations should include a CLAT function.

=
Aren= 9;t we just changing the outcome from "we'll never get away from I= Pv4-only socket calls" to "we'll never get away from running = IPv4"?

I think the former entai= ls the latter. I think we get away from running IPv4 by deliberately and ca= refully removing support for IPv4 from application developers and users in = a way that continuously makes forward progress at a manageable and predicta= ble expense. If we deploy CLAT everywhere, then we will be making IPv4 more= difficult to displace by removing support for it in the network.

You could well argue that for as long as IPv4 is around, we'll neve= r get rid of IPv4 socket calls either, because it's impossible for anyo= ne to impose a "thou shalt not write an IPv4-only app" policy wit= hout placing themselves at a competitive disadvantage.
<= div>
Is it really impossible? Because t= hat's exactly what Facebook did=E2=80=94 impose a "thou shalt not = use IPv4" policy on its internal developers, and it doesn't look t= o me like it put them at a competitive disadvantage. Have you looked at Goo= gle+ lately?
=
In fact,= I suspect they might have found it more difficult if the majority of their= developers were using workstations that had CLAT implementations in their = operating systems. Taking away IPv4 was a critical step for them, according= to what their delegation to the World IPv6 Congress reported earlier this = month. If their developers could have still written IPv4 applications and r= elied on the system to translate it into IPv6 on their interior networks, t= hen I think it would have greatly complicated transition.
=

--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Com= munications Engineering
--001a11c254340bce520512d872ed-- From nobody Fri Apr 3 14:19: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 9DB781A882A for ; Fri, 3 Apr 2015 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqXc_N-QSG9S for ; Fri, 3 Apr 2015 14:19:14 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0181A6FFC for ; Fri, 3 Apr 2015 14:19:14 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6B9BB25D3A42; Fri, 3 Apr 2015 21:19:12 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B3A13C77046; Fri, 3 Apr 2015 21:19:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 1JTrBcpxzEpO; Fri, 3 Apr 2015 21:19:10 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:7448:67fa:8f81:c515] (unknown [IPv6:fde9:577b:c1a9:4410:7448:67fa:8f81:c515]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B1B78C76FCD; Fri, 3 Apr 2015 21:19:09 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Bjoern A. Zeeb" In-Reply-To: Date: Fri, 3 Apr 2015 21:19:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5B9E9FC4-5949-4B44-B3DC-B581DFAD509D@lists.zabbadoz.net> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> <04B1F6B3-C406-4592-9BE9-04BF4099455C@lists.zabbadoz.net> To: Ca By X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 21:19:15 -0000 > On 03 Apr 2015, at 21:15 , Ca By wrote: >=20 >=20 >=20 > On Fri, Apr 3, 2015 at 2:10 PM, Bjoern A. Zeeb = wrote: >=20 > > On 03 Apr 2015, at 20:57 , Lorenzo Colitti = wrote: > > > > On 4 Apr 2015 3:08 am, "James Woodyatt" wrote: > > > > > That's an overly general statement, which is why I'm pushing back. = A more specific statement you could make is that the IPv4 programming = interfaces need to be supported on general-purpose multi-program hosts = that operate on IPv6-only networks which bear a strong resemblance to = yours. > > > > James, > > > > what do you purpose as a better alternative? > > > > Suppose that, as you say, not all popular OSes implement 464xlat. = Aren't we just changing the outcome from "we'll never get away from = IPv4-only socket calls" to "we'll never get away from running IPv4"? If = so, how is that better? > > > > You could well argue that for as long as IPv4 is around, we'll never = get rid of IPv4 socket calls either, because it's impossible for anyone = to impose a "thou shalt not write an IPv4-only app" policy without = placing themselves at a competitive disadvantage. >=20 > Ok, so we need a monthly global =E2=80=9Cwe=E2=80=99ll get rid of all = these 512k IPv4 prefixes in BGP for you=E2=80=9D-day and the problem = will be solved by christmas. It=E2=80=99s probably good enough if 5 = major transport networks will do it once for a start, very much like 5 = major content players started making loud noises 10 years to late for = IPv6. June 6 2016? Who=E2=80=99s in for a long weekend? >=20 > If you can say crazy things, so can I. >=20 >=20 >=20 > On my mobile network, this is really not that crazy of a statement at = all. >=20 > I just need one more mobile OS vendor to implement 464XLAT and = IPv6-only will be every device of any consequence by default in the = store. No. And no. What you need is that things just work IPv6 end-to-end. =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From nobody Fri Apr 3 14:23: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 8808B1A1A8C for ; Fri, 3 Apr 2015 14:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUP7AvWDv_A5 for ; Fri, 3 Apr 2015 14:23:35 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (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 D22D51A1A83 for ; Fri, 3 Apr 2015 14:23:34 -0700 (PDT) Received: by wgra20 with SMTP id a20so119451778wgr.3 for ; Fri, 03 Apr 2015 14:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pP+ytECln/as6dJWqz9Df3+cpBDJNMAMqMji72k3jlo=; b=liRICiiEf6BefVFdWbQbI2MI380Z0jz09RmcY+HDIGQ0xihgY5PTBeG1ABO9uYz0Cl j4vpPhdgo2XI6+BdbBttSeaw26y9hpoYuBIJDszbncXG0N5+b1GXsUzyXJafeQaAbPu9 ikzL+8GoqrCACioXHpx0xncip9rITMH6kgGB8wXuzHCFg20wCcMFgzMZt2PvRIkA1Ps1 C244OTYD2oq7phVrGeGN/GhXfabPuxEndPVxICpTOL1iFyRoqbmkKhdYAyMl7/Usgo4w VCzV199k9kZ6GsZ2jRSpCOVQf79aGAD9UQD5v8Rk0g5l7iA44xWp8pzZ+0Adi9C9M4fw JdEQ== MIME-Version: 1.0 X-Received: by 10.194.61.161 with SMTP id q1mr8754531wjr.132.1428096213430; Fri, 03 Apr 2015 14:23:33 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Fri, 3 Apr 2015 14:23:33 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Fri, 3 Apr 2015 14:23:33 -0700 Message-ID: From: Ca By To: James Woodyatt Content-Type: multipart/alternative; boundary=047d7ba9722a81b61d0512d88f3b Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 21:23:37 -0000 --047d7ba9722a81b61d0512d88f3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 3, 2015 at 2:15 PM, James Woodyatt wrote: > On Fri, Apr 3, 2015 at 3:57 PM, Lorenzo Colitti > wrote: > >> what do you purpose as a better alternative? >> > I propose that IETF decline the invitation to publish a BCP to the effect > that host OS implementations should include a CLAT function. > > Aren't we just changing the outcome from "we'll never get away from >> IPv4-only socket calls" to "we'll never get away from running IPv4"? > > > I think the former entails the latter. I think we get away from running > IPv4 by deliberately and carefully removing support for IPv4 from > application developers and users in a way that continuously makes forward > progress at a manageable and predictable expense. If we deploy CLAT > everywhere, then we will be making IPv4 more difficult to displace by > removing support for it in the network. > > You could well argue that for as long as IPv4 is around, we'll never get >> rid of IPv4 socket calls either, because it's impossible for anyone to >> impose a "thou shalt not write an IPv4-only app" policy without placing >> themselves at a competitive disadvantage. > > > Is it really impossible? Because that's exactly what Facebook did=E2=80= =94 impose > a "thou shalt not use IPv4" policy on its internal developers, and it > doesn't look to me like it put them at a competitive disadvantage. Have y= ou > looked at Google+ lately? > > In fact, I suspect they might have found it more difficult if the majorit= y > of their developers were using workstations that had CLAT implementations > in their operating systems. Taking away IPv4 was a critical step for them= , > according to what their delegation to the World IPv6 Congress reported > earlier this month. If their developers could have still written IPv4 > applications and relied on the system to translate it into IPv6 on their > interior networks, then I think it would have greatly complicated > transition. > > > The fundamental issue is that you have no control over these on the internet, https://sites.google.com/site/tmoipv6/ipv4literals You, and i, also have no control over what is implemented in signalling channels. Your sockets my be AF agnostic, but that does not stop the data structures for peer to peer apps being ipv4 addesses like Bittorent or Skype use. In fact, Skype works on iOS today on IPv6-only.... why? Because they built a CLAT into the App. It is a horrible idea of ask all the app vendors to invent their of unique CLAT. Because they have already reacted to the threat of IPv6-only... and this is what they do. Regarding the Flash analogy, that was one ecosystem acting unilaterally. The ecosystem is well invited to uniformly and unilaterally move forward with IPv6-only universally. They are not invited to say choose IPv6 or IPv4, and those that choose IPv6 only get 99% of the internet while the IPv4 guy gets 100% CB > -- > james woodyatt > Nest Labs, Communications Engineering > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7ba9722a81b61d0512d88f3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 3, 2015 at 2:15 PM, James Woodyatt <jhw@nestlabs.com>= ; wrote:
On Fri, Apr 3, 2015 at 3:5= 7 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

what do you purpose as a better alternative= ?=C2=A0

I propose that IETF decline = the invitation to publish a BCP to the effect that host OS implementations = should include a CLAT function.

Aren't we just= changing the outcome from "we'll never get away from IPv4-only so= cket calls" to "we'll never get away from running IPv4"?=

I think the former entails t= he latter. I think we get away from running IPv4 by deliberately and carefu= lly removing support for IPv4 from application developers and users in a wa= y that continuously makes forward progress at a manageable and predictable = expense. If we deploy CLAT everywhere, then we will be making IPv4 more dif= ficult to displace by removing support for it in the network.

You could well argue that for as long as IPv4 is around, w= e'll never get rid of IPv4 socket calls either, because it's imposs= ible for anyone to impose a "thou shalt not write an IPv4-only app&quo= t; policy without placing themselves at a competitive disadvantage.<= /blockquote>

Is it really i= mpossible? Because that's exactly what Facebook did=E2=80=94 impose a &= quot;thou shalt not use IPv4" policy on its internal developers, and i= t doesn't look to me like it put them at a competitive disadvantage. Ha= ve you looked at Google+ lately?

In fact, I suspect they might have found it more difficult if t= he majority of their developers were using workstations that had CLAT imple= mentations in their operating systems. Taking away IPv4 was a critical step= for them, according to what their delegation to the World IPv6 Congress re= ported earlier this month. If their developers could have still written IPv= 4 applications and relied on the system to translate it into IPv6 on their = interior networks, then I think it would have greatly complicated transitio= n.

<= br>


The fundamental issue is that you have no control over these on the= internet, h= ttps://sites.google.com/site/tmoipv6/ipv4literals

<= div>You, and i, also have no control over what is implemented in signalling= channels. Your sockets my be AF agnostic, but that does not stop the data = structures for peer to peer apps being ipv4 addesses like Bittorent or Skyp= e use.

In fact, Skype works on iOS today on IPv6-o= nly.... why?=C2=A0 Because they built a CLAT into the App.=C2=A0 It is a ho= rrible idea of ask all the app vendors to invent their of unique CLAT.=C2= =A0 Because they have already reacted to the threat of IPv6-only... and thi= s is what they do.


Regarding the Fl= ash analogy, that was one ecosystem acting unilaterally.=C2=A0 The ecosyste= m is well invited to uniformly and unilaterally move forward with IPv6-only= universally.=C2=A0 They are not invited to say choose IPv6 or IPv4, and th= ose that choose IPv6 only get 99% of the internet while the IPv4 guy gets 1= 00%

CB

=C2=A0
--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineer= ing

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


--047d7ba9722a81b61d0512d88f3b-- From nobody Fri Apr 3 15:02: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 244181A1ABB for ; Fri, 3 Apr 2015 15:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 iahnLsb-HnCo for ; Fri, 3 Apr 2015 15:02:22 -0700 (PDT) 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 35EBF1A1AB9 for ; Fri, 3 Apr 2015 15:02:22 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CE97CDA00BD; Fri, 3 Apr 2015 22:02:21 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 3 Apr 2015 15:02:21 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 3 Apr 2015 18:02:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1760E8FC-D057-4F6D-A277-B166299A04FA@nominum.com> References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> To: James Woodyatt X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 22:02:23 -0000 On Apr 3, 2015, at 4:56 PM, James Woodyatt wrote: > I see myself advocating against permitting the carriers to escape = responsibility. As I view it, they snoozed while operating systems = people worked diligently to make dual-stack hosts ready for the = transition. Now they'd like an easy escape=97 asking for host operating = systems and applications to maintain the transitional state = indefinitely, while they make a clean break to green fields now. I'm sympathetic, but I don't think this helps us. What we want is for = the transition to happen. Focusing on fairness isn't going to get us = anywhere because fairness really doesn't seem to motivate large = corporations to spend money unless there's substantial public = visibility, and I don't see that happening here. What I think is a more viable path to v6only is simply that at some = point it might become possible to charge a premium for NAT64, or else = silently degrade service on NAT64 without entirely breaking it, e.g. by = restricting the number of ports any host can get. This will put = v4-only apps and apps with IPv4 literals at a disadvantage, which might = motivate them to upgrade. Another thing that could motivate them to upgrade is if hosting = providers start to charge extra for IPv4 transit, because the amount of = market share they expect to lose as a result will not be significant = enough to worry them. But I think this will follow the NAT64 = translator cost effect, not lead it. The point being that I think 464XLAT is going to speed the transition, = not slow it, and if that sucks for O.S. vendors, well, that's why they = call it work... From nobody Fri Apr 3 15:06: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 30E321A1A94 for ; Fri, 3 Apr 2015 15:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 j5IYFgsuO16d for ; Fri, 3 Apr 2015 15:06:04 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 63A9B1A1AF0 for ; Fri, 3 Apr 2015 15:06:00 -0700 (PDT) Received: by obbec2 with SMTP id ec2so185002199obb.3 for ; Fri, 03 Apr 2015 15:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=omRYy5HdjWyRYnJ+fV2raxCsuM5sBG9Hx/2r8N/CSAQ=; b=m3I5+hcTsDM8souzAX4qeOS/iOGzPTgtdb4xzVA1mznv0eftFojsLDegV/GQBWY6Vt 6mpDJJMiFO1nR1bGxPZKNy+8wOYENNLibcZE1+bUCkdkHO/5KFzAqOSVZOvhKUY2AvwA QRtZCI9fviaWQWMtNsUgJeB0rpHRNlcdZ3KWQ= 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=omRYy5HdjWyRYnJ+fV2raxCsuM5sBG9Hx/2r8N/CSAQ=; b=e+NPZsOVWm4YKKEL3iCnIakZeuNmaZ8sckdrwWe9jj9gVZFbegbZu92so8434W0jZK hDe5Ep10FYKt4bhxEHnLTP7XfdjEr5T1k3kx6syn//1NDiYZoCnZkhPdHddf2cYwG7Z0 lo1MFmx3ryrWmOnHY/0/1OgGLjes+SKfbGqUATIQa28eNapIi+5ZyW4HUsC97k9dx8m8 jMqSfkMp7T0R09a66wl8CSmrQgz8dFiFpALXxvS+bbiC5sqNl+W8BKENYaxQbXaKp2jo FO3IZvPYfSqPnau5pnvFHEwJ/+C1hOw2KIyTvwwSx20hi0RSKOi6QUSC1HDjLx7P/wRg CwKQ== X-Gm-Message-State: ALoCoQmDhowYLxbYQPlRpHkI3lWvwqmLfy4YMb+OFwFOYbUcqYQAiIGvKM+kOotssHZTDDjuQEPq MIME-Version: 1.0 X-Received: by 10.60.165.68 with SMTP id yw4mr5187119oeb.76.1428098759881; Fri, 03 Apr 2015 15:05:59 -0700 (PDT) Received: by 10.76.177.229 with HTTP; Fri, 3 Apr 2015 15:05:59 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Fri, 3 Apr 2015 17:05:59 -0500 Message-ID: From: James Woodyatt To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=047d7b4508624989d30512d927ca Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Apr 2015 22:06:07 -0000 --047d7b4508624989d30512d927ca Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 4:23 PM, Ca By wrote: > > The fundamental issue is that you have no control over these on the > internet, https://sites.google.com/site/tmoipv6/ipv4literals > That list is badly out of date. (For grins, I looked at some entries on the list. The first one I looked at was at nodejs.org which has an IPv4 literal in its pre-formatted example code on the first page. Which I would note is example code that WOULD NOT BREAK in the absence of a CLAT. You'd have to remove the IPv4 stack completely from the host to break it. The second one I looked at was the one at the top of the list. There is one IPv4 literal in the page. It's assigned to an unused Javascript variable. The third one I looked at was the second one on the list, which appears to have moved entirely since this list was created. Please update the list.) But put that aside for now. There aren't many people in this discussion who DO have control over the entries in that list, but Internet service operators certainly have more influence over them than anyone outside of the actual site owners. Tremble at the risk entailed in using your influence if you must, but don't complain that you have no influence at all. You can choose to get them to stop using IPv4 literals by taking away the free lunch. Or you can choose to let them run wild without consequence. Just start moving select populations of CLAT-less users to IPv6-only+NAT64 networks. They'll figure it out pretty quickly. > You, and i, also have no control over what is implemented in signalling > channels. Your sockets my be AF agnostic, but that does not stop the data > structures for peer to peer apps being ipv4 addesses like Bittorent or > Skype use. [...] In fact, Skype works on iOS today on IPv6-only.... why? > Because they built a CLAT into the App. > Ah yes, those pesky IPv4-only P2P applications. Especially the ones with DHT keys containing IPv4 addresses. Which can't be easily adapted to handle IPv6 address too. A scourge on the Internet those apps are. Exactly how many are we talking about? Besides Skype and BitTorrent, I mean. Oh wait. They're already IPv6-capable. So, who *are* we talking about today? > It is a horrible idea of ask all the app vendors to invent their of unique > CLAT. Because they have already reacted to the threat of IPv6-only... and > this is what they do. > Well, we aren't asking *all* the app vendors to do that, are we? Just the ones that are so amazingly clever they can't do the simple straightforward obvious thing, which is to change their protocols to not use IPv4 literal addresses. I simply don't see the downside of telling whatever remaining IPv4-only P2P app vendors are out there that they have to implement their own UNSAF mechanism over IPv6 rather than rely on the system to do it for them. Who knows, for many of them, it might not be that hard to just upgrade their protocols to support the dual-stack IPv4/IPv6 public Internet. That it was hard for Skype, but not very hard at all for FaceTime, seems like a relevant point to keep in mind. -- james woodyatt Nest Labs, Communications Engineering --047d7b4508624989d30512d927ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 4:23 PM, Ca By <cb.list6@gmail.com> wrot= e:

T= he fundamental issue is that you have no control over these on the internet= , https://sites.google.com/site/tmoipv6/ipv4literals
<= /div>

That list is badly out of date.=



=C2=A0


--
james woodyatt= <jhw@nestlabs.com= >
Nest Labs, Communications Engineering
--047d7b4508624989d30512d927ca-- From nobody Fri Apr 3 19:29:40 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 E25BE1A88C2 for ; Fri, 3 Apr 2015 19:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_INVITATION=-2, 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 0QCkTUEbDSOW for ; Fri, 3 Apr 2015 19:29:37 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 95F9F1A88BF for ; Fri, 3 Apr 2015 19:29:37 -0700 (PDT) Received: by igblo3 with SMTP id lo3so18446974igb.0 for ; Fri, 03 Apr 2015 19:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q5NMopBYl/QRhORWGCJql5Hx8EuCi/gwpTUX5q7bOx4=; b=ltq9rf5SuRKqNU9ts4KXffMqZuTySXkaZT7gyrYuldqnuJowE01YuV+zJ1P7CoHBPl FGH5wkgYs/bLpEmiv+jD/D1AlQjn9UhZI7DghFVw7HlbLx8JZ9xznzuPZ3WxSasrc+49 UU/k9EbnYPbIEu6Z3U02InY/gO4LbrjUzLf1XQJTk4B6+z69dQXOuVyRQw0sL/PnjdL+ KIRNhamM+gOFBc/CnkhoLqszay46n93+WKsl4ZBYYSyv9pHAhlQdkznXIMY3NXS9Yomi POTG4KgMCg46T4y3Olu4fChXCl+s5YlJ7WtRLlAwQRzq4Zl3x4FBzb9gt8HggHXZ9sd3 talA== 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=q5NMopBYl/QRhORWGCJql5Hx8EuCi/gwpTUX5q7bOx4=; b=e0C289g9YIgQuHL47K5vkE67wsMokQvMA7iESvsGIEA2AxJzvMN7Gyq6yRGAot3Q/I 0alP/fMn8MtDLee5PUsIOyL6BmnWDZsdhQtvQzHse5AmMukbtRCrpQ5SvZ8Iyl2OkP4w xpnRkqhu3FbfaCncg7ptnXvyCmWGm7Db0l7zZP1JxUBsGNqDNU1LRhkoBM+Jcm/FMynb crRREwpznIf8kNCCQjKKeisawW0M1DMCQpi2VtkXOKtqwRxE5K6sNe1I45u2WmpjdoTR 1nkPDMgdT/6GhC9EtpMHmwwHchtm3SRW1suEjMP1vBsnzuS6w0xxmmtdkIrXW9wN8VFY ImuA== X-Gm-Message-State: ALoCoQkCIQWn7Os8q2TUNNvKfmIWlzcYu+APjQeXwp+nfy5/eN3ysLxc00ZF0l5hYpeROhC4QEJz X-Received: by 10.107.46.155 with SMTP id u27mr7573699iou.87.1428114576937; Fri, 03 Apr 2015 19:29:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Fri, 3 Apr 2015 19:29:16 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> From: Lorenzo Colitti Date: Sat, 4 Apr 2015 11:29:16 +0900 Message-ID: To: James Woodyatt Content-Type: multipart/alternative; boundary=001a113ac5b60ec2810512dcd683 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Apr 2015 02:29:39 -0000 --001a113ac5b60ec2810512dcd683 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 4, 2015 at 6:15 AM, James Woodyatt wrote: > On Fri, Apr 3, 2015 at 3:57 PM, Lorenzo Colitti > wrote: > >> what do you purpose as a better alternative? >> > I propose that IETF decline the invitation to publish a BCP to the effect > that host OS implementations should include a CLAT function. > Ok, so let me see if we can determine the extent of the disagreement. Suppose that instead of a BCP that says host OS implementations should include a CLAT function, we instead had a BCP that says general-purpose host implementations should *either* include a CLAT function, *or* ensure that all applications are capable of running on an IPv6-only network. Would you oppose that? If so - then how do you see us getting to IPv6-only? Do you see application developers moving to support IPv6 by themselves, including on legacy apps that haven't been updated for years, or that can't be updated because they were sold on CDs? Or do you see network operators removing IPv4 regardless of whether that breaks their users' applications? --001a113ac5b60ec2810512dcd683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 4, 2015 at 6:15 AM, James Woodyatt <jhw@nestlabs.com>= wrote:
On Fri, Apr 3, 2015 = at 3:57 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
=

what do you purpose as a better alter= native?=C2=A0

I propose that IETF de= cline the invitation to publish a BCP to the effect that host OS implementa= tions should include a CLAT function.
<= div>
Ok, so let me see if we can determine the extent of the = disagreement.

Suppose that instead of a BCP that s= ays host OS implementations should include a CLAT function, we instead had = a BCP that says general-purpose host implementations should *either* includ= e a CLAT function, *or* ensure that all applications are capable of running= on an IPv6-only network. Would you oppose that?

I= f so - then how do you see us getting to IPv6-only? Do you see application = developers moving to support IPv6 by themselves, including on legacy apps t= hat haven't been updated for years, or that can't be updated becaus= e they were sold on CDs? Or do you see network operators removing IPv4 rega= rdless of whether that breaks their users' applications?
--001a113ac5b60ec2810512dcd683-- From nobody Sat Apr 4 06:02: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 41EDE1B2AFE for ; Sat, 4 Apr 2015 06:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 INUPubqR_9oD for ; Sat, 4 Apr 2015 06:02:20 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 B0EA31A90A0 for ; Sat, 4 Apr 2015 06:02:19 -0700 (PDT) Received: by wiaa2 with SMTP id a2so164395680wia.0 for ; Sat, 04 Apr 2015 06:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sv9LfKWTc8DiULurkLymjV/7D94ezPJow+UTdJOe+XU=; b=hEDhB8UBb5FDuimNomS+DM2hMmPqN4PQHK8FUVkhnsN8olm2UcDa/zzuT25G+jqIff DLIH0Rjj2QCwzKyKRaPfhnYSWUxGj/lYfupbZMR4SpRcb2fBhMowmXllLu3SlZei/3PF F5H2TcgTsglmCSFFLNEend7PCSMWu88Ua87lxjbLxitTHzlfhyxwDcn80HUdfrFqiOBD 2alcpkQx7M+PZglyqkzrCA5OErCngw8KveO1Dca6GpPP0rIb/zHYNMrC3IznQ6DwK3Vk hZX+Em58lZ5i6aqrr4E22Cz51iDNvgsC7RxkzOZkfWqNY2RUeiMdz8gD9Vic+cAtvHq5 rPfg== MIME-Version: 1.0 X-Received: by 10.194.77.230 with SMTP id v6mr14089739wjw.25.1428152538284; Sat, 04 Apr 2015 06:02:18 -0700 (PDT) Received: by 10.194.93.164 with HTTP; Sat, 4 Apr 2015 06:02:18 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Sat, 4 Apr 2015 06:02:18 -0700 Message-ID: From: Ca By To: James Woodyatt Content-Type: multipart/alternative; boundary=047d7bfd028cbaecf80512e5ac04 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Apr 2015 13:02:22 -0000 --047d7bfd028cbaecf80512e5ac04 Content-Type: text/plain; charset=UTF-8 On Friday, April 3, 2015, James Woodyatt wrote: > On Fri, Apr 3, 2015 at 4:23 PM, Ca By > wrote: > >> >> The fundamental issue is that you have no control over these on the >> internet, ipv4literals | tmoipv6 >> >> > > That list is badly out of date. > > It is only a few weeks old. > (For grins, I looked at some entries on the list. The first one I looked > at was at nodejs.org which has an IPv4 literal in its pre-formatted > example code on the first page. Which I would note is example code that > WOULD NOT BREAK in the absence of a CLAT. You'd have to remove the IPv4 > stack completely from the host to break it. The second one I looked at was > the one at the top of the list. There is one IPv4 literal in the page. It's > assigned to an unused Javascript variable. The third one I looked at was > the second one on the list, which appears to have moved entirely since this > list was created. Please update the list.) > > But put that aside for now. There aren't many people in this discussion > who DO have control over the entries in that list, but Internet service > operators certainly have more influence over them than anyone outside of > the actual site owners. Tremble at the risk entailed in using your > influence if you must, but don't complain that you have no influence at > all. You can choose to get them to stop using IPv4 literals by taking away > the free lunch. Or you can choose to let them run wild without consequence. > Just start moving select populations of CLAT-less users to IPv6-only+NAT64 > networks. They'll figure it out pretty quickly. > > This is 0% executive leaders from the customer service, network operations, marketing, or regulatory affairs would approve such a move. Seriously, the only viable path for that is if the government required it. > You, and i, also have no control over what is implemented in signalling >> channels. Your sockets my be AF agnostic, but that does not stop the data >> structures for peer to peer apps being ipv4 addesses like Bittorent or >> Skype use. [...] In fact, Skype works on iOS today on IPv6-only.... why? >> Because they built a CLAT into the App. >> > > Ah yes, those pesky IPv4-only P2P applications. Especially the ones with > DHT keys containing IPv4 addresses. Which can't be easily adapted to handle > IPv6 address too. A scourge on the Internet those apps are. Exactly how > many are we talking about? Besides Skype and BitTorrent, I mean. Oh wait. > They're already IPv6-capable. So, who *are* we talking about today? > > It is a horrible idea of ask all the app vendors to invent their of unique >> CLAT. Because they have already reacted to the threat of IPv6-only... and >> this is what they do. >> > > Well, we aren't asking *all* the app vendors to do that, are we? Just the > ones that are so amazingly clever they can't do the simple straightforward > obvious thing, which is to change their protocols to not use IPv4 literal > addresses. > > I simply don't see the downside of telling whatever remaining IPv4-only > P2P app vendors are out there that they have to implement their own UNSAF > mechanism over IPv6 rather than rely on the system to do it for them. Who > knows, for many of them, it might not be that hard to just upgrade their > protocols to support the dual-stack IPv4/IPv6 public Internet. That it was > hard for Skype, but not very hard at all for FaceTime, seems like a > relevant point to keep in mind. > > > Hard or not, FaceTime requires IPv4 the last time I checked. -- > james woodyatt > > Nest Labs, Communications Engineering > --047d7bfd028cbaecf80512e5ac04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Friday, April 3, 2015, James Woodyatt <jhw@nestlabs.com> wrote:
On Fri, Apr 3, 2015 at 4:23 PM, Ca By <cb.list6@gmail.com> wrote:
=

The fundamental issue is that you have no c= ontrol over these on the internet, ipv4literals | tmoipv6

That list is badly out of = date.


It is only a few weeks old.=C2=A0
=C2=A0
(For grins, I looked at some entries on the list. The first = one I looked at was at node= js.org which has an IPv4 literal in its pre-formatted example code on t= he first page. Which I would note is example code that WOULD NOT BREAK in t= he absence of a CLAT. You'd have to remove the IPv4 stack completely fr= om the host to break it. The second one I looked at was the one at the top = of the list. There is one IPv4 literal in the page. It's assigned to an= unused Javascript variable. The third one I looked at was the second one o= n the list, which appears to have moved entirely since this list was create= d. Please update the list.)

But put that aside for= now. There aren't many people in this discussion who DO have control o= ver the entries in that list, but Internet service operators certainly have= more influence over them than anyone outside of the actual site owners. Tr= emble at the risk entailed in using your influence if you must, but don'= ;t complain that you have no influence at all. You can choose to get them t= o stop using IPv4 literals by taking away the free lunch. Or you can choose= to let them run wild without consequence. Just start moving select populat= ions of CLAT-less users to IPv6-only+NAT64 networks. They'll figure it = out pretty quickly.
=C2=A0

This is 0% executive=C2=A0leaders from the customer servi= ce, network operations, marketing, or regulatory affairs would approve such= a move. Seriously, the only viable path for that is if the government requ= ired it.=C2=A0
=C2=A0
You, and i, also have no control over what is implemented in signall= ing channels. Your sockets my be AF agnostic, but that does not stop the da= ta structures for peer to peer apps being ipv4 addesses like Bittorent or S= kype use. [...] In fact, Skype works on iOS today on IPv6-only.... why?=C2= =A0 Because they built a CLAT into the App.

Ah yes, those pesky IPv4-only P2P applications. Es= pecially the ones with DHT keys containing IPv4 addresses. Which can't = be easily adapted to handle IPv6 address too. A scourge on the Internet tho= se apps are. Exactly how many are we talking about? Besides Skype and BitTo= rrent, I mean. Oh wait. They're already IPv6-capable. So, who *are* we = talking about today?
=C2=A0
<= div>

=
It is a horrible idea of ask all the app vendors to invent their of unique= CLAT.=C2=A0 Because they have already reacted to the threat of IPv6-only..= . and this is what they do.

Well, we aren't asking *all* the app vendors to do that, = are we? Just the ones that are so amazingly clever they can't do the si= mple straightforward obvious thing, which is to change their protocols to n= ot use IPv4 literal addresses.

I simply don't = see the downside of telling whatever remaining IPv4-only P2P app vendors ar= e out there that they have to implement their own UNSAF mechanism over IPv6= rather than rely on the system to do it for them. Who knows, for many of t= hem, it might not be that hard to just upgrade their protocols to support t= he dual-stack IPv4/IPv6 public Internet. That it was hard for Skype, but no= t very hard at all for FaceTime, seems like a relevant point to keep in min= d.


=

Hard=C2=A0=C2=A0or not, FaceTime requires IPv4 the last= time I checked. =C2=A0

=
--
ja= mes woodyatt <jhw@nestlabs.com>
Nest Labs= , Communications Engineering
--047d7bfd028cbaecf80512e5ac04-- From nobody Sat Apr 4 06:46: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 1EE3F1B2B2F for ; Sat, 4 Apr 2015 06:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 SRhEuchFvVzo for ; Sat, 4 Apr 2015 06:46:08 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3991B2B29 for ; Sat, 4 Apr 2015 06:46:07 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,522,1422939600"; d="scan'208,217";a="849505970" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Apr 2015 09:32:09 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Sat, 4 Apr 2015 09:46:07 -0400 From: "Howard, Lee" To: Ca By , "George, Wes" Date: Sat, 4 Apr 2015 09:46:05 -0400 Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AdBu3bL76FEtC25/SS2i9EfUHrLUxQ== Message-ID: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D14562F993AC4LeeHowardtwcablecom_" MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Apr 2015 13:46:10 -0000 --_000_D14562F993AC4LeeHowardtwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Cameron Byrne > Date: Friday, April 3, 2015 at 10:35 AM To: Wesley George > Cc: 'IPv6 Operations' > Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions --= NAT64/DNS64 remains insufficient Talk is cheap, so are guidelines. If it works, it ships. We have been wav= ing the guidelines that people should turn on ipv6 for years, they don't wo= rk. Anyone who has turned on ipv6 has done it because they saw a straight-= line to risk and cost mitigation. . . . Meaning, nobody has even started. Conclusion: IPv4 sockets need to be supported on hosts that operate in IPv= 6-only networks. Would an IETF BCP help convince your remaining vendor to do what you want? Lee CB ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_D14562F993AC4LeeHowardtwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


=
From: Cameron Byrne <cb.list6@gmail.com>
Date: Friday, April 3, 2015 at 10:35 AM
To: Wesley George <Wesley.George@twcable.com>
Cc: 'IPv6 Operations' <v6ops@ietf.org>
Subject: Re: [v6ops] The need for local-ipv4 socket transition s= olutions -- NAT64/DNS64 remains insufficient
=

Talk is cheap, so are guidel= ines.  If it works, it ships.  We have been waving the guidelines= that people should turn on ipv6 for years, they don't work.  Anyone w= ho has turned on ipv6 has done it because they saw a straight-line to risk = and cost mitigation.
. . .
Meaning, nobody has even sta= rted.

Conclusion:  IPv4 sockets need to be su= pported on hosts that operate in IPv6-only networks.

Would an IETF BCP help convince yo= ur remaining vendor to do what you want?

Lee
=


CB 
This E-mail and any of its attachments may c= ontain Time Warner Cable proprietary information, which is privileged, conf= idential, or subject to copyright belonging to Time Warner Cable. This E-ma= il is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.

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


 --_000_D14562F993AC4LeeHowardtwcablecom_-- From nobody Sat Apr 4 06:59:41 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 A9A311B2B4C for ; Sat, 4 Apr 2015 06:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 wBg6Hn6w1S6W for ; Sat, 4 Apr 2015 06:59:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370151B2B49 for ; Sat, 4 Apr 2015 06:59:37 -0700 (PDT) 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.125.19; Sat, 4 Apr 2015 13:59:17 +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.0118.029; Sat, 4 Apr 2015 13:59:17 +0000 From: "Metzler, Dan J" To: Ca By , "George, Wes" Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient Thread-Index: AQHQYouA3ye9AcRTck+xU68IbGwQo50k3BQAgAB1XgCAADeeAIADZz+AgAFS54CAAVsLAIAAFWiAgAAAioCAAA8DgIAAC2wAgABuQoCAAa/cAIAAFKSAgAD9fgCAAAeaAIAAW2CAgAwMloCAAANjAIABh97w Date: Sat, 4 Apr 2015 13:59:16 +0000 Message-ID: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> 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: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(2900100001)(106116001)(5890100001)(54356999)(2950100001)(102836002)(89122001)(76576001)(93886004)(2656002)(50986999)(16236675004)(76176999)(74316001)(19617315012)(33656002)(77156002)(62966003)(46102003)(15975445007)(19625215002)(77096005)(88552001)(92566002)(75432002)(99286002)(86362001)(66066001)(19580405001)(19580395003)(19609705001)(122556002)(40100003)(87936001)(19300405004)(90282001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO2PR04MB587; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB587; x-forefront-prvs: 0536638EAC Content-Type: multipart/alternative; boundary="_000_CO2PR04MB585AC89EBEEAAAF62697E15FEF00CO2PR04MB585namprd_" MIME-Version: 1.0 X-OriginatorOrg: uiowa.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2015 13:59:16.9231 (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: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Apr 2015 13:59:40 -0000 --_000_CO2PR04MB585AC89EBEEAAAF62697E15FEF00CO2PR04MB585namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIENhIEJ5DQpTZW50OiBGcmlkYXksIEFwcmlsIDMsIDIwMTUgOTozNiBBTQ0KVG86IEdlb3Jn ZSwgV2VzDQpDYzogSVB2NiBPcHMgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNdIFRoZSBuZWVkIGZv ciBsb2NhbC1pcHY0IHNvY2tldCB0cmFuc2l0aW9uIHNvbHV0aW9ucyAtLSBOQVQ2NC9ETlM2NCBy ZW1haW5zIGluc3VmZmljaWVudA0KDQoNCg0KT24gRnJpLCBBcHIgMywgMjAxNSBhdCA3OjIzIEFN LCBHZW9yZ2UsIFdlcyA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTxtYWlsdG86d2VzbGV5Lmdl b3JnZUB0d2NhYmxlLmNvbT4+IHdyb3RlOg0KDQpGcm9tOiBKYW1lcyBXb29keWF0dCA8amh3QG5l c3RsYWJzLmNvbTxtYWlsdG86amh3QG5lc3RsYWJzLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgTWFy Y2ggMjYsIDIwMTUgYXQgNjoyMyBQTQ0KVG86IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZzxt YWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gVGhlIG5lZWQgZm9y IGxvY2FsLWlwdjQgc29ja2V0IHRyYW5zaXRpb24gc29sdXRpb25zIC0tIE5BVDY0L0ROUzY0IHJl bWFpbnMgaW5zdWZmaWNpZW50DQoNClRoZXJlIGlzIG9ubHkgb25lIHRoaW5nIGFwcGx5aW5nIGFu eSBwcmVzc3VyZSBvZiBhbnkga2luZCB0byBkZXZlbG9wZXJzIGN1cnJlbnRseSB1c2luZyBJUHY0 IGxpdGVyYWxzIGluIHRoZWlyIGFwcGxpY2F0aW9uIHByb3RvY29sczogdGhhdCB0aGVpciBhcHBs aWNhdGlvbnMgRkFJTCBvbiBBcHBsZSBvcGVyYXRpbmcgc3lzdGVtcyB3aGVuIHRob3NlIGRldmlj ZXMgY29ubmVjdCB0byBJUHY2LW9ubHkrTkFUNjQgbmV0d29ya3MuDQoNCklmIEFwcGxlIGNhdmVz IG9uIHRoaXMsIGFzIGV2ZXJ5IG90aGVyIG1ham9yIHZlbmRvciBvZiBtb2JpbGUgZGV2aWNlIG9w ZXJhdGluZyBzeXN0ZW1zIGhhcyBhbHJlYWR5IGNhdmVkLCB0aGVuIGRldmVsb3BlcnMgd2lsbCBj b250aW51ZSB0byByZWx5IG9uIHRoZSB2aWFiaWxpdHkgb2YgSVB2NCBsaXRlcmFscyBhcyBhIHBy b3RvY29sIGVsZW1lbnQgZm9yIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUuIFRob3NlIGFwcGxpY2F0 aW9ucyB0aGF0IGRvIHNvIHdpbGwgY29udGludWUgc2hpcHBpbmcgd2l0aCBhIHJlbGlhbmNlIG9u IDQ2NFhMQVQgZm9yIHllYXJzIHRvIGNvbWUsIGFuZCB0aGV5IHdpbGwgY29udGludWUgdG8gYmUg dXNlZCBpbiBjcml0aWNhbCBwcm9jZXNzZXMgZm9yIHllYXJzIGFmdGVyIHRoYXQgd2hlbiB0aGV5 IGFyZSBubyBsb25nZXIgdW5kZXIgbWFpbnRlbmFuY2UuIFRoZXJlIGFyZSBwZW9wbGUgdG9kYXkg c2NydWJiaW5nIHdlYiBwYWdlcyBhbmQgYXBwbGljYXRpb24gcHJvdG9jb2xzIG9mIHRoZWlyIElQ djQgbGl0ZXJhbHMsIGFuZCB0aGV5IGFyZSBtYWlubHkgbW90aXZhdGVkIHRvIGNvbnRpbnVlIGRv aW5nIHRoaXMgYnkgdGhlIG5lZWQgdG8gZGVhbCB3aXRoIHRoZSBmYWN0IHRoYXQgNDY0WExBVCBp c24ndCB1bml2ZXJzYWxseSBkZXBsb3llZCBvbiBhbGwgdGhlIG1ham9yIG1vYmlsZSBwbGF0Zm9y bXMgeWV0LiBBcHBsZSBpcyB0aGUgbGFzdCBub3Rld29ydGh5IGhvbGRvdXQuDQoNClB1Ymxpc2hp bmcgYSBCQ1AgdGhhdCBlbnRhaWxzIHRlbGxpbmcgZGV2ZWxvcGVycyB0aGF0IElQdjQgbGl0ZXJh bHMgYXJlIGxlZ2l0aW1hdGUgZm9yIHVzZSBhcyBhcHBsaWNhdGlvbiBwcm90b2NvbCBlbGVtZW50 cyBpcyB1bm5lY2Vzc2FyeSBhbmQgY291bnRlci1wcm9kdWN0aXZlIHRvIHRoZSBpbnRlcmVzdHMg b2YgdGhlIElFVEYgaW4gcHJvbW90aW5nIGFkb3B0aW9uIG9mIElQdjYuIEluc3RlYWQgaXQgd291 bGQgY29tbXVuaWNhdGUgdG8gZGV2ZWxvcGVycyB0aGF0IElFVEYgaXMgY2FwaXR1bGF0aW5nIG9u IElQdjYsIHRoYXQgaXQgZG9lc24ndCByZWFsbHkgYmVsaWV2ZSBpbiBpdCBhbnltb3JlLCBhbmQg YXBwbGljYXRpb24gZGV2ZWxvcGVycyBzaG91bGQgZmVlbCBzYWZlIGlnbm9yaW5nIGl0IGZvciB0 aGUgZm9yZXNlZWFibGUgZnV0dXJlLg0KDQpXR10gaW50ZXJlc3RpbmdseSwgbW9zdCBvZiB0aGUg YWJvdmUgc3RhdGVtZW50IHN0aWxsIHdvcmtzIGlmIHlvdSBkbyAlcy9JUHY0IExpdGVyYWxzL0Fk b2JlIEZsYXNoL2csIHRob3VnaCBBbmRyb2lkIGhhcyBob3BwZWQgb24gdGhhdCBwYXJ0aWN1bGFy IGJhbmR3YWdvbiB0b28uDQoNCllvdSdyZSBzaW1wbHkgYWR2b2NhdGluZyBmb3IgcHVzaGluZyB0 aGlzIHByb2JsZW0gYW5kIHRoZXJlZm9yZSBhbGwgZWZmb3J0cyB0byBtb3RpdmF0ZSBwZW9wbGUg dG8gc3RvcCB1c2luZyBJUHY0IGxpdGVyYWxzIGJhY2sgb250byB0aGUgY2FycmllcnMsIGJlY2F1 c2UgeW91IGtub3cgZnVsbCB3ZWxsIHRoYXQgdW5saWtlIEFwcGxlL0FuZHJvaWQgZGlkIHdpdGgg Zmxhc2gsIHRoZSBjYXJyaWVycyBhcmVuJ3QgZ29pbmcgdG8gaW50ZW50aW9uYWxseSBicmVhayB0 aGVpciB1c2VyJ3MgZXhwZXJpZW5jZSB0byBwcm92ZSBhIHBvaW50IHVudGlsIHRoZSByaXNrIGlz IHZhbmlzaGluZ2x5IHNtYWxsLCBzbyB0aGV5IHNpbXBseSB3b24ndCBkZXBsb3kgSVB2Ni1vbmx5 K05BVDY0LCBiZWNhdXNlIGRvaW5nIHNvIHdpbGwgbWFrZSB0aGUgcGhvbmUgcmluZy4NCg0KUGVy aGFwcyBpZiBBcHBsZSBiZWxpZXZlcyB0aGF0IHRoZSBkZXZlbG9wZXJzIG5lZWQgbW9yZSBtb3Rp dmF0aW9uLCB0aGVyZSBzaG91bGQgYmUgZXhwbGljaXQgZ3VpZGFuY2UgaW4gdGhlIEFwcCBzdG9y ZSBndWlkZWxpbmVzIHRoYXQgYXBwcyB1c2luZyBJUHY0IGxpdGVyYWxzLCBldmVuIG9uIHRoZSBz ZXJ2ZXIgc2lkZSwgYXJlIHVuYWNjZXB0YWJsZT8gKHllcywgSSByZWFsaXplIHlvdSBubyBsb25n ZXIgd29yayB0aGVyZSBKYW1lcykuIExvcmVuem8sIGRvZXMgQW5kcm9pZCBoYXZlIHN1Y2ggZ3Vp ZGFuY2U/IEV2ZW4gd2l0aCA0NjR4bGF0IHN1cHBvcnQsIGlmIHRoYXQncyB0aGVyZSwgdGhlbiB3 ZSdyZSBjb250aW51aW5nIHRoZSBwcmVzc3VyZSBvbiBmaXhpbmcgaXQgd2hpbGUgYWNrbm93bGVk Z2luZyB0aGUgb3BlcmF0aW9uYWwgcmVhbGl0eSBvZiBtYWtpbmcgYSBkZWNlbnQgdXNlciBleHBl cmllbmNlIHVudGlsIGl0J3MgZml4ZWQgcHJvcGVybHkuDQoNCldlcyBHZW9yZ2UNCg0KDQpUYWxr IGlzIGNoZWFwLCBzbyBhcmUgZ3VpZGVsaW5lcy4gIElmIGl0IHdvcmtzLCBpdCBzaGlwcy4gIFdl IGhhdmUgYmVlbiB3YXZpbmcgdGhlIGd1aWRlbGluZXMgdGhhdCBwZW9wbGUgc2hvdWxkIHR1cm4g b24gaXB2NiBmb3IgeWVhcnMsIHRoZXkgZG9uJ3Qgd29yay4gIEFueW9uZSB3aG8gaGFzIHR1cm5l ZCBvbiBpcHY2IGhhcyBkb25lIGl0IGJlY2F1c2UgdGhleSBzYXcgYSBzdHJhaWdodC1saW5lIHRv IHJpc2sgYW5kIGNvc3QgbWl0aWdhdGlvbi4NCg0KQW5kIGFnYWluLCB0aGVyZSBhcmUgaXB2NCBs aXRlcmFscyBvbiBtYWpvciB0b3AgMTAwLCB0b3AgMTAwMCwgdG9wIDFNIHdlYnNpdGVzLi4uLiBB cHAgc3RvcmUgZ3VpZGVsaW5lcyBhbmQgZXZlbiBoYXJkICByZXF1aXJlbWVudHMgd29uJ3QgZml4 IHRoZSBmcmVlIGFuZCBvcGVuIHdlYi4NCg0KUmVsZWFzaW5nIGd1aWRlbGluZXMgd2FzIHNvb29v IDIwMDUuIEFuZCwgc29vb28gaW5lZmZlY3RpdmUgYXQgbWFraW5nIHJlYWwgaXB2Ni1vbmx5IGlw djQtc29ja2V0LWZyZWUgZGVwbG95bWVudCBwb3NzaWJsZS4gIEluIGZhY3QsIHdlIGFyZSBwcmV0 dHkgc3VyZSBubyBtYWpvciAob3IgbWlub3IpIG5ldHdvcmsgb3Igb3BlcmF0aW5nIGVudmlyb25t ZW50IG9mIGFueSBzb3J0IGlzIGlwdjQtZnJlZS4NCg0KTWVhbmluZywgbm9ib2R5IGhhcyBldmVu IHN0YXJ0ZWQuDQoNCkNvbmNsdXNpb246ICBJUHY0IHNvY2tldHMgbmVlZCB0byBiZSBzdXBwb3J0 ZWQgb24gaG9zdHMgdGhhdCBvcGVyYXRlIGluIElQdjYtb25seSBuZXR3b3Jrcy4NCg0KQ0INCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBp bmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0 IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWls IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBp biByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1t YWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55 IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= --_000_CO2PR04MB585AC89EBEEAAAF62697E15FEF00CO2PR04MB585namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DYSBCeTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFw cmlsIDMsIDIwMTUgOTozNiBBTTxicj4NCjxiPlRvOjwvYj4gR2VvcmdlLCBXZXM8YnI+DQo8Yj5D Yzo8L2I+IElQdjYgT3BzIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIFRoZSBu ZWVkIGZvciBsb2NhbC1pcHY0IHNvY2tldCB0cmFuc2l0aW9uIHNvbHV0aW9ucyAtLSBOQVQ2NC9E TlM2NCByZW1haW5zIGluc3VmZmljaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGcmksIEFwciAzLCAyMDE1IGF0IDc6MjMgQU0sIEdlb3JnZSwgV2VzICZs dDs8YSBocmVmPSJtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SmFtZXMgV29v ZHlhdHQgJmx0OzxhIGhyZWY9Im1haWx0bzpqaHdAbmVzdGxhYnMuY29tIiB0YXJnZXQ9Il9ibGFu ayI+amh3QG5lc3RsYWJzLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBN YXJjaCAyNiwgMjAxNSBhdCA2OjIzIFBNPGJyPg0KPGI+VG86IDwvYj5JUHY2IE9wcyBXRyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3Y2b3BzXSBUaGUgbmVlZCBm b3IgbG9jYWwtaXB2NCBzb2NrZXQgdHJhbnNpdGlvbiBzb2x1dGlvbnMgLS0gTkFUNjQvRE5TNjQg cmVtYWlucyBpbnN1ZmZpY2llbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZXJlIGlzIG9ubHkgb25l IHRoaW5nIGFwcGx5aW5nIGFueSBwcmVzc3VyZSBvZiBhbnkga2luZCB0byBkZXZlbG9wZXJzIGN1 cnJlbnRseSB1c2luZyBJUHY0IGxpdGVyYWxzIGluIHRoZWlyIGFwcGxpY2F0aW9uIHByb3RvY29s czogdGhhdCB0aGVpciBhcHBsaWNhdGlvbnMgRkFJTA0KIG9uIEFwcGxlIG9wZXJhdGluZyBzeXN0 ZW1zIHdoZW4gdGhvc2UgZGV2aWNlcyBjb25uZWN0IHRvIElQdjYtb25seSYjNDM7TkFUNjQgbmV0 d29ya3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPklmIEFwcGxlIGNhdmVzIG9uIHRoaXMsIGFzIGV2ZXJ5IG90aGVy IG1ham9yIHZlbmRvciBvZiBtb2JpbGUgZGV2aWNlIG9wZXJhdGluZyBzeXN0ZW1zIGhhcyBhbHJl YWR5IGNhdmVkLCB0aGVuIGRldmVsb3BlcnMgd2lsbCBjb250aW51ZSB0byByZWx5IG9uIHRoZSB2 aWFiaWxpdHkNCiBvZiBJUHY0IGxpdGVyYWxzIGFzIGEgcHJvdG9jb2wgZWxlbWVudCBmb3IgdGhl IGZvcmVzZWVhYmxlIGZ1dHVyZS4gVGhvc2UgYXBwbGljYXRpb25zIHRoYXQgZG8gc28gd2lsbCBj b250aW51ZSBzaGlwcGluZyB3aXRoIGEgcmVsaWFuY2Ugb24gNDY0WExBVCBmb3IgeWVhcnMgdG8g Y29tZSwgYW5kIHRoZXkgd2lsbCBjb250aW51ZSB0byBiZSB1c2VkIGluIGNyaXRpY2FsIHByb2Nl c3NlcyBmb3IgeWVhcnMgYWZ0ZXIgdGhhdCB3aGVuIHRoZXkgYXJlDQogbm8gbG9uZ2VyIHVuZGVy IG1haW50ZW5hbmNlLiBUaGVyZSBhcmUgcGVvcGxlIHRvZGF5IHNjcnViYmluZyB3ZWIgcGFnZXMg YW5kIGFwcGxpY2F0aW9uIHByb3RvY29scyBvZiB0aGVpciBJUHY0IGxpdGVyYWxzLCBhbmQgdGhl eSBhcmUgbWFpbmx5IG1vdGl2YXRlZCB0byBjb250aW51ZSBkb2luZyB0aGlzIGJ5IHRoZSBuZWVk IHRvIGRlYWwgd2l0aCB0aGUgZmFjdCB0aGF0IDQ2NFhMQVQgaXNuJ3QgdW5pdmVyc2FsbHkgZGVw bG95ZWQgb24gYWxsDQogdGhlIG1ham9yIG1vYmlsZSBwbGF0Zm9ybXMgeWV0LiBBcHBsZSBpcyB0 aGUgbGFzdCBub3Rld29ydGh5IGhvbGRvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlB1Ymxpc2hpbmcgYSBCQ1Ag dGhhdCBlbnRhaWxzIHRlbGxpbmcgZGV2ZWxvcGVycyB0aGF0IElQdjQgbGl0ZXJhbHMgYXJlIGxl Z2l0aW1hdGUgZm9yIHVzZSBhcyBhcHBsaWNhdGlvbiBwcm90b2NvbCBlbGVtZW50cyBpcyB1bm5l Y2Vzc2FyeSBhbmQgY291bnRlci1wcm9kdWN0aXZlDQogdG8gdGhlIGludGVyZXN0cyBvZiB0aGUg SUVURiBpbiBwcm9tb3RpbmcgYWRvcHRpb24gb2YgSVB2Ni4gSW5zdGVhZCBpdCB3b3VsZCBjb21t dW5pY2F0ZSB0byBkZXZlbG9wZXJzIHRoYXQgSUVURiBpcyBjYXBpdHVsYXRpbmcgb24gSVB2Niwg dGhhdCBpdCBkb2Vzbid0IHJlYWxseSBiZWxpZXZlIGluIGl0IGFueW1vcmUsIGFuZCBhcHBsaWNh dGlvbiBkZXZlbG9wZXJzIHNob3VsZCBmZWVsIHNhZmUgaWdub3JpbmcgaXQgZm9yIHRoZSBmb3Jl c2VlYWJsZQ0KIGZ1dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxiciBjbGVh cj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldHXSBpbnRlcmVzdGluZ2x5LCBtb3N0 IG9mIHRoZSBhYm92ZSBzdGF0ZW1lbnQgc3RpbGwgd29ya3MgaWYgeW91IGRvICVzL0lQdjQgTGl0 ZXJhbHMvQWRvYmUgRmxhc2gvZywgdGhvdWdoIEFuZHJvaWQgaGFzIGhvcHBlZCBvbiB0aGF0IHBh cnRpY3VsYXIgYmFuZHdhZ29uIHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPllvdSdy ZSBzaW1wbHkgYWR2b2NhdGluZyBmb3IgcHVzaGluZyB0aGlzIHByb2JsZW0gYW5kIHRoZXJlZm9y ZSBhbGwgZWZmb3J0cyB0byBtb3RpdmF0ZSBwZW9wbGUgdG8gc3RvcCB1c2luZyBJUHY0IGxpdGVy YWxzIGJhY2sgb250byB0aGUgY2FycmllcnMsIGJlY2F1c2UgeW91IGtub3cNCiBmdWxsIHdlbGwg dGhhdCB1bmxpa2UgQXBwbGUvQW5kcm9pZCBkaWQgd2l0aCBmbGFzaCwgdGhlIGNhcnJpZXJzIGFy ZW4ndCBnb2luZyB0byBpbnRlbnRpb25hbGx5IGJyZWFrIHRoZWlyIHVzZXIncyBleHBlcmllbmNl IHRvIHByb3ZlIGEgcG9pbnQgdW50aWwgdGhlIHJpc2sgaXMgdmFuaXNoaW5nbHkgc21hbGwsIHNv IHRoZXkgc2ltcGx5IHdvbid0IGRlcGxveSBJUHY2LW9ubHkmIzQzO05BVDY0LCBiZWNhdXNlIGRv aW5nIHNvIHdpbGwgbWFrZSB0aGUgcGhvbmUNCiByaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5QZXJoYXBzIGlm IEFwcGxlIGJlbGlldmVzIHRoYXQgdGhlIGRldmVsb3BlcnMgbmVlZCBtb3JlIG1vdGl2YXRpb24s IHRoZXJlIHNob3VsZCBiZSBleHBsaWNpdCBndWlkYW5jZSBpbiB0aGUgQXBwIHN0b3JlIGd1aWRl bGluZXMgdGhhdCBhcHBzIHVzaW5nIElQdjQgbGl0ZXJhbHMsDQogZXZlbiBvbiB0aGUgc2VydmVy IHNpZGUsIGFyZSB1bmFjY2VwdGFibGU/ICh5ZXMsIEkgcmVhbGl6ZSB5b3Ugbm8gbG9uZ2VyIHdv cmsgdGhlcmUgSmFtZXMpLiBMb3JlbnpvLCBkb2VzIEFuZHJvaWQgaGF2ZSBzdWNoIGd1aWRhbmNl PyBFdmVuIHdpdGggNDY0eGxhdCBzdXBwb3J0LCBpZiB0aGF0J3MgdGhlcmUsIHRoZW4gd2UncmUg Y29udGludWluZyB0aGUgcHJlc3N1cmUgb24gZml4aW5nIGl0IHdoaWxlIGFja25vd2xlZGdpbmcg dGhlIG9wZXJhdGlvbmFsDQogcmVhbGl0eSBvZiBtYWtpbmcgYSBkZWNlbnQgdXNlciBleHBlcmll bmNlIHVudGlsIGl0J3MgZml4ZWQgcHJvcGVybHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4 ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij5XZXMgR2Vvcmdl PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFsayBp cyBjaGVhcCwgc28gYXJlIGd1aWRlbGluZXMuJm5ic3A7IElmIGl0IHdvcmtzLCBpdCBzaGlwcy4m bmJzcDsgV2UgaGF2ZSBiZWVuIHdhdmluZyB0aGUgZ3VpZGVsaW5lcyB0aGF0IHBlb3BsZSBzaG91 bGQgdHVybiBvbiBpcHY2IGZvciB5ZWFycywgdGhleSBkb24ndCB3b3JrLiZuYnNwOyBBbnlvbmUg d2hvIGhhcyB0dXJuZWQgb24gaXB2NiBoYXMgZG9uZSBpdCBiZWNhdXNlIHRoZXkgc2F3IGEgc3Ry YWlnaHQtbGluZSB0byByaXNrDQogYW5kIGNvc3QgbWl0aWdhdGlvbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGFnYWluLCB0aGVyZSBh cmUgaXB2NCBsaXRlcmFscyBvbiBtYWpvciB0b3AgMTAwLCB0b3AgMTAwMCwgdG9wIDFNIHdlYnNp dGVzLi4uLiBBcHAgc3RvcmUgZ3VpZGVsaW5lcyBhbmQgZXZlbiBoYXJkICZuYnNwO3JlcXVpcmVt ZW50cyB3b24ndCBmaXggdGhlIGZyZWUgYW5kIG9wZW4gd2ViLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWxlYXNpbmcgZ3VpZGVsaW5lcyB3 YXMgc29vb28gMjAwNS4gQW5kLCBzb29vbyBpbmVmZmVjdGl2ZSBhdCBtYWtpbmcgcmVhbCBpcHY2 LW9ubHkgaXB2NC1zb2NrZXQtZnJlZSBkZXBsb3ltZW50IHBvc3NpYmxlLiZuYnNwOyBJbiBmYWN0 LCB3ZSBhcmUgcHJldHR5IHN1cmUgbm8gbWFqb3IgKG9yIG1pbm9yKSBuZXR3b3JrIG9yIG9wZXJh dGluZyBlbnZpcm9ubWVudCBvZiBhbnkgc29ydCBpcyBpcHY0LWZyZWUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lYW5pbmcsIG5vYm9keSBo YXMgZXZlbiBzdGFydGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Db25jbHVzaW9uOiAmbmJzcDtJUHY0IHNvY2tldHMgbmVlZCB0byBiZSBz dXBwb3J0ZWQgb24gaG9zdHMgdGhhdCBvcGVyYXRlIGluIElQdjYtb25seSBuZXR3b3Jrcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q0ImbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2IGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxp Z249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Z3JheSI+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQg YmVsb25naW5nIHRvDQogVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gg aXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9m IHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbg0KIGluIHJlbGF0aW9u IHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQgYW55DQogcHJpbnRvdXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CO2PR04MB585AC89EBEEAAAF62697E15FEF00CO2PR04MB585namprd_-- From nobody Sun Apr 5 02:28:37 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 E16611A92F3 for ; Sun, 5 Apr 2015 02:28:36 -0700 (PDT) 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 YNtx9ssXdmNH for ; Sun, 5 Apr 2015 02:28:35 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7761A92F2 for ; Sun, 5 Apr 2015 02:28:34 -0700 (PDT) Received: from [127.0.0.1] (unknown [123.112.109.128]) by centos (Coremail) with SMTP id AQAAf3D7HQa7_iBVuDRCAA--.1417S5; Sun, 05 Apr 2015 17:22:04 +0800 (CST) Message-ID: <55210022.4000808@cernet.edu.cn> Date: Sun, 05 Apr 2015 17:28:02 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian E Carpenter References: <551AF135.3060602@gmail.com> <551B37B9.4090400@gmail.com> In-Reply-To: <551B37B9.4090400@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3D7HQa7_iBVuDRCAA--.1417S5 X-Coremail-Antispam: 1UD129KBjvdXoWrtr48Xw18Wr4xtF4DGr4fGrg_yoWDZrX_uF 95Ka4kAr1jyFs5tr4Utr1a9r9xGan8XF1DA3s8tw4qv34q9wsrG39rC34xWF4rJryUAr45 WF93Z3yrJry7ujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUjEkYjsxI4VW3JwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwA2z4x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwVC2z280aVCY1x0267AKxVWUJVW8Jw AS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2z280 aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxAIw28IcxkI7V AKI48JMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CE b7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0x vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI 42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxh VjvjDU0xZFpf9x07jUb18UUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv4 trajectory X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Apr 2015 09:28:37 -0000 Brian E Carpenter 写é“: > In fact, I agree. So the sequence I'm thinking of for a transit > or DFZ carrier is something like this: > > 1. (now) Run dual stack with ships-in-the-night routing, but > configuration and management is via IPv4. > > 2. (soon) Ditto, but some config & management moves to IPv6. > > 3. Ditto, but all config & management is via IPv6. > Just for the information, this is easy for the backbone. CERNET2 (IPv6-only) is doing this for about 10 years. Of cause, the BOSS is another story. xing > 4. Observe that IPv4 has become secondary. > > 5. Therefore, migrate IPv4 support to run over IPv6. > > This is different (and simpler) than subscriber-facing carriers, > because they will have to navigate all kinds of other issues > like CGN and MAP on the client side. > > I'm not saying this is profound; just that it is a different > trajectory from the ones we mainly discuss. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Apr 5 02:39: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 89CDE1A9300 for ; Sun, 5 Apr 2015 02:39:21 -0700 (PDT) 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 ZLOcKRklxAQj for ; Sun, 5 Apr 2015 02:39:18 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 565851A92FE for ; Sun, 5 Apr 2015 02:39:17 -0700 (PDT) Received: from [127.0.0.1] (unknown [123.112.109.128]) by centos (Coremail) with SMTP id AQAAf3DrtgRJASFVCzpCAA--.1995S5; Sun, 05 Apr 2015 17:32:58 +0800 (CST) Message-ID: <552102B0.6070904@cernet.edu.cn> Date: Sun, 05 Apr 2015 17:38:56 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ca By References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3DrtgRJASFVCzpCAA--.1995S5 X-Coremail-Antispam: 1UD129KBjvJXoW7AF4xtFWfGr1UJF15Wr18AFb_yoW8ur4kpr 13Kw17Cr4UJF17C34kJw1jqr1YvFW8Jry7Gw13Ar1kArZ8Cr1UKr4IqrnYyr97Jry5Jr4j qrWUCry5Jw48ArJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUDGb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Jr0_Gr 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0 cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8Jw ACjcxG0xvEwIxGrwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I0E 7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcV C0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF 04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2js IEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8rcTPUUUUU== X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Apr 2015 09:39:21 -0000 Ca By 写é“: > > Conclusion: IPv4 sockets need to be supported on hosts that operate > in IPv6-only networks. Fully agree, based CERNET2's 10 years IPv6-only backbone experience. We have the following observations. (1) If it is the IPv6-only network and IPv6-only applications (IPv6-only socket), then nobody will use it, except for the demonstration. (2) If it is the IPv6-only network with single IPv4/IPv6 translation and IPv6-only applications (IPv6-only socket), then somebody will use it, but they are not the majority (less than 5%). (3) If it is the IPv6-only network with double IPv4/IPv6 translation and IPv4/IPv6 applications (IPv4/IPv6 sockets), then everybody will use it happily. So I think the transition path should be moving from double translation to single translation and eventually to IPv6-only. Regards, xing > > CB > > ------------------------------------------------------------------------ > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This > E-mail is intended solely for the use of the individual or entity > to which it is addressed. If you are not the intended recipient of > this E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may > be unlawful. If you have received this E-mail in error, please > notify the sender immediately and permanently delete the original > and any copy of this E-mail and any printout. > > _______________________________________________ > 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 Sun Apr 5 02:39: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 6A47D1ABC10 for ; Sun, 5 Apr 2015 02:39:35 -0700 (PDT) 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 vi-Gb3MwHYFL for ; Sun, 5 Apr 2015 02:39:34 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id BDAE91ABB1A for ; Sun, 5 Apr 2015 02:39:33 -0700 (PDT) Received: from [127.0.0.1] (unknown [123.112.109.128]) by centos (Coremail) with SMTP id AQAAf3AL1wRyASFVHjpCAA--.1632S5; Sun, 05 Apr 2015 17:33:39 +0800 (CST) Message-ID: <552102D9.6060603@cernet.edu.cn> Date: Sun, 05 Apr 2015 17:39:37 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ted Lemon References: <1760E8FC-D057-4F6D-A277-B166299A04FA@nominum.com> In-Reply-To: <1760E8FC-D057-4F6D-A277-B166299A04FA@nominum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3AL1wRyASFVHjpCAA--.1632S5 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU5O7k0a2IF6F4UM7kC6x804xWl14x267AK xVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY 6xkF7I0E14v26r1j6r4UM28EF7xvwVC2z280aVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv6x kF7I0E14v26r1j6r4UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02 F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4I kC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AK xVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrx kI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v2 6r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVW8JVW3JwCI42IY6I8E87Iv67AKxVWUJVW8Jw CI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUznmRUUUU U X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Apr 2015 09:39:35 -0000 Ted Lemon 写é“: > > The point being that I think 464XLAT is going to speed the transition, not slow it, and if that sucks for O.S. vendors, well, that's why they call it work... > +1. xing > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Sun Apr 5 11:00: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 7F0531ACD0F for ; Sun, 5 Apr 2015 11:00:23 -0700 (PDT) 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 hZvFD4ZI-qIH for ; Sun, 5 Apr 2015 11:00:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A0F1ACD05 for ; Sun, 5 Apr 2015 11:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=628; q=dns/txt; s=iport; t=1428256822; x=1429466422; h=date:from:message-id:to:subject:cc; bh=wYX1jRxiuPM6Bvl++ecNdr6C4MonoJ770J7SVtJ6Zlk=; b=GeC2tXoEQi+LgXAzy5jSBtHS9GAAxt1O86iTJXyIR7a+YKf2MLbferbV 0ZklVLIQl0eJ1hftsqvbsA90yRLziXsSetH6eFWsb3z8cSHi5+EusfOry gDvv6GRmg9mOCoaT3yJf98MMwwxarwPvbz3p8p/XcPiDDmEMm34kE/ZQf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYCwD4dyFV/40NJK1cgwhSthoBj3KFfYEYTAEBAQEBAX5BAYRcPDSJDwENylYBAQEHAQEBAR6QIh2EFwWLIok+hyo6gnuCY4lXg0gihA+DEgEBAQ X-IronPort-AV: E=Sophos;i="5.11,528,1422921600"; d="scan'208";a="1552495" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 05 Apr 2015 18:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t35I03DC029207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Apr 2015 18: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 t35I02iW010620; Sun, 5 Apr 2015 11:00:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t35I02pj010612; Sun, 5 Apr 2015 11:00:02 -0700 Date: Sun, 5 Apr 2015 11:00:02 -0700 From: fred@cisco.com Message-Id: <201504051800.t35I02pj010612@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-design-choices 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, 05 Apr 2015 18:00:23 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-design-choices. 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 Mon Apr 6 07:24: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 41DC61A8753 for ; Mon, 6 Apr 2015 07:24:17 -0700 (PDT) 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 sdKZLCANFEvd for ; Mon, 6 Apr 2015 07:24:15 -0700 (PDT) Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by ietfa.amsl.com (Postfix) with SMTP id 1E0051A6EDE for ; Mon, 6 Apr 2015 07:24:14 -0700 (PDT) Received: (qmail 58255 messnum 2393222 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 6 Apr 2015 14:24:13 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail00.svc.cra.dublin.eircom.net (qp 58255) with SMTP; 6 Apr 2015 14:24:13 -0000 Received: from [192.168.1.1] ([86.43.35.194]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id CeQ91q00d4BK5ly01eQCFh; Mon, 06 Apr 2015 15:24:13 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ross Chandler In-Reply-To: <552102B0.6070904@cernet.edu.cn> Date: Mon, 6 Apr 2015 15:24:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> References: <552102B0.6070904@cernet.edu.cn> To: Xing Li X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2015 14:24:17 -0000 > On 5 Apr 2015, at 10:38, Xing Li wrote: >=20 > Ca By =E5=86=99=E9=81=93: >>=20 >> Conclusion: IPv4 sockets need to be supported on hosts that operate = in IPv6-only networks. > Fully agree, based CERNET2's 10 years IPv6-only backbone experience. = We have the following observations. >=20 > (1) If it is the IPv6-only network and IPv6-only applications = (IPv6-only socket), then nobody will use it, except for the = demonstration. > (2) If it is the IPv6-only network with single IPv4/IPv6 translation = and IPv6-only applications (IPv6-only socket), then somebody will use = it, but they are not the majority (less than 5%). > (3) If it is the IPv6-only network with double IPv4/IPv6 translation = and IPv4/IPv6 applications (IPv4/IPv6 sockets), then everybody will use = it happily. >=20 > So I think the transition path should be moving from double = translation to single translation and eventually to IPv6-only. > Regards, >=20 > xing Once IPv6-only with double IPv4/IPv6 translation is available the next = stage to reach is IPv6-only. IPv4 literals will be with us for as long = as IPv4 is. Similar to ISPs dropping services they don=E2=80=99t have a natural = advantage in providing (Usenet, web hosting, email, in fact anything not = tied to the access network) they eventually won=E2=80=99t bother to = operate NAT64. Ross From nobody Mon Apr 6 09:34: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 CDEB31A89AA; Mon, 6 Apr 2015 09:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 645HNpToeq2q; Mon, 6 Apr 2015 09:34:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7FC1A8912; Mon, 6 Apr 2015 09:34:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150406163408.31453.91488.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 09:34:08 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (IPv6 Prefix Length Recommendation for Forwarding) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:34:13 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 Prefix Length Recommendation for Forwarding' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 6 10:10:41 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 2A1E31A9005 for ; Mon, 6 Apr 2015 10:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 QPnNWfSfO6Aq for ; Mon, 6 Apr 2015 10:10:38 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 EB27D1A9004 for ; Mon, 6 Apr 2015 10:10:37 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so48507712obb.1 for ; Mon, 06 Apr 2015 10:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TQ1uoA4f0ZnEf4ukhOMJs1AV/2D4PQaqtiUtx8ccs+k=; b=GfaUdC6sYxk4nrzc3vkmse3O0jddCbXYU2HA6ISbTf2lLzYnynDBYNePr2IGTyW267 82SmcFvDwaJ7D8m9xCxE9wt68kQaU8rfDwhE8SWOi+RODnRbEOBtGh/cUqIpVGLq7YMa dWgzgm+WGgUbqCdP+g5BPAHRaOIX7yqhAWiZg= 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=TQ1uoA4f0ZnEf4ukhOMJs1AV/2D4PQaqtiUtx8ccs+k=; b=MPSIiYVtlEQcwpHWX66LjYsEaTgh69esA713Vl+cZ7n6yhrjRhRk8mYWuxoSmmyJuW hh0st3tm0Lmiz4XfxnfVILQR9cwh9mq6WZYDcDpWBkckPi3JeFu6qrxSGBXWSyRthR/o hMdE97Kq/v8QXoEE4D5XC2z0I0XntpUcntsY0E9qeqbvl1TvvTk0jDQ0aZydMKV81Hl0 BFgTLK8C00CW2WzlLivf3Yym66X0VpTXRoC2mRVFginTyc5cYXqYoaqWZ+dGy5r48MZR V5VBTEWVrIyB1Gy0Iph9j+KtC2b7xlpOfh912LKF4VU37qTkOnak2RC8U++MQ5+ZL/IE 5rng== X-Gm-Message-State: ALoCoQlEy3DzTKY8kXVBcn202T5hif1B/fjHLHHIW6Zz5dqq/vcZrj49K4Sv0secPsIA5ydoHsOK MIME-Version: 1.0 X-Received: by 10.182.88.136 with SMTP id bg8mr19913688obb.86.1428340236698; Mon, 06 Apr 2015 10:10:36 -0700 (PDT) Received: by 10.76.177.229 with HTTP; Mon, 6 Apr 2015 10:10:36 -0700 (PDT) In-Reply-To: References: <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <550F1F1F.3060703@cernet.edu.cn> Date: Mon, 6 Apr 2015 10:10:36 -0700 Message-ID: From: James Woodyatt To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=089e0111bd766d63e705131160d0 Archived-At: Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Apr 2015 17:10:39 -0000 --089e0111bd766d63e705131160d0 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 7:29 PM, Lorenzo Colitti wrote: > If so - then how do you see us getting to IPv6-only? Do you see > application developers moving to support IPv6 by themselves, including on > legacy apps that haven't been updated for years, or that can't be updated > because they were sold on CDs? Or do you see network operators removing > IPv4 regardless of whether that breaks their users' applications? > I don't see us getting to IPv6-only unless and until network operators are compelled by some external force to start breaking IPv4-only applications for their users. Yes, I understand that no such external force exists (thanks in no small part to regulatory capture, but we can leave that aside for now) at present. They will only do so when the costs of supporting IPv4-only exceeds the cost of breaking IPv4-only. And that's probably just as it should be, unless you're the sort who thinks that Internet service operators ought to be treated like public utilities instead of private enterprises. I would support V6OPS publishing a BCP that recommends, to those network operators which cannot abide breaking IPv4-only applications for their users, that subscribers be provided with native dual-stack IPv4/IPv6 service, instead of them trying to make a hard transition to IPv6-only, which relies on them somehow forcing customers to bring their own hosts that can support 464XLAT to the network. I would probably support 6MAN publishing a matching pair of Informational specifications that update RFC 3493 and RFC 3542 with considerations for hosts with a CLAT function integrated. -- james woodyatt Nest Labs, Communications Engineering --089e0111bd766d63e705131160d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 7:29 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:
If so - then how do you s= ee us getting to IPv6-only? Do you see application developers moving to sup= port IPv6 by themselves, including on legacy apps that haven't been upd= ated for years, or that can't be updated because they were sold on CDs?= Or do you see network operators removing IPv4 regardless of whether that b= reaks their users' applications?

I don't see us getting to IPv6-only unless and u= ntil network operators are compelled by some external force to start breaki= ng IPv4-only applications for their users. Yes, I understand that no such e= xternal force exists (thanks in no small part to regulatory capture, but we= can leave that aside for now) at present. They will only do so when the co= sts of supporting IPv4-only exceeds the cost of breaking IPv4-only. And tha= t's probably just as it should be, unless you're the sort who think= s that Internet service operators ought to be treated like public utilities= instead of private enterprises.

=
I would support V6OPS publishing a BCP that reco= mmends, to those network operators which cannot abide breaking IPv4-only ap= plications for their users, that subscribers be provided with native dual-s= tack IPv4/IPv6 service, instead of them trying to make a hard transition to= IPv6-only, which relies on them somehow forcing customers to bring their o= wn hosts that can support 464XLAT to the network.

I would probably support 6MAN publishing a match= ing pair of Informational specifications that update RFC 3493 and RFC 3542 = with considerations for hosts with a CLAT function integrated.

--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering
--089e0111bd766d63e705131160d0-- From nobody Mon Apr 6 16:10: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 F09661ACE14 for ; Mon, 6 Apr 2015 16:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h6-YSzXNN13 for ; Mon, 6 Apr 2015 16:10:55 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 23EE21ACE11 for ; Mon, 6 Apr 2015 16:10:54 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 12803102C5C for ; Mon, 6 Apr 2015 18:10:54 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id A480A133208; Mon, 6 Apr 2015 18:10:53 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 1E1AF2F500E; Mon, 6 Apr 2015 19:08:07 -0400 (EDT) Received: from pwn401ea105.ent.corp.bcbsm.com (unknown [10.64.102.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id 09CB42F5000; Mon, 6 Apr 2015 19:08:07 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Mon, 6 Apr 2015 19:10:52 -0400 From: "Ackermann, Michael" To: "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC Thread-Index: AdBwejVZflkIuUqSRyO7yHiQggoOUQ== Date: Mon, 6 Apr 2015 23:10:51 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CDAAE66@PWN401EA160.ent.corp.bcbsm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] x-tm-as-product-ver: SMEX-10.2.0.3262-7.500.1018-21454.003 x-tm-as-result: No--41.886900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 7c33b0be-2c78-43d0-89d2-d236061685fb X-VPM-MSG-ID: 4e5a668a-cc87-4c7c-a867-37817ac15a33 X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 06 Apr 2015 23:10:57 -0000 HI Fred This will be a most beneficial document for those of us contemplating IPv6 = deployments. =20 A couple questions:=20 1. In Section 2.1.2, second paragraph it states that a network with a = large number of link local only interfaces, can just enable an IGP on each = router and not have to assign and trace addresses on each interface. = Does this advantage apply ONLY to router link local only interfaces?=20 2. Section 2.2.1. Most of the text in this section seems to suggest = that using link-locals for next hop addresses is the best approach. But = there are a couple situations where it is not. And then at the end it = says =22Today most operators use GUA's as next hop addresses=22. As a = neophyte reader I was uncertain what conclusion I should draw? =20 3. Section 2.3.1. For many of us EIGRP is the IGP of choice. Is it = not acceptable for this protocol to be included in the Option Table? =20 Once again, a very helpful beneficial document=21 Thanks Mike -----Original Message----- From: v6ops =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of = fred=40cisco.com Sent: Sunday, April 05, 2015 2:00 PM To: v6ops=40ietf.org Subject: =5Bv6ops=5D draft-ietf-v6ops-design-choices WGLC This is to initiate a two week working group last call of = http://tools.ietf.org/html/draft-ietf-v6ops-design-choices. =20 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=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Mon Apr 6 22: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 7853F1B2A10 for ; Mon, 6 Apr 2015 22:23:56 -0700 (PDT) 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, HTML_MESSAGE=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 p3f2RBJKNiak for ; Mon, 6 Apr 2015 22:23:54 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id E156C1B2A0E for ; Mon, 6 Apr 2015 22:23:53 -0700 (PDT) Received: from [127.0.0.1] (unknown [58.200.235.35]) by centos (Coremail) with SMTP id AQAAf3BrIANjaCNVEBVHAA--.8315S5; Tue, 07 Apr 2015 13:17:24 +0800 (CST) Message-ID: <552369C8.5000801@cernet.edu.cn> Date: Tue, 07 Apr 2015 13:23:20 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ross Chandler References: <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> In-Reply-To: <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> Content-Type: multipart/alternative; boundary="------------060601000309000001070504" X-CM-TRANSID: AQAAf3BrIANjaCNVEBVHAA--.8315S5 X-Coremail-Antispam: 1UD129KBjvJXoW7Kw43Zw4DGr1fKrWrKFWfZrb_yoW8CrWkpa y3Wa1UCanrGF10kas8Xw4fZwnY9FWkGr4kGw1jyrsxAws8GF4fKr429rZ0yryftryxXr4j grWUJ345Xa18ArJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqSb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW8Jr 0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAqjxCE14ACF2xKxwAv7VC2z280 aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMx8GjcxK6IxK0x IIj40E5I8CrwCY02Avz4vE14v_GrWl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWU GVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7V AKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j 6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVW8JVWxJw CI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUF0eHDUUU U X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2015 05:23:56 -0000 This is a multi-part message in MIME format. --------------060601000309000001070504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Ross Chandler 写é“: >> On 5 Apr 2015, at 10:38, Xing Li wrote: >> >> Ca By 写é“: >> >>> Conclusion: IPv4 sockets need to be supported on hosts that operate in IPv6-only networks. >>> >> Fully agree, based CERNET2's 10 years IPv6-only backbone experience. We have the following observations. >> >> (1) If it is the IPv6-only network and IPv6-only applications (IPv6-only socket), then nobody will use it, except for the demonstration. >> (2) If it is the IPv6-only network with single IPv4/IPv6 translation and IPv6-only applications (IPv6-only socket), then somebody will use it, but they are not the majority (less than 5%). >> (3) If it is the IPv6-only network with double IPv4/IPv6 translation and IPv4/IPv6 applications (IPv4/IPv6 sockets), then everybody will use it happily. >> >> So I think the transition path should be moving from double translation to single translation and eventually to IPv6-only. >> Regards, >> >> xing >> > > Once IPv6-only with double IPv4/IPv6 translation is available the next stage to reach is IPv6-only. IPv4 literals will be with us for as long as IPv4 is. > If all the users on the Internet can access both the IPv4 (via double and single translation) and IPv6 (native) contents, who cares if the IPv4 literals will coexist with IPv4 and IPv6 for a long time? > Similar to ISPs dropping services they don’t have a natural advantage in providing (Usenet, web hosting, email, in fact anything not tied to the access network) they eventually won’t bother to operate NAT64. > If the ISP lacks the public IPv4 addresses, the justification is to compare (1) (stateful or stateless NAT64 + [host based] double translation) (2) (NAT44 + dual-stack) (3) NAT44-only Based on 10 years IPv6 operation experience of CERNET2, I think (1) costs less than (2) and (1) has more features (IPv6) than (3). Therefore (1) is the way to go. Regards, xing > Ross > > > > > > > --------------060601000309000001070504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Ross Chandler 写é“: 
On 5 Apr 2015, at 10:38, Xing Li <xing@cernet.edu.cn> wrote:

Ca By 写é“:
    
Conclusion:  IPv4 sockets need to be supported on hosts that operate in IPv6-only networks.
      
Fully agree, based CERNET2's 10 years IPv6-only backbone experience. We have the following observations.

(1) If it is the IPv6-only network and IPv6-only applications (IPv6-only socket), then nobody will use it, except for the demonstration.
(2) If it is the IPv6-only network with single IPv4/IPv6 translation and IPv6-only applications (IPv6-only socket), then somebody will use it, but they are not the majority (less than 5%).
(3) If it is the IPv6-only network with double IPv4/IPv6 translation and IPv4/IPv6 applications (IPv4/IPv6 sockets), then everybody will use it happily.

So I think the transition path should be moving from double translation to single translation and eventually to IPv6-only.
Regards,

xing
    

Once IPv6-only with double IPv4/IPv6 translation is available the next stage to reach is IPv6-only. IPv4 literals will be with us for as long as IPv4 is.

If all the users on the Internet can access both the IPv4 (via double and single translation) and IPv6 (native) contents, who cares if the IPv4 literals will coexist with IPv4 and IPv6 for a long time?

Similar to ISPs dropping services they don’t have a natural advantage in providing (Usenet, web hosting, email, in fact anything not tied to the access network) they eventually won’t bother to operate NAT64.

If the ISP lacks the public IPv4 addresses, the justification is to compare

(1) (stateful or stateless NAT64 + [host based] double translation)
(2) (NAT44 + dual-stack)
(3) NAT44-only

Based on 10 years IPv6 operation experience of CERNET2, I think (1) costs less than (2) and (1) has more features (IPv6) than (3). Therefore (1) is the way to go.

Regards,

xing


Ross

--------------060601000309000001070504-- From nobody Mon Apr 6 22:50: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 CCE2F1B31A3 for ; Mon, 6 Apr 2015 22:50:55 -0700 (PDT) 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 uXySjlrrSxaS for ; Mon, 6 Apr 2015 22:50:54 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4666A1B31A2 for ; Mon, 6 Apr 2015 22:50:54 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id BAF6C1FCC36; Tue, 7 Apr 2015 05:50:50 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 66563160069; Tue, 7 Apr 2015 05:58:08 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id BD763160066; Tue, 7 Apr 2015 05:58:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rock.dv.isc.org (Postfix) with ESMTP id 315D52C71A98; Tue, 7 Apr 2015 15:50:46 +1000 (EST) To: Xing Li From: Mark Andrews References: <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn> In-reply-to: Your message of "Tue, 07 Apr 2015 13:23:20 +0800." <552369C8.5000801@cernet.edu.cn> Date: Tue, 07 Apr 2015 15:50:46 +1000 Message-Id: <20150407055046.315D52C71A98@rock.dv.isc.org> Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2015 05:50:56 -0000 In message <552369C8.5000801@cernet.edu.cn>, Xing Li writes: > Ross Chandler 写é“: > >> On 5 Apr 2015, at 10:38, Xing Li wrote: > >> > >> Ca By 写é“: > >> > >>> Conclusion: IPv4 sockets need to be supported on hosts that operate in I > Pv6-only networks. > >>> > >> Fully agree, based CERNET2's 10 years IPv6-only backbone experience. We ha > ve the following observations. > >> > >> (1) If it is the IPv6-only network and IPv6-only applications (IPv6-only s > ocket), then nobody will use it, except for the demonstration. > >> (2) If it is the IPv6-only network with single IPv4/IPv6 translation and I > Pv6-only applications (IPv6-only socket), then somebody will use it, but they > are not the majority (less than 5%). > >> (3) If it is the IPv6-only network with double IPv4/IPv6 translation and I > Pv4/IPv6 applications (IPv4/IPv6 sockets), then everybody will use it happily > . > >> > >> So I think the transition path should be moving from double translation to > single translation and eventually to IPv6-only. > >> Regards, > >> > >> xing > >> > > > > Once IPv6-only with double IPv4/IPv6 translation is available the next stag > e to reach is IPv6-only. IPv4 literals will be with us for as long as IPv4 is > . > > > > If all the users on the Internet can access both the IPv4 (via double > and single translation) and IPv6 (native) contents, who cares if the > IPv4 literals will coexist with IPv4 and IPv6 for a long time? > > > Similar to ISPs dropping services they don’t have a natural advantage in pro > viding (Usenet, web hosting, email, in fact anything not tied to the access n > etwork) they eventually won’t bother to operate NAT64. > > > > If the ISP lacks the public IPv4 addresses, the justification is to compare > > (1) (stateful or stateless NAT64 + [host based] double translation) > (2) (NAT44 + dual-stack) > (3) NAT44-only (4) DS-Lite Additionally ISP's don't need to operate the translation/encapsulation services themselves. 464XLAT and DS-Lite both can be done elsewhere on the net. Eventually IPv4 will be a "service" you get from a niche service provider not your regular ISP. > Based on 10 years IPv6 operation experience of CERNET2, I think (1) > costs less than (2) and (1) has more features (IPv6) than (3). Therefore > (1) is the way to go. > > Regards, > > xing > > > > Ross -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Apr 6 23:14:52 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 B1FF31A0125 for ; Mon, 6 Apr 2015 23:14:51 -0700 (PDT) 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, HTML_MESSAGE=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 mlGh7U73Vfrb for ; Mon, 6 Apr 2015 23:14:50 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id CC1921A0068 for ; Mon, 6 Apr 2015 23:14:49 -0700 (PDT) Received: from [127.0.0.1] (unknown [58.200.235.35]) by centos (Coremail) with SMTP id AQAAf3DbhQhpdCNVDS5HAA--.7782S5; Tue, 07 Apr 2015 14:08:42 +0800 (CST) Message-ID: <552375CD.5050302@cernet.edu.cn> Date: Tue, 07 Apr 2015 14:14:37 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mark Andrews References: <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn> <20150407055046.315D52C71A98@rock.dv.isc.org> In-Reply-To: <20150407055046.315D52C71A98@rock.dv.isc.org> Content-Type: multipart/alternative; boundary="------------030309040609020503070808" X-CM-TRANSID: AQAAf3DbhQhpdCNVDS5HAA--.7782S5 X-Coremail-Antispam: 1UD129KBjvdXoWrZw1kZF1rZw13Xry8JFy3XFb_yoWxurc_ur yrGrsIvw4UXrs7u3WrX3s3u34Sg393G3ykZrnrJ3s7Gas3ZrnrGFn2grs3WFs3Jw4rKrna vFyDt34Ykw13ujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbo8YjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJV WxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6c804VAFz4xC04v7McIj6xIIjxv2 0xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7 xvr2IY64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxkIecxEwVAFwVW8AwCF04k20xvY0x0E wIxGrwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMI IF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVF xhVjvjDU0xZFpf9x07jeuWLUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Apr 2015 06:14:51 -0000 This is a multi-part message in MIME format. --------------030309040609020503070808 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit >> If the ISP lacks the public IPv4 addresses, the justification is to compare >> >> (1) (stateful or stateless NAT64 + [host based] double translation) >> (2) (NAT44 + dual-stack) >> (3) NAT44-only >> > > (4) DS-Lite > > Additionally ISP's don't need to operate the translation/encapsulation > services themselves. 464XLAT and DS-Lite both can be done elsewhere > on the net. Eventually IPv4 will be a "service" you get from a > niche service provider not your regular ISP. > > Good point. I includes this scenario in (1). Regards, xing >> Based on 10 years IPv6 operation experience of CERNET2, I think (1) >> costs less than (2) and (1) has more features (IPv6) than (3). Therefore >> (1) is the way to go. >> >> Regards, >> >> xing >> >> >> >>> Ross >>> > > --------------030309040609020503070808 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 7bit 
If the ISP lacks the public IPv4 addresses, the justification is to compare

(1) (stateful or stateless NAT64 + [host based] double translation)
(2) (NAT44 + dual-stack)
(3) NAT44-only
    

(4) DS-Lite

Additionally ISP's don't need to operate the translation/encapsulation
services themselves.  464XLAT and DS-Lite both can be done elsewhere
on the net.  Eventually IPv4 will be a "service" you get from a
niche service provider not your regular ISP.

Good point. I includes this scenario in (1).  Regards, xing


  

    
Based on 10 years IPv6 operation experience of CERNET2, I think (1) 
costs less than (2) and (1) has more features (IPv6) than (3). Therefore 
(1) is the way to go.

Regards,

xing


    

    

      
Ross
      

    

  

  

  








--------------030309040609020503070808--



From nobody Tue Apr  7 02:18: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 187501B3355 for ; Tue,  7 Apr 2015 02:18:42 -0700 (PDT)
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 alloucOZlydK for ; Tue,  7 Apr 2015 02:18:40 -0700 (PDT)
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 0C5221B3353 for ; Tue,  7 Apr 2015 02:18:39 -0700 (PDT)
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 t379IZAP029424; Tue, 7 Apr 2015 11:18:35 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C8E682029C2; Tue,  7 Apr 2015 11:19:37 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BA804200BC3; Tue,  7 Apr 2015 11:19:37 +0200 (CEST)
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 t379IF4I029228; Tue, 7 Apr 2015 11:18:35 +0200
Message-ID: <5523A0D7.2010509@gmail.com>
Date: Tue, 07 Apr 2015 11:18:15 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Brian E Carpenter , "Fred Baker (fred)" 
References: <8D33A146-8721-4C43-8453-0385ED901D79@nominum.com> <5506E21D.80000@bogus.com> <8659A9C4-129C-4DA2-9265-B06D4AA4E262@nominum.com> <20150316.181923.74694044.sthaug@nethelp.no>    <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com>
In-Reply-To: <55161E85.8020806@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 09:18:42 -0000

Le 28/03/2015 04:22, Brian E Carpenter a écrit :
> On 28/03/2015 08:01, Fred Baker (fred) wrote:
>>> I dont work for an Operator, but it is reasonable to expect
>>> operators to filter Routing Headers.
>>>
>>> These are not used by any application and open a signficant
>>> security risk.
>>
>> 
>>
>> I understand the security risk, I think; that’s discussed in RFC
>> 5095. I’ll note, however, that the RFC doesn’t address “routing
>> headersâ€; it addresses “routing headers of type 0â€. The Segment
>> Routing header is a Routing Header, and trashing all Segment
>> Routing traffic because we have an issue with RH0 traffic seems a
>> trifle extreme.
>
> This is laid out precisely in RFC 7045*, so you can tell any
> operator that trashes all RH packets that they are in violation and
> the protocol police are very angry with them.
>
> Brian
>
> * "The IPv6 Routing Header Types 0 and 1 have been deprecated.  Note
> that Type 0 was deprecated by [RFC5095].  However, this does not
> mean that the IPv6 Routing Header can be unconditionally dropped by
> forwarding nodes.  Packets containing standardised and undeprecated
> Routing Headers SHOULD be forwarded by default.  At the time of
> writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the
> experimental Routing Header Types 253 and 254 [RFC4727].  Others may
> be defined in the future."

Brian,

So currently RH types 2 (Mobile IPv6), 3 (RPL) and 253 and 254 for
experiments are not deprecated andshould be implemented.

In protocole Mobile IPv6 the RH type 2 is used in some cases for Route
Optimization (there are other MIP6 cases).  This feature (RO) needs to
be implemented also in the Correspondent Nodes, not only in the network.
  And, the CNs dont implement RO.  If the CNs dont implement RO then
there is no reason for the network to transmit RH type 2.

Second, for RH type 3 in RPL - this is local-only routing, i.e. a
network of small devices which are typically disconnected from the
Internet.  The RH must contain only addresses within that domain, or let
self do tunnelling instead.

RH types 253 and 254 are EXPERIMENTAL - but there is no experiment
described.  We dont even know whether it is a local experiment or
something that needs to get through Internet overall.

For these reasons, I still suppose data carrying operators have all
reasons to filter RHs altogether.

Alex

>
>>
>> I get a little antsy is it being filtered by a system other than
>> the one in the destination address or a system acting as a
>> firewall. The operator doesn’t necessarily know what network the
>> address is in, or whether there might be a private arrangement
>> between networks that use his network as transit to communicate. I
>> would want the transit domains to not be applying transitive policy
>> to their customer’s or peer’s traffic without their knowledge.
>>
>>
>>
>> _______________________________________________ v6ops mailing list
>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>



From nobody Tue Apr  7 02:26: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 81EA11B338F for ; Tue,  7 Apr 2015 02:26:15 -0700 (PDT)
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 n069qcDmMgrj for ; Tue,  7 Apr 2015 02:26:13 -0700 (PDT)
Received: from mail19.svc.cra.dublin.eircom.net (mail19.svc.cra.dublin.eircom.net [159.134.118.218]) by ietfa.amsl.com (Postfix) with SMTP id B4A3B1B3388 for ; Tue,  7 Apr 2015 02:25:58 -0700 (PDT)
Received: (qmail 16071 messnum 320396 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 7 Apr 2015 09:25:56 -0000
Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail19.svc.cra.dublin.eircom.net (qp 16071) with SMTP; 7 Apr 2015 09:25:56 -0000
Received: from [192.168.1.5] ([95.44.35.164]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id CxRq1q00h3YUviP01xRwq8; Tue, 07 Apr 2015 10:25:56 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ross Chandler 
In-Reply-To: <552369C8.5000801@cernet.edu.cn>
Date: Tue, 7 Apr 2015 10:25:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:              <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>
To: Xing Li 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 07 Apr 2015 09:26:15 -0000

> On 7 Apr 2015, at 06:23, Xing Li  wrote:
>> Once IPv6-only with double IPv4/IPv6 translation is available the =
next stage to reach is IPv6-only. IPv4 literals will be with us for as =
long as IPv4 is. =20
> If all the users on the Internet can access both the IPv4 (via double =
and single translation) and IPv6 (native) contents, who cares if the =
IPv4 literals will coexist with IPv4 and IPv6 for a long time?

I think for 3GPP especially people care more about the IPv4 literals & =
IPv4 only apps issue as that necessitates IPv4+IPv6 on the PDP/PDN =
connection for Internet access. Having 464xlat stops this issue =
hindering adoption of IPv6. With the local-ipv4 socket transition =
solution efforts to fix IPv4 literals and IPv4 only apps can proceed in =
parallel with IPv6 deployment instead of impeding it.

In fixed Internet, not having a local-ipv4 socket translation solution =
isn=E2=80=99t as bad a hinderance as the end hosts sit behind a CPE =
providing dual-stack on the LAN side.=20

Ross


From nobody Tue Apr  7 02:32: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 032CE1B3382 for ; Tue,  7 Apr 2015 02:32:20 -0700 (PDT)
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 UeCAG9ft_pPJ for ; Tue,  7 Apr 2015 02:32:16 -0700 (PDT)
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 642871B3380 for ; Tue,  7 Apr 2015 02:32:15 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 215226010D for ; Tue,  7 Apr 2015 11:32:14 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D67686291A for ; Tue,  7 Apr 2015 11:32:13 +0200 (CEST)
Received: (qmail 72370 invoked by uid 1007); 7 Apr 2015 11:32:13 +0200
Date: Tue, 7 Apr 2015 11:32:13 +0200
From: Gert Doering 
To: Alexandru Petrescu 
Message-ID: <20150407093213.GJ54385@Space.Net>
References:   <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5523A0D7.2010509@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 09:32:20 -0000

Hi,

On Tue, Apr 07, 2015 at 11:18:15AM +0200, Alexandru Petrescu wrote:
> For these reasons, I still suppose data carrying operators have all
> reasons to filter RHs altogether.

The only halfway acceptable reason is "I need to drop RH0, but have
stupid gear that cannot differenciate, so either drop-all or drop-none".

(Yes, this happens for brand new top-of-the-line gear...)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Tue Apr  7 03:07: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 313CD1A1AC6 for ; Tue,  7 Apr 2015 03:07:25 -0700 (PDT)
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 HvMCHBBxxNMS for ; Tue,  7 Apr 2015 03:07:23 -0700 (PDT)
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 9301E1A1BDA for ; Tue,  7 Apr 2015 03:07:23 -0700 (PDT)
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 t37A7JOL021041; Tue, 7 Apr 2015 12:07:19 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BA0DC202AF1; Tue,  7 Apr 2015 12:08:21 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A076D202A8C; Tue,  7 Apr 2015 12:08:21 +0200 (CEST)
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 t37A6dOB004644; Tue, 7 Apr 2015 12:07:19 +0200
Message-ID: <5523AC2F.6070802@gmail.com>
Date: Tue, 07 Apr 2015 12:06:39 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Gert Doering 
References:   <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net>
In-Reply-To: <20150407093213.GJ54385@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 10:07:25 -0000

Le 07/04/2015 11:32, Gert Doering a écrit :
> Hi,
>
> On Tue, Apr 07, 2015 at 11:18:15AM +0200, Alexandru Petrescu wrote:
>> For these reasons, I still suppose data carrying operators have
>> all reasons to filter RHs altogether.
>
> The only halfway acceptable reason is "I need to drop RH0, but have
> stupid gear that cannot differenciate, so either drop-all or
> drop-none".

I agree.

This begs a question about particular hardware which may not distinguish
types, and thus force others to drop-all RHs, regardless of their type -
what is that hardware?

Alex

>
> (Yes, this happens for brand new top-of-the-line gear...)
>
> Gert Doering -- NetMaster
>



From nobody Tue Apr  7 05:36:59 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 78E891A87AF for ; Tue,  7 Apr 2015 05:36:57 -0700 (PDT)
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 qAbhhnXUjMVb for ; Tue,  7 Apr 2015 05:36:55 -0700 (PDT)
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 854101A87AE for ; Tue,  7 Apr 2015 05:36:55 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1123A62917 for ; Tue,  7 Apr 2015 14:36:54 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8F5676010D for ; Tue,  7 Apr 2015 14:36:53 +0200 (CEST)
Received: (qmail 88516 invoked by uid 1007); 7 Apr 2015 14:36:53 +0200
Date: Tue, 7 Apr 2015 14:36:53 +0200
From: Gert Doering 
To: Alexandru Petrescu 
Message-ID: <20150407123653.GS54385@Space.Net>
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pZNecdF2o6CbdTLS"
Content-Disposition: inline
In-Reply-To: <5523AC2F.6070802@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 12:36:57 -0000

--pZNecdF2o6CbdTLS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Apr 07, 2015 at 12:06:39PM +0200, Alexandru Petrescu wrote:
> This begs a question about particular hardware which may not distinguish
> types, and thus force others to drop-all RHs, regardless of their type -
> what is that hardware?

"Hardware+Software".  My current beef is Cisco IOS XR on ASR9001, which
has hardware capable of doing about anything, and software that missed that
particular call...

(Of course there's 6500/Sup720, which has hardware not capable of doing
any EH header filtering, but that is *old* stuff and not particularily
relevant here)

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--pZNecdF2o6CbdTLS
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVSPPZd9WwGXkzn/FAQJk1A/9H0BuXGVLnBiJlS2ZqwvMSFzyHoVY35x8
OfF1x6fg3JilCI6raTQvsHGv3Gm0oqNGbSXE2c9eLRteAP4+6Vr3AuckV/XjUdeY
RD5DIHKeCNSqs4Imq5Kuul3R4MZGprPC5KNb1tl/VjNH08XCV+iAJGkLINPlqMFD
vhiE35H4o2cyLwzvhExRGIMD4DUhDkb5UnppT+gXl9h18MxpSxFJCYqq+b94Dl8Z
eMjQOdTQDr3mzK6KcVm/U3xxzoPFd0TCaZDMbcFDId/JbWeYgZ8m7rWYi0EC5af8
pW/UPj7kmtVLTtR4+0dJqJ4EMlH3pRFfHdqIGSjzoBuRBlaedLD35xfGxDjzKcos
KWpLc1RDvdx6+I1kTFen7kp54Q7uHqzTR2bsCrFnX8FE/oLzh7ir+GUfeL1HuOM9
GXHjW8685RC9B6W/lXlQvySrYZ65tzWBSyCybRRZUYr38XaCSoO9ZZWk9xmBVMY6
w07qBe8qiwNb1FgmctgHBLA/Qz61jPLHha1sjk4W9n/eBVLkVdcsFBDTCqevVyQA
D3wdHVn94Je5tFTeU5R9rOVpTzZIg2Dnf8+PLbMSLDWCy6iJhf6WZLeaP8LRH8NK
kCj87ELGcepTpo0AuZjiodjPDjqqkikTgMN/ao1jwK+gExbWEVyZr+uk/nDn3s2x
jbNbX6VNLNw=
=2B2P
-----END PGP SIGNATURE-----

--pZNecdF2o6CbdTLS--


From nobody Tue Apr  7 10: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 34D241B38BD for ; Tue,  7 Apr 2015 10:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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] 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 1fFO52up54Px for ; Tue,  7 Apr 2015 10:30:54 -0700 (PDT)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 569221B38B8 for ; Tue,  7 Apr 2015 10:30:54 -0700 (PDT)
Received: by obbgh1 with SMTP id gh1so95431162obb.1 for ; Tue, 07 Apr 2015 10:30:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TplwExgyaVggiCoI9o0ow8ux/wm7xz0pLtjUX4iBRAA=; b=TBOaGlmbIAMVFM1vfy2/Ykp4Nl3sU4dRPO+wYgDgp0yVLD0mNFlqOjnCVpKmMEP3lu IX91LDWaUtSP2jP4uYI+8DfF+Cp0lJTmcMkGcApHE1Pk3gtqc2gAq5eJ60oHauTYKKaM kK/C/galkNgDg8ohq63WY2B1wj3km3r6EW5Ko=
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=TplwExgyaVggiCoI9o0ow8ux/wm7xz0pLtjUX4iBRAA=; b=FsqIFvBmF23msyStGPl0MZW9GhMI8me+4VqTX82QW8BVT58NEFETr2bxbe925Jc43u KZWTp8zF/sXE0zXn4q2Nq4o+6+v4j9z4ul5wFs+Q0FUAZXBKQ7s37jgI6bLXf4oJlwzv ycMgyyETsWxKzNnEx9dt4ZrshMPusyleNwfjm5XL8uTj0Qu2xAXfUSDqHfBp6ejJXNxO zR0Xx2+0kn3zNmuvySBukwBOiqcP/pX8FWakK+Ak2ZbPoPq0bJJkkN5J1+sbkby7ZIFa 5JlK52pXae2QwlzQ6e+wl+Lzktp5SsLfGOZFylU8DKSmu7M5Xtpox2yvZZbCMEFj1vVI 3Qig==
X-Gm-Message-State: ALoCoQmcRq36wSMH3kltQ4r0+fsk3JUfvD6PWo51CZ3ZpiGsYhcHEBKVOQv5yGrbiQjxhp7saJ5o
MIME-Version: 1.0
X-Received: by 10.182.137.136 with SMTP id qi8mr25778562obb.51.1428427843008;  Tue, 07 Apr 2015 10:30:43 -0700 (PDT)
Received: by 10.76.177.229 with HTTP; Tue, 7 Apr 2015 10:30:42 -0700 (PDT)
In-Reply-To: <552369C8.5000801@cernet.edu.cn>
References:              <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>
Date: Tue, 7 Apr 2015 10:30:42 -0700
Message-ID: 
From: James Woodyatt 
To: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary=001a11c352362b978b051325c6ae
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 07 Apr 2015 17:30:55 -0000

--001a11c352362b978b051325c6ae
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 6, 2015 at 10:23 PM, Xing Li  wrote:

>
> If all the users on the Internet can access both the IPv4 (via double and
> single translation) and IPv6 (native) contents, who cares if the IPv4
> literals will coexist with IPv4 and IPv6 for a long time?
>

You have obviously never tried to sell recurring software maintenance work
to support IPv6 transition to the management of a commercial host operating
systems vendor.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--001a11c352362b978b051325c6ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Apr 6, 2015 at 10:23 PM, Xing Li <xing@cernet.edu.cn> w=
rote:



 =20




If all the users on the Internet can access both the IPv4 (via double
and single translation) and IPv6 (native) contents, who cares if the
IPv4 literals will coexist with IPv4 and IPv6 for a long time?

You have obviously never tried to sell recurring software m=
aintenance work to support IPv6 transition to the management of a commercia=
l host operating systems vendor.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering
<=
/div>




--001a11c352362b978b051325c6ae--


From nobody Tue Apr  7 18:10: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 0C17F1B2AAE for ; Tue,  7 Apr 2015 18:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYLqXPJsPYwK for ; Tue,  7 Apr 2015 18:10:14 -0700 (PDT)
Received: from tor-smtp-01.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id BFD911B2AB0 for ; Tue,  7 Apr 2015 18:10:14 -0700 (PDT)
Received: from bas5-ottawa10-1177851009.dsl.bell.ca ([70.52.148.129] helo=[10.0.1.23]) by tor-smtp-01.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1YfeVR-0004NG-M6; Tue, 07 Apr 2015 21:10:14 -0400
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Philip Matthews 
In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDAAE66@PWN401EA160.ent.corp.bcbsm.com>
Date: Tue, 7 Apr 2015 21:10:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DF32A06-80FA-461A-A387-DE55F1DB79DB@magma.ca>
References: <4FC37E442D05A748896589E468752CAA0CDAAE66@PWN401EA160.ent.corp.bcbsm.com>
To: "Ackermann, Michael" , "Fred Baker (fred)" 
X-Mailer: Apple Mail (2.1085)
X-Authenticated: philip_matthews - bas5-ottawa10-1177851009.dsl.bell.ca ([10.0.1.23]) [70.52.148.129]
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 08 Apr 2015 01:10:17 -0000

On 2015-04-06, at 19:10 , Ackermann, Michael wrote:

> HI Fred
>=20
> This will be a most beneficial document for those of us contemplating =
IPv6 deployments. =20
>=20
> A couple questions:=20
>=20
> 1.  In Section 2.1.2, second paragraph it states that a network with a =
large number of link local only interfaces, can just enable an IGP on =
each router  and not have to assign and trace addresses on each =
interface.   Does this advantage apply ONLY  to router link local only =
interfaces?=20

Are you asking if the same approach could be taken for host interfaces?  =
If so, then the question is:  how would you send packets to the host =
from off-link?  With a router, there is a virtual interface that has a =
(manually-assigned) global or unique-local address, and so packets can =
be sent to this address.  Usually hosts do not have such interfaces...


>=20
> 2.  Section 2.2.1.   Most of the text in this section seems to suggest =
that using link-locals for next hop addresses is the best approach.   =
But there are a couple situations where it is not.   And then at the end =
it says "Today most operators use GUA's as next hop addresses".      As =
a neophyte reader I was uncertain what conclusion I should draw? =20

That, despite the specs seeming to say that static-routes should use =
link-local addresses, that in practice it can sometimes cause problems =
so most operators use GUAs instead.
Most large providers are large corporations with many employees with =
varying skill sets. These corporations have established procedures that =
work for IPv4 and most employees try to apply these IPv4 procedures to =
IPv6. Anything that causes IPv6 to be different than IPv4 means special =
procedures must be developed and taught to employees. Using link-local =
addresses in static routes is a difference, so most large providers =
don't use them.   Things can be different at a smaller provider where =
differences can be handled more easily.

>=20
> 3.  Section 2.3.1.    For many of us EIGRP is the IGP of choice.     =
Is it not acceptable for this protocol to be included in the  Option =
Table? =20

The thing about EIGRP is that it is not standardized, but is Cisco =
proprietary. So I suspect that we could only say "Cisco EIGRP does this" =
and "Cisco EIGRP does that", which is not a typical thing for IETF =
documents.  I work for Alcatel-Lucent, and I know we do not support =
EIGRP on our routers because it is not standardized. Most large =
providers don't use it for that reason.

Fred, as WG chair and as a Cisco employee, could comment further on =
whether he thinks the document should cover EIGRP.


>=20
>=20
> Once again,  a very helpful beneficial document!

Thanks!!  The document started out as my attempt to document many of the =
questions I had when I first started to design IPv6 networks. I also =
credit my co-author Victor, who added many useful insights gained from =
deploying IPv6 when he worked for Rogers Communications.

- Philip

>=20
> Thanks
>=20
> Mike
>=20
>=20
>=20
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of =
fred@cisco.com
> Sent: Sunday, April 05, 2015 2:00 PM
> To: v6ops@ietf.org
> Subject: [v6ops] draft-ietf-v6ops-design-choices WGLC
>=20
> This is to initiate a two week working group last call of =
http://tools.ietf.org/html/draft-ietf-v6ops-design-choices. =20
> 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.
>=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.
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20
> The information contained in this communication is highly confidential =
and is intended solely for the use of the individual(s) to whom this =
communication is directed. If you are not the intended recipient, you =
are hereby notified that any viewing, copying, disclosure or =
distribution of this information is prohibited. Please notify the =
sender, by electronic mail or telephone, of any unintended receipt and =
delete the original message without making any copies.
>=20
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan =
are nonprofit corporations and independent licensees of the Blue Cross =
and Blue Shield Association.
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From nobody Wed Apr  8 00:41: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 957DF1B2DE5 for ; Wed,  8 Apr 2015 00:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.622
X-Spam-Level: 
X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41zoA-Vrseok for ; Wed,  8 Apr 2015 00:41:50 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (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 2E6A61B2D4A for ; Wed,  8 Apr 2015 00:40:44 -0700 (PDT)
Received: by labbd9 with SMTP id bd9so48234505lab.2 for ; Wed, 08 Apr 2015 00:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=FzRbEiV3PgDn7aoGvSsn9t7VYXQi7XoMkmA9gF47JgA=; b=HFJ3auPgbkVouTNSZLivd32YN4z2BkOlrByEVjR/be4aHDaVgC+TIqevPD5/qHveNS TUcsmPc4h9PpTBDttJhcaoKGrlStNnPRxNfP0jWJQUGfglRvj5l6mZ72vL96qbYyDTwa 2ghLdTtjrhdKAT+6mPCe74bHdJGTmp+HH2GC5YxxfK2b4epRAKsfhHrHMKYR62Oys4iZ JhNMvnHDoTMNDpAJPQMj00FRLEnDD4+8QpV2zr1WofnvtlvHnIBsqyYjkPrv8YiSOmCj iPnHkvOmvj3Gg/d2YyaAKXh0xvbIDOphxXRlqK9OzZOofWs21rKKd9RkE1mA1gnvChju qcsg==
X-Received: by 10.152.219.2 with SMTP id pk2mr21588186lac.107.1428478842603; Wed, 08 Apr 2015 00:40:42 -0700 (PDT)
MIME-Version: 1.0
Sender: edwinsc@gmail.com
Received: by 10.152.29.72 with HTTP; Wed, 8 Apr 2015 00:40:12 -0700 (PDT)
In-Reply-To: 
References:  <8EF27210-0C56-4F6D-81FD-B27EE34ED444@cisco.com>  <95C21895-305F-46BD-A571-925FBD838EEA@cisco.com> <940432F8-44CD-43E7-B570-D3CAA07C4710@cisco.com>   
From: Edwin Cordeiro 
Date: Wed, 8 Apr 2015 09:40:12 +0200
X-Google-Sender-Auth: wW5CJTRLCKWcb1T1FqusOonN3BE
Message-ID: 
To: "Fred Baker (fred)" 
Content-Type: multipart/alternative; boundary=001a1134188cfb9023051331a5a2
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] Discussion: IPv4 as a Service
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 08 Apr 2015 07:41:52 -0000

--001a1134188cfb9023051331a5a2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dear Fred,

I read your document and I have some material that might be useful in the
"Observations and Experiments" part. On my Master thesis I compared
DS-Lite, 464XLAT, MAP-E and MAP-T, the results are available at:
http://edwin.scordeiro.net/master

The dissertation text is in Portuguese, but there is a summary article in
English available in the link as well.

If you want, I may assist on your proposed task.

Best regards,

--
Edwin Cordeiro, M.Sc.     Network Architectures and Services
T: +49 89 289 18550       Department of Computer Science
M: +49 175 215 6481      Technische Universit=C3=A4t M=C3=BCnchen

On Wed, Apr 1, 2015 at 3:11 AM, Fred Baker (fred)  wrote:

> Since they might be among the early folks I would ask to write something,
> I asked Xing Li, Akira, and Suprita to comment specifically on the outlin=
e:
> =E2=80=9Cif you were to write such a document, how would this outline wor=
k for you=E2=80=9D.
>
> Suprita replied as follows. I have changed the proposed outline in a
> manner similar to her suggestion.
>
> On Mar 31, 2015, at 2:41 PM, suprita  wrote:
>
> I tried to first re-write the "Outlined hierarchy" used  and then make an=
y
> modification to it, as per ease of answering them.
> I did not have to do many changes to the one already used by you, with
> minor adjustments in naming convention and placements..
>
> Experience Gathering : Heading
>
> General/Overview
> Major Motivation(s)
> v4 as-a-service Requirements
> Exactly which v4 Service Types
> Architecture and Methodology
> Major Design Considerations
> Regulatory Considerations
> Security Considerations
> Operational Considerations
> End-User Experience Considerations
> Observations and Experiences
> Effects on End-User
> Effects on Internal Staff
> Planning & Design
> Implementation
> Operations
> Effects on Business
> Summary: Post-mortem Report
> Deviations from RFC's/Drafts/Standards
> Worked Well
> Did not work well
>
>
> On Wed, Apr 1, 2015 at 1:56 AM, suprita  wrote:
>
>> Dear Fred,
>>
>> I am yet to apply newly learnt skill from you of applying filters for th=
e
>> directly addressed e-mails :).
>> I will sure go through the doc in detail and comment.
>>
>> Thank you,
>> Suprita
>>
>> On Tue, Mar 31, 2015 at 2:04 AM, Fred Baker (fred) 
>> wrote:
>>
>>>
>>> > On Mar 30, 2015, at 12:50 PM, Fred Baker  wrote:
>>> >
>>> > Over the weekend, we crowd-sourced a number of pretty good questions.
>>> I took the liberty, this morning, of reorganizing the text a bit. The "=
list
>>> of technologies" and "list of questions" remain, but I have added "poss=
ible
>>> (classes of) documents to be developed" and a first cut at a proposed
>>> outline, with the questions from above pulled in to make it clear what =
I
>>> might hope the section might comment on.
>>> >
>>> > Collecting comments and thoughts. I guarantee there is something we
>>> haven=E2=80=99t thought of (as I was reorganizing, several points poppe=
d out, and
>>> I=E2=80=99m sure I=E2=80=99m not that smart).
>>> >
>>> >>
>>> https://docs.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwoUWdz6psy=
Eb456c3A/edit?usp=3Dsharing
>>>
>>> The first thing I am wondering about is whether the proposed outline
>>> =E2=80=9Cworks=E2=80=9D. Would you be willing to spend an hour thinking=
 through the outline
>>> and wondering how you would respond to it for Reliance? What questions =
are
>>> missing? Would another organization work better?
>>>
>>
>>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

--001a1134188cfb9023051331a5a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Dear Fred,

I read your document and I h=
ave some material that might be useful in the "Observations and Experi=
ments" part. On my Master thesis I compared DS-Lite, 464XLAT, MAP-E an=
d MAP-T, the results are available at:

The dissertation text is in Portuguese, but t=
here is a summary article in English available in the link as well.

If you want, I may assist on your proposed task.

Best regards,

--
Edw=
in Cordeiro, M.Sc. =C2=A0 =C2=A0 Network Architectures and Services
T: +49 89 289 18550 =C2=A0 =C2=A0 =C2=A0 Departm=
ent of Computer Science
=



On Wed, Apr 1, 2015 at 3:11 AM, Fred Baker (=
fred) <fred@cisco.com> wrote:=

Since they might b=
e among the early folks I would ask to write something, I asked Xing Li, Ak=
ira, and Suprita to comment specifically on the outline: =E2=80=9Cif you we=
re to write such a document, how would this outline work for you=E2=80=9D.<=
div>
Suprita replied as follows. I have changed the proposed =
outline in a manner similar to her suggestion.

On Mar 31, 2015, at 2:41 PM, suprita <suprita.nitw@gmail.com> wrote:

I tried to first re-write the "Outlined hierarchy" used =
=C2=A0and then make any modification to it, as per ease of answering them.=
=C2=A0
I did not have to do many changes to the one already used by you=
, with minor adjustments in naming convention and placements..
Experience Gathering : Heading

G=
eneral/Overview
	Majo=
r Motivation(s)
	v4 a=
s-a-service Requirements
		<=
/span>Exactly which v4 Service Types
Architecture and Methodology=

	Major Design Consid=
erations
	Regulatory =
Considerations
	Secur=
ity Considerations
	O=
perational Considerations
	<=
/span>End-User Experience Considerations
Observations and Experie=
nces
	Effects on End-=
User
	Effects on Inte=
rnal Staff
		Planning=
 & Design
		Imple=
mentation
		Operation=
s
	Effects on Busines=
s
Summary:=C2=A0Post-mortem Report
	Deviations from RFC's/Drafts/Standards
	Worked Well
	Did not work well


On=
 Wed, Apr 1, 2015 at 1:56 AM, suprita <suprita.nitw@gmail.com> wrote:
Dear Fred,

I am yet to apply newly le=
arnt skill from you of applying filters for the directly addressed e-mails =
:).
I will sure go through the doc in detail and comment.=C2=A0

Thank you,
Suprita
<=
div class=3D"gmail_extra">
On Tue, Mar 31, 20=
15 at 2:04 AM, Fred Baker (fred) <fred@cisc=
o.com> wrote:


> On Mar 30, 2015, at 12:50 PM, Fred Baker <fred@cisco.com=
> wrote:

>

> Over the weekend, we crowd-sourced a number of pretty good questions. =
I took the liberty, this morning, of reorganizing the text a bit. The "=
;list of technologies" and "list of questions" remain, but I=
 have added "possible (classes of) documents to be developed" and=
 a first cut at a proposed outline, with the questions from above pulled in=
 to make it clear what I might hope the section might comment on.

>

> Collecting comments and thoughts. I guarantee there is something we ha=
ven=E2=80=99t thought of (as I was reorganizing, several points popped out,=
 and I=E2=80=99m sure I=E2=80=99m not that smart).

>

>> https://docs=
.google.com/document/d/1ifDEkoypW43lgZJqh2paUDcMAwoUWdz6psyEb456c3A/edit?us=
p=3Dsharing




The first thing I am wondering about is whether the=
 proposed outline =E2=80=9Cworks=E2=80=9D. Would you be willing to spend an=
 hour thinking through the outline and wondering how you would respond to i=
t for Reliance? What questions are missing? Would another organization work=
 better?










______________________________=
_________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--001a1134188cfb9023051331a5a2--


From nobody Wed Apr  8 17:52: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 411571ACC87 for ; Wed,  8 Apr 2015 17:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.802
X-Spam-Level: ***
X-Spam-Status: No, score=3.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, 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 JkEj_kpsK7iH for ; Wed,  8 Apr 2015 17:52:20 -0700 (PDT)
Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09211ACC85 for ; Wed,  8 Apr 2015 17:52:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1428540739; bh=AKXitd5HVILgwbfcfjjt5Z749CsQYrM/WgSLQhmKi3M=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=cb34xcPXb25rNmV1ZPUolMjTNt1TKhA8hdE9rW/GtmIWxeyjF9QBLZkYBYmP6KXqyg7JLQx2qpWPdIv9qQFgg5eLUXCuROEOLqIY9OGCGVNe5RFJUp6xLdwg+p/ebxMGCkSY0pM90Uilut0mWPv24tf/mLZsRylf5hwze3N+uVRfki9t50oafoONo3pDC6CWKpvQLFt+CKBZcApgJv1TF3q8W2aMK2s7+LNpr4CgEb19ZDe0m3bgoUsk1uM4KJJqcthssPvzXFIGIpCKNGDGSIwyZil+yXv0Yv/msYlIBBGhBiTSlzmqcPMwQ9+bzRTYOzhI1u1Dh8bgE7+xF/uH0w==
Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 09 Apr 2015 00:52:19 -0000
Received: from [98.138.226.179] by nm40.bullet.mail.ne1.yahoo.com with NNFMP;  09 Apr 2015 00:49:25 -0000
Received: from [66.196.81.174] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 09 Apr 2015 00:49:25 -0000
Received: from [98.139.212.242] by tm20.bullet.mail.bf1.yahoo.com with NNFMP;  09 Apr 2015 00:49:25 -0000
Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 09 Apr 2015 00:49:25 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 69781.81677.bm@omp1051.mail.bf1.yahoo.com
X-YMail-OSG: NcDcBDgVM1m9p.H6TZvBsKlvEgbUFUS20Fg.cIJTBq4ZuFbHDhQiUiAkPJQd1OB V_lxL7WmQmg0tBITonYhlDFTHx8Z4i.UZ5M4DUDuHOs_CZoqbnt9wZhvAJ2jWUm9u6nA2.unuCED do.wwZWU4nhpp0kmKXrw_Ec9xwstpaXvuNyuHeFLwxhauVDP2HhNe5ABEJAwxtHRpHKmJN8N1rBG KAPYHc36F8IqCxvlU5tqQnM4cS8YzMncO21B4trDlZQdG4TQacsY8Qqm1hvmEMWJbg81sm83H7kn xCKxHJKvI9UL.wTJt7IN2JzVnzabuEEQtbxB7FG5tiPiclrOGZvkxT2khLiRYfiR48nS4vYjVgps EuqER18_QJyqE8lhMSx9N.KvkrNi1yGtaNpumHMjTKSIPaRgZdjaIgzdd2F9ksDC0GjIqyn7_Vl6 nQP9JYVgP0gCIEQkG1hvyADYWhHOT4TIpGLkkudaHu.Yfb0JXMDKpl4IqXnZepMIJZNPzGpva8Ih xDrBghDf3Q2LFkhRouEl3B0Wb5BYhkF1l2CfQTqyYMaGmY30cRtZrOro-
Received: by 66.196.80.125; Thu, 09 Apr 2015 00:49:24 +0000 
Date: Thu, 9 Apr 2015 00:49:21 +0000 (UTC)
From: Mark ZZZ Smith 
To: Philip Matthews ,  "Ackermann, Michael" ,  "Fred Baker (fred)" 
Message-ID: <2004183372.2937208.1428540561672.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <7DF32A06-80FA-461A-A387-DE55F1DB79DB@magma.ca>
References: <7DF32A06-80FA-461A-A387-DE55F1DB79DB@magma.ca>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_2937207_2073662507.1428540561669"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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: Thu, 09 Apr 2015 00:52:21 -0000

------=_Part_2937207_2073662507.1428540561669
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: Philip Matthews 
 To: "Ackermann, Michael" ; Fred Baker (fred) =20
Cc: v6ops list =20
 Sent: Wednesday, 8 April 2015, 11:10
 Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
  =20

On 2015-04-06, at 19:10 , Ackermann, Michael wrote:

> HI Fred
>=20
> This will be a most beneficial document for those of us contemplating IPv=
6 deployments.=C2=A0=20
>=20
> A couple questions:=20
>=C2=A0


>=20
> 2.=C2=A0 Section 2.2.1.=C2=A0 Most of the text in this section seems to s=
uggest that using link-locals for next hop addresses is the best approach.=
=C2=A0 But there are a couple situations where it is not.=C2=A0 And then at=
 the end it says "Today most operators use GUA's as next hop addresses".=C2=
=A0 =C2=A0 =C2=A0 As a neophyte reader I was uncertain what conclusion I sh=
ould draw?=C2=A0=20

That, despite the specs seeming to say that static-routes should use link-l=
ocal addresses, that in practice it can sometimes cause problems so most op=
erators use GUAs instead.
Most large providers are large corporations with many employees with varyin=
g skill sets. These corporations have established procedures that work for =
IPv4 and most employees try to apply these IPv4 procedures to IPv6. Anythin=
g that causes IPv6 to be different than IPv4 means special procedures must =
be developed and taught to employees. Using link-local addresses in static =
routes is a difference, so most large providers don't use them.=C2=A0 Thing=
s can be different at a smaller provider where differences can be handled m=
ore easily.


/ Perhaps that means there needs to be a bit more explanation of the value =
of using link-locals so people can more easily make a value judgement?
/ My understanding is that link-locals were chosen to be used as next-hop v=
alues are for two reasons (a) link-local prefixes are always present (as pe=
r RFC4291), unlike GUAs or ULAs and (b) they allow less disruptive phasing =
in and phasing out of GUA/ULA prefixes across a network as static or dynami=
c routing next-hops won't be impacted by GUA/ULA changes.=C2=A0
/ Regards,Mark

  
------=_Part_2937207_2073662507.1428540561669
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



   
 
 
   From: Philip Matthews <philip_matthews@magma.ca>=
;
 To: "Ackermann, Mich=
ael" <MAckermann@bcbsm.com>; Fred Baker (fred) <fred@cisco.com>=
 
Cc: v6ops list <v6=
ops@ietf.org> 
 Sent: Wednesday, 8 April 2015, 11:10
 =
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
=
  
 


On 2015-04-06, at 19:10 , Ackermann, Michael wrote:
=

> HI Fred
> 
> This will be a most beneficial document f=
or those of us contemplating IPv6 deployments.  
> 
> A co=
uple questions: 
> 

<snip>

> > 2.  Section 2.2.1.   Most of the text in this section seem=
s to suggest that using link-locals for next hop addresses is the best appr=
oach.   But there are a couple situations where it is not.   And =
then at the end it says "Today most operators use GUA's as next hop address=
es".      As a neophyte reader I was uncertain what conclusi=
on I should draw?  

That, despite the specs seeming to say that=
 static-routes should use link-local addresses, that in practice it can som=
etimes cause problems so most operators use GUAs instead.
Most large pro=
viders are large corporations with many employees with varying skill sets. =
These corporations have established procedures that work for IPv4 and most =
employees try to apply these IPv4 procedures to IPv6. Anything that causes =
IPv6 to be different than IPv4 means special procedures must be developed a=
nd taught to employees. Using link-local addresses in static routes is a di=
fference, so most large providers don't use them.   Things can be diff=
erent at a smaller provider where differences can be handled more easily.

/ Perhaps that means there needs to be a bit more explanation of =
the value of using link-locals so people can more easily make a value judge=
ment?

/ My understanding is that link-locals=
 were chosen to be used as next-hop values are for two reasons (a) link-loc=
al prefixes are always present (as per RFC4291), unlike GUAs or ULAs and (b=
) they allow less disruptive phasing in and phasing out of GUA/ULA prefixes=
 across a network as static or dynamic routing next-hops won't be impacted =
by GUA/ULA changes. 

/ Regards,
Mark


<snip>
 
   
------=_Part_2937207_2073662507.1428540561669--


From nobody Thu Apr  9 07:41: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 DDEF31A8729 for ; Thu,  9 Apr 2015 07:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgvEWbCzhEVr for ; Thu,  9 Apr 2015 07:41:34 -0700 (PDT)
Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 DE4AD1A8727 for ; Thu,  9 Apr 2015 07:41:25 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 1F621102620 for ; Thu,  9 Apr 2015 09:41:25 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 64D2E1334C0; Thu,  9 Apr 2015 09:41:24 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 16C9D2F5188; Thu,  9 Apr 2015 10:38:31 -0400 (EDT)
Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id 01FE52F51B7; Thu,  9 Apr 2015 10:38:31 -0400 (EDT)
Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([::1]) with mapi id 14.01.0438.000;  Thu, 9 Apr 2015 10:41:23 -0400
From: "Ackermann, Michael" 
To: Mark ZZZ Smith , Philip Matthews , "Fred Baker (fred)" 
Thread-Topic: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
Thread-Index: AdBwejVZflkIuUqSRyO7yHiQggoOUQBQBUQAADGQMIAAFEHyUA==
Date: Thu, 9 Apr 2015 14:41:16 +0000
Message-ID: <4FC37E442D05A748896589E468752CAA0CDAFE85@PWN401EA160.ent.corp.bcbsm.com>
References: <7DF32A06-80FA-461A-A387-DE55F1DB79DB@magma.ca> <2004183372.2937208.1428540561672.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <2004183372.2937208.1428540561672.JavaMail.yahoo@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.10.35]
Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0CDAFE85PWN401EA160entc_"
MIME-Version: 1.0
X-VPM-HOST: vmvpm01.z120.zixworks.com
X-VPM-GROUP-ID: 682d8942-ef13-4495-bac1-0cd2b13a7e45
X-VPM-MSG-ID: abb0128f-d9de-4854-a0ff-c73b4d27473d
X-VPM-ENC-REGIME: Plaintext
X-VPM-CERT-FLAG: 0
X-VPM-IS-HYBRID: 0
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 09 Apr 2015 14:41:38 -0000

--_000_4FC37E442D05A748896589E468752CAA0CDAFE85PWN401EA160entc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIGZvciB0aGUgZ29vZCBwb2ludHMgTWFyayENCg0KRG9jdW1lbnRpbmcgdGhlIHBy
b3MgYW5kIGNvbnMgb2YgdXNpbmcgbGluayBsb2NhbHMgYXMgbmV4dCBob3BzLCBzbyB0aGF0
IGluZm9ybWVkIGRlY2lzaW9ucyBjYW4gYmUgbWFkZSAoZXNwZWNpYWxseSBieSB0aG9zZSBw
ZXJoYXBzIGxlc3Mga25vd2xlZGdlYWJsZSBvbiBJUHY2KSwgIHdvdWxkIGJlIGEgZ3JlYXQg
YmVuZWZpdC4gICAgICAgTXkgb3JnYW5pemF0aW9uIGlzICBqdXN0IHN0YXJ0aW5nIHRvIHRl
c3QgdGhpcywgc28gSSB3b3VsZCBhcHByZWNpYXRlIGlucHV0IG9uIHRoaXMgZnJvbSB0aG9z
ZSB3aXRoIG1vcmUgYWN0dWFsLCBwcmFjdGljYWwgZXhwZXJpZW5jZXMsICBidXQgIGZyb20g
d2hhdCBJIGhhdmUgc2VlbiBzbyBmYXIsICB0aGUgbGluayBsb2NhbCBiZW5pZXMgd291bGQg
aW5jbHVkZToNCg0KDQoxLiAgICAgICBPbW5pcHJlc2VuY2UuDQoNCjIuICAgICAgIFN0YWJp
bGl0eSBhbmQgdW5hZmZlY3RlZCBieSBleHRlcm5hbCBldmVudHMuDQoNCjMuICAgICAgIE1v
cmUgU2VjdXJlDQoNClNvIHByZXR0eSBjb25zaXN0ZW50IHdpdGggd2hhdCB5b3Ugc2FpZC4N
Cg0KV2hhdCBJIGRvIG5vdCBrbm93IGlzIHdoYXQgdGhlIGRyYXdiYWNrcyB0byB1c2luZyBM
aW5rIExvY2FscyBmb3IgbmV4dCBob3AgbWlnaHQgYmU/DQpJIGFsc28gd29uZGVyIHdoZXRo
ZXIgdGhlIHByb3MgYW5kIGNvbnMgY2hhbmdlLCAgaWYgdGhlIGRldmljZSBpcyBhbiBlbmQg
aG9zdCwgdnMgYSBtaWRkbGUgYm94Pw0KRmluYWwgcmVsYXRlZCBxdWVzdGlvbiBpcyB3aGV0
aGVyIHRoaXMgc2l0dWF0aW9uIGlzIGFmZmVjdGVkIGJ5IHRoZSBjaG9pY2Ugb2Ygb3IgdGhl
IHByZXNlbmNlIG9mIGFueSByb3V0aW5nIHByb3RvY29scz8NCg0KVGhhbmtzIGFnYWluIQ0K
DQpNaWtlDQoNCkZyb206IE1hcmsgWlpaIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQHlh
aG9vLmNvbS5hdV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDgsIDIwMTUgODo0OSBQTQ0K
VG86IFBoaWxpcCBNYXR0aGV3czsgQWNrZXJtYW5uLCBNaWNoYWVsOyBGcmVkIEJha2VyIChm
cmVkKQ0KQ2M6IHY2b3BzIGxpc3QNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYUluIGZ0LWll
dGYtdjZvcHMtZGVzaWduLWNob2ljZXMgV0dMQw0KDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQpGcm9tOiBQaGlsaXAgTWF0dGhld3MgPHBoaWxpcF9tYXR0aGV3c0Bt
YWdtYS5jYTxtYWlsdG86cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPj4NClRvOiAiQWNrZXJt
YW5uLCBNaWNoYWVsIiA8TUFja2VybWFubkBiY2JzbS5jb208bWFpbHRvOk1BY2tlcm1hbm5A
YmNic20uY29tPj47IEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbTxtYWlsdG86
ZnJlZEBjaXNjby5jb20+Pg0KQ2M6IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPG1haWx0
bzp2Nm9wc0BpZXRmLm9yZz4+DQpTZW50OiBXZWRuZXNkYXksIDggQXByaWwgMjAxNSwgMTE6
MTANClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYUluIGZ0LWlldGYtdjZvcHMtZGVzaWduLWNo
b2ljZXMgV0dMQw0KDQoNCk9uIDIwMTUtMDQtMDYsIGF0IDE5OjEwICwgQWNrZXJtYW5uLCBN
aWNoYWVsIHdyb3RlOg0KDQo+IEhJIEZyZWQNCj4NCj4gVGhpcyB3aWxsIGJlIGEgbW9zdCBi
ZW5lZmljaWFsIGRvY3VtZW50IGZvciB0aG9zZSBvZiB1cyBjb250ZW1wbGF0aW5nIElQdjYg
ZGVwbG95bWVudHMuDQo+DQo+IEEgY291cGxlIHF1ZXN0aW9uczoNCj4NCg0KPHNuaXA+DQoN
Cj4NCj4gMi4gIFNlY3Rpb24gMi4yLjEuICBNb3N0IG9mIHRoZSB0ZXh0IGluIHRoaXMgc2Vj
dGlvbiBzZWVtcyB0byBzdWdnZXN0IHRoYXQgdXNpbmcgbGluay1sb2NhbHMgZm9yIG5leHQg
aG9wIGFkZHJlc3NlcyBpcyB0aGUgYmVzdCBhcHByb2FjaC4gIEJ1dCB0aGVyZSBhcmUgYSBj
b3VwbGUgc2l0dWF0aW9ucyB3aGVyZSBpdCBpcyBub3QuICBBbmQgdGhlbiBhdCB0aGUgZW5k
IGl0IHNheXMgIlRvZGF5IG1vc3Qgb3BlcmF0b3JzIHVzZSBHVUEncyBhcyBuZXh0IGhvcCBh
ZGRyZXNzZXMiLiAgICAgIEFzIGEgbmVvcGh5dGUgcmVhZGVyIEkgd2FzIHVuY2VydGFpbiB3
aGF0IGNvbmNsdXNpb24gSSBzaG91bGQgZHJhdz8NCg0KVGhhdCwgZGVzcGl0ZSB0aGUgc3Bl
Y3Mgc2VlbWluZyB0byBzYXkgdGhhdCBzdGF0aWMtcm91dGVzIHNob3VsZCB1c2UgbGluay1s
b2NhbCBhZGRyZXNzZXMsIHRoYXQgaW4gcHJhY3RpY2UgaXQgY2FuIHNvbWV0aW1lcyBjYXVz
ZSBwcm9ibGVtcyBzbyBtb3N0IG9wZXJhdG9ycyB1c2UgR1VBcyBpbnN0ZWFkLg0KTW9zdCBs
YXJnZSBwcm92aWRlcnMgYXJlIGxhcmdlIGNvcnBvcmF0aW9ucyB3aXRoIG1hbnkgZW1wbG95
ZWVzIHdpdGggdmFyeWluZyBza2lsbCBzZXRzLiBUaGVzZSBjb3Jwb3JhdGlvbnMgaGF2ZSBl
c3RhYmxpc2hlZCBwcm9jZWR1cmVzIHRoYXQgd29yayBmb3IgSVB2NCBhbmQgbW9zdCBlbXBs
b3llZXMgdHJ5IHRvIGFwcGx5IHRoZXNlIElQdjQgcHJvY2VkdXJlcyB0byBJUHY2LiBBbnl0
aGluZyB0aGF0IGNhdXNlcyBJUHY2IHRvIGJlIGRpZmZlcmVudCB0aGFuIElQdjQgbWVhbnMg
c3BlY2lhbCBwcm9jZWR1cmVzIG11c3QgYmUgZGV2ZWxvcGVkIGFuZCB0YXVnaHQgdG8gZW1w
bG95ZWVzLiBVc2luZyBsaW5rLWxvY2FsIGFkZHJlc3NlcyBpbiBzdGF0aWMgcm91dGVzIGlz
IGEgZGlmZmVyZW5jZSwgc28gbW9zdCBsYXJnZSBwcm92aWRlcnMgZG9uJ3QgdXNlIHRoZW0u
ICBUaGluZ3MgY2FuIGJlIGRpZmZlcmVudCBhdCBhIHNtYWxsZXIgcHJvdmlkZXIgd2hlcmUg
ZGlmZmVyZW5jZXMgY2FuIGJlIGhhbmRsZWQgbW9yZSBlYXNpbHkuDQoNCg0KLyBQZXJoYXBz
IHRoYXQgbWVhbnMgdGhlcmUgbmVlZHMgdG8gYmUgYSBiaXQgbW9yZSBleHBsYW5hdGlvbiBv
ZiB0aGUgdmFsdWUgb2YgdXNpbmcgbGluay1sb2NhbHMgc28gcGVvcGxlIGNhbiBtb3JlIGVh
c2lseSBtYWtlIGEgdmFsdWUganVkZ2VtZW50Pw0KDQovIE15IHVuZGVyc3RhbmRpbmcgaXMg
dGhhdCBsaW5rLWxvY2FscyB3ZXJlIGNob3NlbiB0byBiZSB1c2VkIGFzIG5leHQtaG9wIHZh
bHVlcyBhcmUgZm9yIHR3byByZWFzb25zIChhKSBsaW5rLWxvY2FsIHByZWZpeGVzIGFyZSBh
bHdheXMgcHJlc2VudCAoYXMgcGVyIFJGQzQyOTEpLCB1bmxpa2UgR1VBcyBvciBVTEFzIGFu
ZCAoYikgdGhleSBhbGxvdyBsZXNzIGRpc3J1cHRpdmUgcGhhc2luZyBpbiBhbmQgcGhhc2lu
ZyBvdXQgb2YgR1VBL1VMQSBwcmVmaXhlcyBhY3Jvc3MgYSBuZXR3b3JrIGFzIHN0YXRpYyBv
ciBkeW5hbWljIHJvdXRpbmcgbmV4dC1ob3BzIHdvbid0IGJlIGltcGFjdGVkIGJ5IEdVQS9V
TEEgY2hhbmdlcy4NCg0KLyBSZWdhcmRzLA0KTWFyaw0KDQoNCjxzbmlwPg0KCgpUaGUgaW5m
b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29u
ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu
ZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElm
IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v
dGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJp
YnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkg
dW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0
aG91dCBtYWtpbmcgYW55IGNvcGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBN
aWNoaWdhbiBhbmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2Zp
dCBjb3Jwb3JhdGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBD
cm9zcyBhbmQgQmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uCg==

--_000_4FC37E442D05A748896589E468752CAA0CDAFE85PWN401EA160entc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu
OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj
aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov
L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9
IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt
ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl
cmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJs
KCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K
d1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1
cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZl
dGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x
OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z
b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu
aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz
dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5
OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv
dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0
OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl
Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N
CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0OTQ4Nzk5OTE7DQoJbXNvLWxpc3QtdHlwZTpo
eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI3MDAxNjMyIDY3Njk4NzAzIDY3Njk4
NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4
NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph
bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl
dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K
CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz
dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy
aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv
d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0
b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3
MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGdvb2Qg
cG9pbnRzIE1hcmshPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5Eb2N1bWVudGluZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB1c2luZyBs
aW5rIGxvY2FscyBhcyBuZXh0IGhvcHMsIHNvIHRoYXQgaW5mb3JtZWQgZGVjaXNpb25zIGNh
biBiZSBtYWRlIChlc3BlY2lhbGx5IGJ5IHRob3NlIHBlcmhhcHMgbGVzcyBrbm93bGVkZ2Vh
YmxlIG9uIElQdjYpLCZuYnNwOw0KIHdvdWxkIGJlIGEgZ3JlYXQgYmVuZWZpdC4mbmJzcDsm
bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TXkgb3JnYW5pemF0aW9uIGlzICZuYnNw
O2p1c3Qgc3RhcnRpbmcgdG8gdGVzdCB0aGlzLCBzbyBJIHdvdWxkIGFwcHJlY2lhdGUgaW5w
dXQgb24gdGhpcyBmcm9tIHRob3NlIHdpdGggbW9yZSBhY3R1YWwsIHByYWN0aWNhbCBleHBl
cmllbmNlcywmbmJzcDsgYnV0ICZuYnNwO2Zyb20gd2hhdCBJIGhhdmUgc2VlbiBzbyBmYXIs
ICZuYnNwO3RoZSBsaW5rIGxvY2FsIGJlbmllcyB3b3VsZCBpbmNsdWRlOg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0
OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3Bh
biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+
PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbW5pcHJlc2Vu
Y2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw
aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+
PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w
cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3RhYmlsaXR5IGFuZCB1bmFmZmVjdGVkIGJ5
IGV4dGVybmFsIGV2ZW50cy4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47
bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl
Ij4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu
Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1v
cmUgU2VjdXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5TbyBwcmV0dHkgY29uc2lzdGVudCB3aXRoIHdoYXQgeW91IHNhaWQuDQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PldoYXQgSSBkbyBub3Qga25vdyBpcyB3aGF0IHRoZSBkcmF3YmFja3MgdG8gdXNpbmcgTGlu
ayBMb2NhbHMgZm9yIG5leHQgaG9wIG1pZ2h0IGJlPyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbHNvIHdvbmRlciB3aGV0aGVy
IHRoZSBwcm9zIGFuZCBjb25zIGNoYW5nZSwmbmJzcDsgaWYgdGhlIGRldmljZSBpcyBhbiBl
bmQgaG9zdCwgdnMgYSBtaWRkbGUgYm94PyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPkZpbmFsIHJlbGF0ZWQgcXVlc3Rpb24gaXMgd2hldGhlciB0aGlzIHNpdHVh
dGlvbiBpcyBhZmZlY3RlZCBieSB0aGUgY2hvaWNlIG9mIG9yIHRoZSBwcmVzZW5jZSBvZiBh
bnkgcm91dGluZyBwcm90b2NvbHM/Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBhZ2FpbiE8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1p
a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l
PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1hcmsgWlpaIFNt
aXRoIFttYWlsdG86bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdV0NCjxicj4NCjxiPlNlbnQ6
PC9iPiBXZWRuZXNkYXksIEFwcmlsIDA4LCAyMDE1IDg6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+
IFBoaWxpcCBNYXR0aGV3czsgQWNrZXJtYW5uLCBNaWNoYWVsOyBGcmVkIEJha2VyIChmcmVk
KTxicj4NCjxiPkNjOjwvYj4gdjZvcHMgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W3Y2b3BzXSBkcmFJbiBmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzIFdHTEM8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg1MzYxMDI5MDNfMTI4
MTYiPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg1MzYxMDI5MDNfMTI4MTUiPg0KPGRp
diBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg1MzYxMDI5MDNfMTI4MTQiPg0KPGRpdiBjbGFzcz0i
TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFj
a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRo
PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj
ayI+IFBoaWxpcCBNYXR0aGV3cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWxpcF9tYXR0aGV3
c0BtYWdtYS5jYSI+cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPC9hPiZndDs8YnI+DQo8Yj5U
bzo8L2I+ICZxdW90O0Fja2VybWFubiwgTWljaGFlbCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOk1BY2tlcm1hbm5AYmNic20uY29tIj5NQWNrZXJtYW5uQGJjYnNtLmNvbTwvYT4mZ3Q7
OyBGcmVkIEJha2VyIChmcmVkKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWRAY2lzY28uY29t
Ij5mcmVkQGNpc2NvLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzIGxpc3Qg
Jmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+
Jmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCA4IEFwcmlsIDIwMTUsIDExOjEw
PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYUluIGZ0LWlldGYtdjZvcHMt
ZGVzaWduLWNob2ljZXMgV0dMQzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg1MzYxMDI5
MDNfMTI4MTciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp
dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KT24gMjAxNS0wNC0wNiwgYXQgMTk6
MTAgLCBBY2tlcm1hbm4sIE1pY2hhZWwgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBISSBGcmVk
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgd2lsbCBiZSBhIG1vc3QgYmVuZWZpY2lhbCBk
b2N1bWVudCBmb3IgdGhvc2Ugb2YgdXMgY29udGVtcGxhdGluZyBJUHY2IGRlcGxveW1lbnRz
LiZuYnNwOw0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgY291cGxlIHF1ZXN0aW9uczogPGJy
Pg0KJmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i
eXVpXzNfMTZfMF8xXzE0Mjg1MzYxMDI5MDNfMTI4MTciPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KJmx0
O3NuaXAmZ3Q7PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIuJm5ic3A7IFNlY3Rpb24g
Mi4yLjEuJm5ic3A7IE1vc3Qgb2YgdGhlIHRleHQgaW4gdGhpcyBzZWN0aW9uIHNlZW1zIHRv
IHN1Z2dlc3QgdGhhdCB1c2luZyBsaW5rLWxvY2FscyBmb3IgbmV4dCBob3AgYWRkcmVzc2Vz
IGlzIHRoZSBiZXN0IGFwcHJvYWNoLiZuYnNwOyBCdXQgdGhlcmUgYXJlIGEgY291cGxlIHNp
dHVhdGlvbnMgd2hlcmUgaXQgaXMgbm90LiZuYnNwOyBBbmQgdGhlbiBhdCB0aGUgZW5kIGl0
IHNheXMgJnF1b3Q7VG9kYXkgbW9zdCBvcGVyYXRvcnMgdXNlIEdVQSdzIGFzIG5leHQNCiBo
b3AgYWRkcmVzc2VzJnF1b3Q7LiZuYnNwOyAmbmJzcDsgJm5ic3A7IEFzIGEgbmVvcGh5dGUg
cmVhZGVyIEkgd2FzIHVuY2VydGFpbiB3aGF0IGNvbmNsdXNpb24gSSBzaG91bGQgZHJhdz8m
bmJzcDsNCjxicj4NCjxicj4NClRoYXQsIGRlc3BpdGUgdGhlIHNwZWNzIHNlZW1pbmcgdG8g
c2F5IHRoYXQgc3RhdGljLXJvdXRlcyBzaG91bGQgdXNlIGxpbmstbG9jYWwgYWRkcmVzc2Vz
LCB0aGF0IGluIHByYWN0aWNlIGl0IGNhbiBzb21ldGltZXMgY2F1c2UgcHJvYmxlbXMgc28g
bW9zdCBvcGVyYXRvcnMgdXNlIEdVQXMgaW5zdGVhZC48YnI+DQpNb3N0IGxhcmdlIHByb3Zp
ZGVycyBhcmUgbGFyZ2UgY29ycG9yYXRpb25zIHdpdGggbWFueSBlbXBsb3llZXMgd2l0aCB2
YXJ5aW5nIHNraWxsIHNldHMuIFRoZXNlIGNvcnBvcmF0aW9ucyBoYXZlIGVzdGFibGlzaGVk
IHByb2NlZHVyZXMgdGhhdCB3b3JrIGZvciBJUHY0IGFuZCBtb3N0IGVtcGxveWVlcyB0cnkg
dG8gYXBwbHkgdGhlc2UgSVB2NCBwcm9jZWR1cmVzIHRvIElQdjYuIEFueXRoaW5nIHRoYXQg
Y2F1c2VzIElQdjYgdG8gYmUgZGlmZmVyZW50DQogdGhhbiBJUHY0IG1lYW5zIHNwZWNpYWwg
cHJvY2VkdXJlcyBtdXN0IGJlIGRldmVsb3BlZCBhbmQgdGF1Z2h0IHRvIGVtcGxveWVlcy4g
VXNpbmcgbGluay1sb2NhbCBhZGRyZXNzZXMgaW4gc3RhdGljIHJvdXRlcyBpcyBhIGRpZmZl
cmVuY2UsIHNvIG1vc3QgbGFyZ2UgcHJvdmlkZXJzIGRvbid0IHVzZSB0aGVtLiZuYnNwOyBU
aGluZ3MgY2FuIGJlIGRpZmZlcmVudCBhdCBhIHNtYWxsZXIgcHJvdmlkZXIgd2hlcmUgZGlm
ZmVyZW5jZXMgY2FuIGJlIGhhbmRsZWQNCiBtb3JlIGVhc2lseS48YnI+DQo8YnI+DQo8YnI+
DQovIFBlcmhhcHMgdGhhdCBtZWFucyB0aGVyZSBuZWVkcyB0byBiZSBhIGJpdCBtb3JlIGV4
cGxhbmF0aW9uIG9mIHRoZSB2YWx1ZSBvZiB1c2luZyBsaW5rLWxvY2FscyBzbyBwZW9wbGUg
Y2FuIG1vcmUgZWFzaWx5IG1ha2UgYSB2YWx1ZSBqdWRnZW1lbnQ/PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyODUzNjEwMjkwM18x
MjgxNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI4NTM2MTAyOTAzXzEyODE3Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si
Pi8gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGxpbmstbG9jYWxzIHdlcmUgY2hvc2VuIHRv
IGJlIHVzZWQgYXMgbmV4dC1ob3AgdmFsdWVzIGFyZSBmb3IgdHdvIHJlYXNvbnMgKGEpIGxp
bmstbG9jYWwgcHJlZml4ZXMgYXJlIGFsd2F5cyBwcmVzZW50IChhcyBwZXINCiBSRkM0Mjkx
KSwgdW5saWtlIEdVQXMgb3IgVUxBcyBhbmQgKGIpIHRoZXkgYWxsb3cgbGVzcyBkaXNydXB0
aXZlIHBoYXNpbmcgaW4gYW5kIHBoYXNpbmcgb3V0IG9mIEdVQS9VTEEgcHJlZml4ZXMgYWNy
b3NzIGEgbmV0d29yayBhcyBzdGF0aWMgb3IgZHluYW1pYyByb3V0aW5nIG5leHQtaG9wcyB3
b24ndCBiZSBpbXBhY3RlZCBieSBHVUEvVUxBIGNoYW5nZXMuJm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyODUzNjEwMjkw
M18xMjgxNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI4NTM2MTAyOTAzXzEyODE3Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh
Y2siPi8gUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9
Inl1aV8zXzE2XzBfMV8xNDI4NTM2MTAyOTAzXzEyODE3Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1hcms8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI4
NTM2MTAyOTAzXzEyODE3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg1MzYxMDI5MDNfMTI4MTci
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjpibGFjayI+PGJyPg0KJmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCgoKPEJSPgo8aHRtbD4KIDxwPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp
cyBjb21tdW5pY2F0aW9uIGlzIGhpZ2hseSBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVk
IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMg
Y29tbXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk
IHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywg
Y29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlv
biBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9u
aWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRl
bGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2luZyBhbnkgY29waWVzLjwv
cD4KIDxwPkJsdWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2Fy
ZSBOZXR3b3JrIG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBp
bmRlcGVuZGVudCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxk
IEFzc29jaWF0aW9uLjwvcD4KICA8L2h0bWw+Cgo=

--_000_4FC37E442D05A748896589E468752CAA0CDAFE85PWN401EA160entc_--


From nobody Thu Apr  9 08:20:37 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 152E71A8798; Thu,  9 Apr 2015 08:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.475
X-Spam-Level: 
X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, 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 BgvIX4mqVS8N; Thu,  9 Apr 2015 08:20:24 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86F1A8777; Thu,  9 Apr 2015 08:20:23 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,550,1422939600"; d="scan'208";a="851854562"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 09 Apr 2015 11:05:59 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 9 Apr 2015 11:20:22 -0400
From: "George, Wes" 
To: "Fred Baker (fred)" 
Date: Thu, 9 Apr 2015 11:20:26 -0400
Thread-Topic: [sunset4] [v6ops] IPv4 trajectory
Thread-Index: AdBy2LJ8cVZsi0zoS0KflxyLWDnfCQ==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: IPv6 Ops WG , "sunset4@ietf.org" 
Subject: Re: [v6ops] [sunset4]  IPv4 trajectory
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 Apr 2015 15:20:26 -0000

SSB0aGluayB5b3UgbWVhbiAiaXQgaXMgKm5vdCogZmVhc2libGUiIGluIDMuNA0KDQpHZW5lcmFs
bHksIEkgdGhpbmsgdXBkYXRlcyB0byB0aGUgdHJhbnNpdGlvbiBndWlkYW5jZSBhcmUgc29tZXdo
YXQgdXNlZnVsLA0KYXQgbGVhc3QgYWNrbm93bGVkZ2luZyB0aGF0IGR1ZSB0byB0aGUgbGltaXRl
ZCBhbW91bnQgb2YgSVB2NCBhZGRyZXNzDQpzcGFjZSBhdmFpbGFibGUsIHRoZSBub3Rpb24gb2Yg
Y29udGludWVkIHBhcmFsbGVsIHN1cHBvcnQgZm9yIElQdjQgc3VjaA0KdGhhdCB5b3UgY2FuIHBy
b3ZpZGUgdHJ1bHkgbmF0aXZlIGR1YWwtc3RhY2sgaXMgZ29pbmcgdG8gYmVjb21lDQppbmNyZWFz
aW5nbHkgZGlmZmljdWx0IHdpdGhvdXQgb25lIG9yIG1vcmUgbGlmZS1zdXBwb3J0IG9wdGlvbnMu
IFdlJ3JlIG5vdA0KaGVyZSB0byBqdWRnZSB0aGUgcHJlc2VuY2Ugb2YgdGhvc2UgbGlmZS1zdXBw
b3J0IG9wdGlvbnMgYXMgZ29vZCwgYmFkLCBvcg0KaW5kaWZmZXJlbnQgYXMgbXVjaCBhcyB3ZSBh
cmUgdG8gYWNrbm93bGVkZ2UgdGhhdCByZWFsaXR5Lg0KDQpJIGtub3cgdGhhdCBJIGhhdmUgZ2l2
ZW4gZ3VpZGFuY2UgaW4gcmV2aWV3cyBvZiBzZXZlcmFsIHJlY2VudCBkb2N1bWVudHMNCmFuZCBn
aXZlbiBvdGhlciBwcmVzZW50YXRpb25zIHRvIHNvY2lhbGl6ZSB0aGUgaWRlYSB0aGF0IElQdjYt
b25seSBpc24ndA0KYW4gYWxsLW9yLW5vdGhpbmcgdGhpbmcsIGFuZCB0aGF0IHNvbWUgc2Vydmlj
ZXMgYW5kIGRldmljZXMgY2FuIG1vdmUgdGhlcmUNCm11Y2ggcXVpY2tlciBmb3IgdmFyaW91cyBy
ZWFzb25zLCBzdWNoIHRoYXQgeW91IG1heSBlbmQgdXAgd2l0aCBpc2xhbmRzIG9yDQpjZXJ0YWlu
IHNlcnZpY2VzIHRoYXQgYXJlIG5vIGxvbmdlciBkZXBlbmRlbnQgb24gSVB2NCBsb25nIGJlZm9y
ZSB5b3UgY2FuDQp0cnVseSB0dXJuIGl0IG9mZiBjb21wbGV0ZWx5LiBJJ3ZlIGFsc28gZHJhd24g
dGhlIHBhcmFsbGVsIHRvIHRoZSBTTkEgdG8NCklQIHRyYW5zaXRpb24sIHdoZXJlIHBlb3BsZSBp
bnN0YWxsZWQgZ2F0ZXdheXMgdGhhdCBhbGxvd2VkIHRoZSBwb3J0aW9uIG9mDQp0aGUgbmV0d29y
ayB0aGF0IHN1cHBvcnRlZCBsZWdhY3kgU05BIHRvIGJlIHZlcnkgc21hbGwgKGkuZS4gUmlnaHQg
aW4NCmZyb250IG9mIHRoZSBvZmZlbmRpbmcgbWFpbmZyYW1lKSBhbmQgdGhlIHJlc3Qgb2YgdGhl
IG5ldHdvcmssIGluY2x1ZGluZw0KYWxsIHJlbW90ZSBob3N0cyB0cmFuc2l0aW9uIHRvIElQLiBJ
IHNlZSBhIHNpbWlsYXIgdGhpbmcgaGFwcGVuaW5nIHdpdGgNCnNvbWUgbGVnYWN5IElQdjQtb25s
eSB0aGluZ3MsIHdoZXJlIGEgc3BlY2lmaWMgQUxHIGlzIGRlcGxveWVkIHRvIGVuYWJsZQ0KaXQg
dG8gc3BlYWsgSVB2NiBzbyB0aGF0IHlvdSBjYW4gaGF2ZSBJUHY2LW9ubHkgaG9zdHMgYWNjZXNz
IGl0IHdpdGhvdXQNCmhhdmluZyB0byBkbyB3aWRlciBJUHY2PC0+IElQdjQgdHJhbnNpdGlvbiBv
ciBkZXBsb3kgSVB2NCB0byBhIGJ1bmNoIG9mDQpob3N0cyBzb2xlbHkgdG8gc3VwcG9ydCB0aGF0
IGFwcGxpY2F0aW9uLg0KDQpUaGF0IHNhaWQsIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgZHJh
ZnQgaGFzIGEgbG90IG5ldyB0byBzYXkgd2hlbg0KY29uc2lkZXJlZCB3aXRoIHJlY2VudCBkb2N1
bWVudHMgbGlrZSBFbnRlcnByaXNlIEluY3JlbWVudGFsICg3MzgxKSwgYW5kIEkNCnRoaW5rIGl0
J2QgYmUgbW9yZSB1c2VmdWwgdG8gY29uc2lkZXIgc29tZXRoaW5nIHRoYXQgaGFzIG1vcmUgbGlt
aXRlZA0Kc2NvcGUsIGFuZCBvbmx5IGRpc2N1c3NlcyB0aGUgdHJhbnNpdGlvbiB0byBJUHY2LW9u
bHkgaW4gZ3JlYXRlciBkZXRhaWwuDQoNClRoYW5rcywNCg0KV2VzDQoNCkFueXRoaW5nIGJlbG93
IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwg
SQ0KaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQoNClRoaXMgRS1tYWls
IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxl
IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRp
YWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJs
ZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp
dmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90
IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5v
dGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3Ig
YWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVu
dHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3
ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v
dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9y
aWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K


From nobody Thu Apr  9 08:32:41 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 D3F631A8825 for ; Thu,  9 Apr 2015 08:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TC0hp_cFTfet for ; Thu,  9 Apr 2015 08:32:37 -0700 (PDT)
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 97F641A883F for ; Thu,  9 Apr 2015 08:32:36 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t39FWSBU016279 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 16:32:28 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org
Message-ID: <55269B8C.7060703@foobar.org>
Date: Thu, 09 Apr 2015 16:32:28 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Ackermann, Michael" , Mark ZZZ Smith , Philip Matthews , "Fred Baker (fred)" 
References: <7DF32A06-80FA-461A-A387-DE55F1DB79DB@magma.ca> <2004183372.2937208.1428540561672.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDAFE85@PWN401EA160.ent.corp.bcbsm.com>
In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDAFE85@PWN401EA160.ent.corp.bcbsm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 09 Apr 2015 15:32:40 -0000

On 09/04/2015 15:41, Ackermann, Michael wrote:
> Documenting the pros and cons of using link locals as next hops, so that
> informed decisions can be made (especially by those perhaps less
> knowledgeable on IPv6),  would be a great benefit.       My organization is
>  just starting to test this, so I would appreciate input on this from those
> with more actual, practical experiences,  but  from what I have seen so
> far,  the link local benies would include:
> 
> 1.       Omnipresence.
> 2.       Stability and unaffected by external events.   
> 3.       More Secure
>
> So pretty consistent with what you said.
> 
> What I do not know is what the drawbacks to using Link Locals for next hop
> might be?      

Large-scale provider networks would normally use a GUA as a next-hop for
the bgp prefix and set it to be the address of the PE device which
originated the prefix.  This allows prefix information to be carried in BGP
with NH reachability handled by the IGP.  I.e. IGP is used purely for
loopbacks and iBGP is used for everything else.  This avoids a large number
of troublesome design and scaling problems on many networks.

As a service provider network operator, I would go some lengths to avoid
using link-locals as NH addresses.  They provide no particular advantage
that I'm interested in and have a bunch of serious disadvantages, of which
the above is the main one.  The other main one is that they cause massive
fail when it comes to debugging problems.

With regard to the features that you listed:

- link-local addresses are not omnipresent, even if they are a mandatory
part of the protocol.  Personally, I prefer to disable them if there is an
option to do so.  Obviously this does not work if you're running protocols
which require them (e.g. ospf).

- "Stability and unaffected by external events".  The only stable address
on a router is a loopback.  MAC addresses can change due to e.g. software
upgrades.

- "more secure" is a statement of opinion which lacks context.  They're
unreachable if you're off-link, and if there is a requirement to consider
this as a security feature, infrastructure ACLs could equally be
implemented to give GUA addressing an equivalent level of security.

Nick


From nobody Thu Apr  9 08:43: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 992431B2DD9 for ; Thu,  9 Apr 2015 08:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nm0xxmQ99dXh for ; Thu,  9 Apr 2015 08:43:18 -0700 (PDT)
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 060251B2DD8 for ; Thu,  9 Apr 2015 08:43:17 -0700 (PDT)
X-Envelope-To: 
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:0:0:0:110]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t39FhFDT016489 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Apr 2015 16:43:16 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:110] claimed to be cupcake.foobar.org
Message-ID: <55269E13.9060803@foobar.org>
Date: Thu, 09 Apr 2015 16:43:15 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: v6ops@ietf.org
References: <7DF32A06-80FA-461A-A387-DE55F1DB79DB@magma.ca> <2004183372.2937208.1428540561672.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDAFE85@PWN401EA160.ent.corp.bcbsm.com> <55269B8C.7060703@foobar.org>
In-Reply-To: <55269B8C.7060703@foobar.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 09 Apr 2015 15:43:19 -0000

On 09/04/2015 16:32, Nick Hilliard wrote:
> Large-scale provider networks would normally use a GUA as a next-hop for
> the bgp prefix and set it to be the address of the PE device which
> originated the prefix.

I should qualify this a bit better: large scale providers running native
ipv6 will do this.  Many large scale providers will run ipv6 on mpls/6pe,
where the bgp NH IP is the ipv4 identifier address of the PE.

Nick


From nobody Thu Apr  9 08:58:52 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 BBACD1B2DAC for ; Thu,  9 Apr 2015 08:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVEg-AbcfIpq for ; Thu,  9 Apr 2015 08:58:47 -0700 (PDT)
Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 F22971B2DA1 for ; Thu,  9 Apr 2015 08:58:46 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id C5650282095 for ; Thu,  9 Apr 2015 10:58:45 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 3154328200D; Thu,  9 Apr 2015 10:58:45 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id ADDEB2F51AA; Thu,  9 Apr 2015 11:55:51 -0400 (EDT)
Received: from pwn401ea105.ent.corp.bcbsm.com (unknown [10.64.102.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id A03CE2F51A2; Thu,  9 Apr 2015 11:55:51 -0400 (EDT)
Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Thu, 9 Apr 2015 11:58:44 -0400
From: "Ackermann, Michael" 
To: Nick Hilliard , Mark ZZZ Smith , Philip Matthews , "Fred Baker (fred)" 
Thread-Topic: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
Thread-Index: AdBwejVZflkIuUqSRyO7yHiQggoOUQBQBUQAADGQMIAAFEHyUAAKlbwAAAe2V4A=
Date: Thu, 9 Apr 2015 15:58:36 +0000
Message-ID: <4FC37E442D05A748896589E468752CAA0CDB016B@PWN401EA160.ent.corp.bcbsm.com>
References: <7DF32A06-80FA-461A-A387-DE55F1DB79DB@magma.ca> <2004183372.2937208.1428540561672.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDAFE85@PWN401EA160.ent.corp.bcbsm.com> <55269B8C.7060703@foobar.org>
In-Reply-To: <55269B8C.7060703@foobar.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.10.35]
x-tm-as-product-ver: SMEX-10.2.0.3262-7.500.1018-21460.005
x-tm-as-result: No--51.690000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-VPM-HOST: vmvpm02.z120.zixworks.com
X-VPM-GROUP-ID: 419f5088-7f8e-4a35-9abc-cb7a9f6bd502
X-VPM-MSG-ID: 92e91de6-89e3-440b-939d-a516d3cafad4
X-VPM-ENC-REGIME: Plaintext
X-VPM-CERT-FLAG: 0
X-VPM-IS-HYBRID: 0
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 09 Apr 2015 15:58:51 -0000

Makes sense.   I can see where your BGP set up would be compelling. =20

One of my questions was if the Link Local Pros and Cons would be different =
for End Hosts vs Middle Boxes. =20
Your comments make me think that it may be good for End Hosts, but not so =
much Middle Boxes,  in particular large scale provider networks. =20

You mention that you remove Link Locals wherever possible.    On what =
platforms is this possible without removing most of IPv6?    Does this =
cause issues with intrinsic functions such as NDP, etc.? =20

Thanks.=20

Mike  =20

-----Original Message-----
From: Nick Hilliard =5Bmailto:nick=40foobar.org=5D=20
Sent: Thursday, April 09, 2015 11:32 AM
To: Ackermann, Michael; Mark ZZZ Smith; Philip Matthews; Fred Baker (fred)
Cc: v6ops list
Subject: Re: =5Bv6ops=5D draIn ft-ietf-v6ops-design-choices WGLC

On 09/04/2015 15:41, Ackermann, Michael wrote:
> Documenting the pros and cons of using link locals as next hops, so=20
> that informed decisions can be made (especially by those perhaps less
> knowledgeable on IPv6),  would be a great benefit.       My organization =
is
>  just starting to test this, so I would appreciate input on this from=20
> those with more actual, practical experiences,  but  from what I have=20
> seen so far,  the link local benies would include:
>=20
> 1.       Omnipresence.
> 2.       Stability and unaffected by external events.  =20
> 3.       More Secure
>
> So pretty consistent with what you said.
>=20
> What I do not know is what the drawbacks to using Link Locals for next hop
> might be?     =20

Large-scale provider networks would normally use a GUA as a next-hop for =
the bgp prefix and set it to be the address of the PE device which =
originated the prefix.  This allows prefix information to be carried in =
BGP with NH reachability handled by the IGP.  I.e. IGP is used purely for =
loopbacks and iBGP is used for everything else.  This avoids a large =
number of troublesome design and scaling problems on many networks.

As a service provider network operator, I would go some lengths to avoid =
using link-locals as NH addresses.  They provide no particular advantage =
that I'm interested in and have a bunch of serious disadvantages, of which =
the above is the main one.  The other main one is that they cause massive =
fail when it comes to debugging problems.

With regard to the features that you listed:

- link-local addresses are not omnipresent, even if they are a mandatory =
part of the protocol.  Personally, I prefer to disable them if there is an =
option to do so.  Obviously this does not work if you're running protocols =
which require them (e.g. ospf).

- =22Stability and unaffected by external events=22.  The only stable =
address on a router is a loopback.  MAC addresses can change due to e.g. =
software upgrades.

- =22more secure=22 is a statement of opinion which lacks context.  =
They're unreachable if you're off-link, and if there is a requirement to =
consider this as a security feature, infrastructure ACLs could equally be =
implemented to give GUA addressing an equivalent level of security.

Nick



The information contained in this communication is highly confidential and =
is intended solely for the use of the individual(s) to whom this =
communication is directed. If you are not the intended recipient, you are =
hereby notified that any viewing, copying, disclosure or distribution of =
this information is prohibited. Please notify the sender, by electronic =
mail or telephone, of any unintended receipt and delete the original =
message without making any copies.
=20
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are =
nonprofit corporations and independent licensees of the Blue Cross and =
Blue Shield Association.


From nobody Thu Apr  9 13:46: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 5A8B41B32B8 for ; Thu,  9 Apr 2015 13:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwGOx6EKa7_U for ; Thu,  9 Apr 2015 13:46:54 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 DA59A1B3252 for ; Thu,  9 Apr 2015 13:45:29 -0700 (PDT)
Received: by paboj16 with SMTP id oj16so161097558pab.0 for ; Thu, 09 Apr 2015 13:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VO1sqUI62i2SWSsH2rMYIbSNLIOJSPRXWV9QYkw7j5I=; b=QQ1QKivanYZjG5R8KYsLsFPwNRCVDzQEPUcTQX0hlRZ3WzC6cX2xq/ycQg0KZgtFKz mnrxVB/+PUhA9VUVrXK3nWRLHv/eoGtPLDoen5zzOxXNoMWMbh8XsKWdGidxc6hDabtD C3M5Q2BYYRnjc7dCoFwFCmCDylKb89hJemi55fpI8Us19E1Qxf/3937maIwxd9+GYC3y n0oq7QkiD3D54AFud3MeptBs7BLT5Lmek0P1yw84+Uv7kxWxy3W3dLmn1k8cxK9ibA6K qcWuihyI9oQmPe527+U3tzjzRybrx2yDrhq/TJK3AN70eJbN3pvZs/dQmEhvXWM3h62M a2fA==
X-Received: by 10.66.172.4 with SMTP id ay4mr60048195pac.157.1428612329379; Thu, 09 Apr 2015 13:45:29 -0700 (PDT)
Received: from ?IPv6:2406:e007:65de:1:28cc:dc4c:9703:6781? ([2406:e007:65de:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id j14sm15229483pbq.29.2015.04.09.13.45.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 13:45:28 -0700 (PDT)
Message-ID: <5526E4ED.3020405@gmail.com>
Date: Fri, 10 Apr 2015 08:45:33 +1200
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.6.0
MIME-Version: 1.0
To: Gert Doering ,  Alexandru Petrescu 
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com> <20150407123653.GS54385@Space.Net>
In-Reply-To: <20150407123653.GS54385@Space.Net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 20:46:56 -0000

On 08/04/2015 00:36, Gert Doering wrote:
> Hi,
> 
> On Tue, Apr 07, 2015 at 12:06:39PM +0200, Alexandru Petrescu wrote:
>> This begs a question about particular hardware which may not distinguish
>> types, and thus force others to drop-all RHs, regardless of their type -
>> what is that hardware?

I don't see which word is hard to understand in "Packets containing
standardised and undeprecated Routing Headers SHOULD be forwarded by
default." That's the IETF standards requirement, and SHOULD means that
"there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."

Operators are adult enough to do the right thing, but for that to work,
products need to be properly designed.

     Brian

> 
> "Hardware+Software".  My current beef is Cisco IOS XR on ASR9001, which
> has hardware capable of doing about anything, and software that missed that
> particular call...
> 
> (Of course there's 6500/Sup720, which has hardware not capable of doing
> any EH header filtering, but that is *old* stuff and not particularily
> relevant here)
> 
> Gert Doering
>         -- NetMaster
> 


From nobody Thu Apr  9 14:01: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 9751C1B32E5 for ; Thu,  9 Apr 2015 14:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47-MkP3EfXEg for ; Thu,  9 Apr 2015 14:01:42 -0700 (PDT)
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 302441B32E6 for ; Thu,  9 Apr 2015 14:01:41 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local ([IPv6:2001:4d68:2002:100:0:0:0:110]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t39L1XPt022673 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 22:01:33 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:110] claimed to be cupcake.local
Message-ID: <5526E8AD.2090201@foobar.org>
Date: Thu, 09 Apr 2015 22:01:33 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Ackermann, Michael" , Mark ZZZ Smith , Philip Matthews , "Fred Baker (fred)" 
References: <7DF32A06-80FA-461A-A387-DE55F1DB79DB@magma.ca> <2004183372.2937208.1428540561672.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDAFE85@PWN401EA160.ent.corp.bcbsm.com> <55269B8C.7060703@foobar.org> <4FC37E442D05A748896589E468752CAA0CDB016B@PWN401EA160.ent.corp.bcbsm.com>
In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDB016B@PWN401EA160.ent.corp.bcbsm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 09 Apr 2015 21:01:48 -0000

On 09/04/2015 16:58, Ackermann, Michael wrote:
> Makes sense.   I can see where your BGP set up would be compelling.
> 
> One of my questions was if the Link Local Pros and Cons would be
> different for End Hosts vs Middle Boxes. Your comments make me think
> that it may be good for End Hosts, but not so much Middle Boxes,  in
> particular large scale provider networks.
> 
> You mention that you remove Link Locals wherever possible.    On what
> platforms is this possible without removing most of IPv6?    Does this
> cause issues with intrinsic functions such as NDP, etc.?

link-locals are necessary on end-hosts due to autoconfig requirements.
Outside this, my use cases tend to be statically configured servers or else
router link addressing.  Neither of these situations particularly need
link-locals.  NDP works fine with GUAs.  Other protocols associated with
autoconfig break (e.g. RA, DAD, etc), but these aren't relevant.

To disable link-locals on a cisco router, use "no ipv6 enable" on your
interface.  It works fine if you don't need it.

Nick


From nobody Thu Apr  9 14:07: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 B7B151B32D0 for ; Thu,  9 Apr 2015 14:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 M9876mOH6bDV for ; Thu,  9 Apr 2015 14:07:32 -0700 (PDT)
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 AE6211B32BE for ; Thu,  9 Apr 2015 14:07:31 -0700 (PDT)
X-Envelope-To: 
Received: from cupcake.local ([IPv6:2001:4d68:2002:100:0:0:0:110]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t39L7SCg022791 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Apr 2015 22:07:29 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:110] claimed to be cupcake.local
Message-ID: <5526EA10.7040804@foobar.org>
Date: Thu, 09 Apr 2015 22:07:28 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: v6ops@ietf.org
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com> <20150407123653.GS54385@Space.Net> <5526E4ED.3020405@gmail.com>
In-Reply-To: <5526E4ED.3020405@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 21:07:33 -0000

On 09/04/2015 21:45, Brian E Carpenter wrote:
> Operators are adult enough to do the right thing, but for that to work,
> products need to be properly designed.

products are designed to a budget and a performance spec.  There's no point
in building a router which will inspect 65536 byte packets for EH chains if
it's too expensive for anyone to buy, or if it trashes performance by
passing packets with headers that big.  There is always a
cost/speed/features compromise.

Nick


From nobody Thu Apr  9 15:43: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 61FB41B34CF for ; Thu,  9 Apr 2015 15:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level: 
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 x4TXpkzV6jxv for ; Thu,  9 Apr 2015 15:43:07 -0700 (PDT)
Received: from nm37-vm1.bullet.mail.bf1.yahoo.com (nm37-vm1.bullet.mail.bf1.yahoo.com [72.30.238.201]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2294B1B34CD for ; Thu,  9 Apr 2015 15:43:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1428619385; bh=82V44V67gZjh1QNmsFKn0EbwH44V6SwBtOccNHAkigs=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=LqlRhKfvsPIGwheOA4L/J55JZq0/y0hrJXoQcEwlu4VnV7M9RX/UHInaPQ4RGNac3zEgaz7q64yjMQBzj3PYYerQYNAMXI2bzfogM9l5VWjW5HI/CZVuP/Kl0aMCeLq5pFVVGPEbMUtewTUTKkmqjjOdnDrXDjLqRqXbypBuFOZxhzU1WE47l7oJyyFdCpOR9r8SKvh1Ao1o5xxfpyNgfFCdBGIRaQNpGqsLY5246twDrvn4nWzYjW9REF6EvQGPjWR8cTAIwCmid/nALRsFHLmOaGfH3q/01/FWXW9a0Br6Gdhtke+6522Rs6TYPEuR4pjkZ9h7JYJwbVErIjXSuQ==
Received: from [66.196.81.173] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 09 Apr 2015 22:43:05 -0000
Received: from [98.139.212.231] by tm19.bullet.mail.bf1.yahoo.com with NNFMP;  09 Apr 2015 22:43:05 -0000
Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 09 Apr 2015 22:43:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 806360.55986.bm@omp1040.mail.bf1.yahoo.com
X-YMail-OSG: z7IIuo0VM1lW0U.kmlMBz8vYajEJLoqZvh6xQKcFb28.KhyFMFzcCMikGlT1hQW YPQ25VDAq0hgec19m4ZGO5_o_kL6sn99rcmfxUUJgHAsepXUNWFCp3UL3GCKFOC6ElP_OXc1MFMc DUiqRdp7W8c4.L8LiefTWlyz2lFkEwMf385t0_UDlpNpr3GO_bSX5RFSFYXWt7_1NeYSLa0.Wwj4 Z1iIpPW7Q2Ud.2tWLIAsnJglepirblsaOEixmDgWEGqOYNvok_ORabvm19QAYBRuYM9DtdnPALuE ac1XrPISZYBCEKxTP7k71q0YRfdxh4ushl7S.kk7.TMOPkRyE2Mh5EAidMl7pfxX19GsmtkmgRa_ OBWIF6kUQLNdSUXltsZMvpB6ZT5wcQyCQOX5bokmbMPkmtq828LcphsLz0O3wU1AqHxxLDJ1HIVA PQZPobAi3LVyFrhoFD7RF15L6yao5GJ63LQ4yrwwn8SkVBUeNJnRNfG.SUfnpam3qGiqYnU3J3Z9 Ar2yIGu1WRLTxB6wc8VpK46ak4mSnzLHQBvlUqxfF
Received: by 76.13.26.79; Thu, 09 Apr 2015 22:43:05 +0000 
Date: Thu, 9 Apr 2015 22:42:18 +0000 (UTC)
From: Mark ZZZ Smith 
To: Nick Hilliard ,  "Ackermann, Michael" ,  Philip Matthews ,  "Fred Baker (fred)" 
Message-ID: <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <5526E8AD.2090201@foobar.org>
References: <5526E8AD.2090201@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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: Thu, 09 Apr 2015 22:43:08 -0000

I think it is worth pointing out that Nick's use cases are or are probably Internet Exchange ones, where both he and his customers are highly technically competent. The mechanisms he's disabling by disabling link-locals e.g., DAD, are ones that in an IX environment are in effect provided by thorough attention to detail in both administration and manual configuration, hence the "(e.g. RA, DAD, etc), but these aren't relevant."

I see the target for this draft to be more general cases, where there is less time or resources to spend on providing manual equivalents to these automated protocols that use link-locals.

(One particular bad incident in my past of where there were 5 hosts with duplicate IPv4 addresses pre-IPv4 DAD makes me never want to see DAD become optional again.)


----- Original Message -----
From: Nick Hilliard 
To: "Ackermann, Michael" ; Mark ZZZ Smith ; Philip Matthews ; Fred Baker (fred) 
Cc: v6ops list 
Sent: Friday, 10 April 2015, 7:01
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC

On 09/04/2015 16:58, Ackermann, Michael wrote:
> Makes sense.   I can see where your BGP set up would be compelling.
> 
> One of my questions was if the Link Local Pros and Cons would be
> different for End Hosts vs Middle Boxes. Your comments make me think
> that it may be good for End Hosts, but not so much Middle Boxes,  in
> particular large scale provider networks.
> 
> You mention that you remove Link Locals wherever possible.    On what
> platforms is this possible without removing most of IPv6?    Does this
> cause issues with intrinsic functions such as NDP, etc.?

link-locals are necessary on end-hosts due to autoconfig requirements.
Outside this, my use cases tend to be statically configured servers or else
router link addressing.  Neither of these situations particularly need
link-locals.  NDP works fine with GUAs.  Other protocols associated with
autoconfig break (e.g. RA, DAD, etc), but these aren't relevant.

To disable link-locals on a cisco router, use "no ipv6 enable" on your
interface.  It works fine if you don't need it.


Nick


From nobody Thu Apr  9 16:58:40 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 38F551A92B8 for ; Thu,  9 Apr 2015 16:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a55wybtUaA9z for ; Thu,  9 Apr 2015 16:58:37 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (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 430311A92B5 for ; Thu,  9 Apr 2015 16:58:37 -0700 (PDT)
Received: by pddn5 with SMTP id n5so3592597pdd.2 for ; Thu, 09 Apr 2015 16:58:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QoYx3uQsLMZkEFd84UZAgeCZLBWnkt4FGShAi76yrPA=; b=YVgLMmOViPNGss6rGINW5sFA2RdqllJ0KLNPDBqqg40pmh0mm7OOsnV4E1+XGeA5Ha yu0YPx2yUpkF1+zEbHSNFea0CG/acyYJJIb1GCQqFq5l6fbgXKTxsws41qcvP19bwv8j 7qMi81icIzjIqQp8QfUpNa2LKfOeB931MS9WQgf2NWT7OPIMx2C68mSBRnC2igoh0wrE RWGFuO6h4ikd/V3X1s5SB+eYQDqlSTleSqv8ibQ/S6o3ABP1J0Mi1SKPYOilRNc2kAlD sI5yEhQ5vzIxXLCsZ6iu1A+UqhuWLSjSm2cc77n3vdTqLrMOAfTL7l9tsheT2wqOG253 kU1A==
X-Received: by 10.70.21.227 with SMTP id y3mr59315044pde.101.1428623917035; Thu, 09 Apr 2015 16:58:37 -0700 (PDT)
Received: from ?IPv6:2406:e007:65de:1:28cc:dc4c:9703:6781? ([2406:e007:65de:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id j2sm167349pdn.44.2015.04.09.16.58.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 16:58:35 -0700 (PDT)
Message-ID: <55271231.1010405@gmail.com>
Date: Fri, 10 Apr 2015 11:58:41 +1200
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.6.0
MIME-Version: 1.0
To: Nick Hilliard , v6ops@ietf.org
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com> <20150407123653.GS54385@Space.Net> <5526E4ED.3020405@gmail.com> <5526EA10.7040804@foobar.org>
In-Reply-To: <5526EA10.7040804@foobar.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 23:58:39 -0000

On 10/04/2015 09:07, Nick Hilliard wrote:
> On 09/04/2015 21:45, Brian E Carpenter wrote:
>> Operators are adult enough to do the right thing, but for that to work,
>> products need to be properly designed.
> 
> products are designed to a budget and a performance spec.  There's no point
> in building a router which will inspect 65536 byte packets for EH chains if
> it's too expensive for anyone to buy, or if it trashes performance by
> passing packets with headers that big.  There is always a
> cost/speed/features compromise.

Of course. But we already changed the standard to limit this problem:

http://tools.ietf.org/html/rfc7112

    Brian


From nobody Fri Apr 10 08:42: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 B5B351A1BDD for ; Fri, 10 Apr 2015 08:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP6ZkgiibqOI for ; Fri, 10 Apr 2015 08:42:28 -0700 (PDT)
Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 12F401A1BED for ; Fri, 10 Apr 2015 08:42:25 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 795D6102D5C for ; Fri, 10 Apr 2015 10:42:24 -0500 (CDT)
Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id BF0161335B0; Fri, 10 Apr 2015 10:42:23 -0500 (CDT)
Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 983054FF652; Fri, 10 Apr 2015 11:38:16 -0400 (EDT)
Received: from pwn401ea105.ent.corp.bcbsm.com (unknown [10.64.102.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva1.bcbsm.com (Postfix) with ESMTP id 88D744FF5E8; Fri, 10 Apr 2015 11:38:16 -0400 (EDT)
Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Fri, 10 Apr 2015 11:42:22 -0400
From: "Ackermann, Michael" 
To: Mark ZZZ Smith , Nick Hilliard , Philip Matthews , "Fred Baker (fred)" 
Thread-Topic: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
Thread-Index: AdBwejVZflkIuUqSRyO7yHiQggoOUQBQBUQAADGQMIAAFEHyUAAKlbwAAAe2V4AAA8flgAADhMYAABpqfEA=
Date: Fri, 10 Apr 2015 15:42:12 +0000
Message-ID: <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com>
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.10.35]
x-tm-as-product-ver: SMEX-10.2.0.3262-7.500.1018-21464.005
x-tm-as-result: No--35.853600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-VPM-HOST: vmvpm01.z120.zixworks.com
X-VPM-GROUP-ID: cc05dced-a3f9-4195-b2eb-6c931eac1978
X-VPM-MSG-ID: 45e865b1-6771-4fb0-b105-93f10d67c95f
X-VPM-ENC-REGIME: Plaintext
X-VPM-CERT-FLAG: 0
X-VPM-IS-HYBRID: 0
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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: Fri, 10 Apr 2015 15:42:33 -0000

SXQgc2VlbXMgdGhhdCB0aGUgYWR2aWNlIHRvIHVzZSBMaW5rIExvY2FscyBmb3IgbmV4dCBo
b3AgKG9yIG1heWJlIGV2ZW4gdG8gdXNlIHRoZW0gYXQgYWxsPyksICBpcyBzaXR1YXRpb25h
bGx5IGRlcGVuZGVudC4gICAgICAgTWF5IGJlIGJlbmVmaWNpYWwgZm9yIG1vc3QgZW5kIHVz
ZXIgb3JnYW5pemF0aW9uIHNpdHVhdGlvbnMsICAgIGJ1dCBwZXJoYXBzIG5vdCBiZW5lZmlj
aWFsIGZvciBtYW55IGxhcmdlciBuZXR3b3JrIG9wZXJhdG9ycy4gICAgICBJZiB0aGUgZG9j
dW1lbnQgY2FuIHBvaW50IG91dCByZWFzb25zIFdIWSB0aGlzIG1pZ2h0IGJlIHRoZSBjYXNl
IChlLmcuIGxhcmdlIEJHUCBpbXBsZW1lbnRhdGlvbiksICBvcmdhbml6YXRpb25zIHZpZXdp
bmcgdGhpcyBkb2N1bWVudCB3b3VsZCBiZSBpbiBhIGdvb2QgcG9zaXRpb24gdG8gZGV0ZXJt
aW5lIHdoYXQgb3B0aW1hbCBuZXR3b3JrIGRlc2lnbnMgZm9yICB0aGVpciBzcGVjaWZpYyBz
aXR1YXRpb24uICAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJr
IFpaWiBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXVdIA0KU2VudDog
VGh1cnNkYXksIEFwcmlsIDA5LCAyMDE1IDY6NDIgUE0NClRvOiBOaWNrIEhpbGxpYXJkOyBB
Y2tlcm1hbm4sIE1pY2hhZWw7IFBoaWxpcCBNYXR0aGV3czsgRnJlZCBCYWtlciAoZnJlZCkN
CkNjOiB2Nm9wcyBsaXN0DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFJbiBmdC1pZXRmLXY2
b3BzLWRlc2lnbi1jaG9pY2VzIFdHTEMNCg0KSSB0aGluayBpdCBpcyB3b3J0aCBwb2ludGlu
ZyBvdXQgdGhhdCBOaWNrJ3MgdXNlIGNhc2VzIGFyZSBvciBhcmUgcHJvYmFibHkgSW50ZXJu
ZXQgRXhjaGFuZ2Ugb25lcywgd2hlcmUgYm90aCBoZSBhbmQgaGlzIGN1c3RvbWVycyBhcmUg
aGlnaGx5IHRlY2huaWNhbGx5IGNvbXBldGVudC4gVGhlIG1lY2hhbmlzbXMgaGUncyBkaXNh
YmxpbmcgYnkgZGlzYWJsaW5nIGxpbmstbG9jYWxzIGUuZy4sIERBRCwgYXJlIG9uZXMgdGhh
dCBpbiBhbiBJWCBlbnZpcm9ubWVudCBhcmUgaW4gZWZmZWN0IHByb3ZpZGVkIGJ5IHRob3Jv
dWdoIGF0dGVudGlvbiB0byBkZXRhaWwgaW4gYm90aCBhZG1pbmlzdHJhdGlvbiBhbmQgbWFu
dWFsIGNvbmZpZ3VyYXRpb24sIGhlbmNlIHRoZSAiKGUuZy4gUkEsIERBRCwgZXRjKSwgYnV0
IHRoZXNlIGFyZW4ndCByZWxldmFudC4iDQoNCkkgc2VlIHRoZSB0YXJnZXQgZm9yIHRoaXMg
ZHJhZnQgdG8gYmUgbW9yZSBnZW5lcmFsIGNhc2VzLCB3aGVyZSB0aGVyZSBpcyBsZXNzIHRp
bWUgb3IgcmVzb3VyY2VzIHRvIHNwZW5kIG9uIHByb3ZpZGluZyBtYW51YWwgZXF1aXZhbGVu
dHMgdG8gdGhlc2UgYXV0b21hdGVkIHByb3RvY29scyB0aGF0IHVzZSBsaW5rLWxvY2Fscy4N
Cg0KKE9uZSBwYXJ0aWN1bGFyIGJhZCBpbmNpZGVudCBpbiBteSBwYXN0IG9mIHdoZXJlIHRo
ZXJlIHdlcmUgNSBob3N0cyB3aXRoIGR1cGxpY2F0ZSBJUHY0IGFkZHJlc3NlcyBwcmUtSVB2
NCBEQUQgbWFrZXMgbWUgbmV2ZXIgd2FudCB0byBzZWUgREFEIGJlY29tZSBvcHRpb25hbCBh
Z2Fpbi4pDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogTmljayBI
aWxsaWFyZCA8bmlja0Bmb29iYXIub3JnPg0KVG86ICJBY2tlcm1hbm4sIE1pY2hhZWwiIDxN
QWNrZXJtYW5uQGJjYnNtLmNvbT47IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFo
b28uY29tLmF1PjsgUGhpbGlwIE1hdHRoZXdzIDxwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2E+
OyBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20+DQpDYzogdjZvcHMgbGlzdCA8
djZvcHNAaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIDEwIEFwcmlsIDIwMTUsIDc6MDENClN1
YmplY3Q6IFJlOiBbdjZvcHNdIGRyYUluIGZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMg
V0dMQw0KDQpPbiAwOS8wNC8yMDE1IDE2OjU4LCBBY2tlcm1hbm4sIE1pY2hhZWwgd3JvdGU6
DQo+IE1ha2VzIHNlbnNlLiAgIEkgY2FuIHNlZSB3aGVyZSB5b3VyIEJHUCBzZXQgdXAgd291
bGQgYmUgY29tcGVsbGluZy4NCj4gDQo+IE9uZSBvZiBteSBxdWVzdGlvbnMgd2FzIGlmIHRo
ZSBMaW5rIExvY2FsIFByb3MgYW5kIENvbnMgd291bGQgYmUgDQo+IGRpZmZlcmVudCBmb3Ig
RW5kIEhvc3RzIHZzIE1pZGRsZSBCb3hlcy4gWW91ciBjb21tZW50cyBtYWtlIG1lIHRoaW5r
IA0KPiB0aGF0IGl0IG1heSBiZSBnb29kIGZvciBFbmQgSG9zdHMsIGJ1dCBub3Qgc28gbXVj
aCBNaWRkbGUgQm94ZXMsICBpbiANCj4gcGFydGljdWxhciBsYXJnZSBzY2FsZSBwcm92aWRl
ciBuZXR3b3Jrcy4NCj4gDQo+IFlvdSBtZW50aW9uIHRoYXQgeW91IHJlbW92ZSBMaW5rIExv
Y2FscyB3aGVyZXZlciBwb3NzaWJsZS4gICAgT24gd2hhdA0KPiBwbGF0Zm9ybXMgaXMgdGhp
cyBwb3NzaWJsZSB3aXRob3V0IHJlbW92aW5nIG1vc3Qgb2YgSVB2Nj8gICAgRG9lcyB0aGlz
DQo+IGNhdXNlIGlzc3VlcyB3aXRoIGludHJpbnNpYyBmdW5jdGlvbnMgc3VjaCBhcyBORFAs
IGV0Yy4/DQoNCmxpbmstbG9jYWxzIGFyZSBuZWNlc3Nhcnkgb24gZW5kLWhvc3RzIGR1ZSB0
byBhdXRvY29uZmlnIHJlcXVpcmVtZW50cy4NCk91dHNpZGUgdGhpcywgbXkgdXNlIGNhc2Vz
IHRlbmQgdG8gYmUgc3RhdGljYWxseSBjb25maWd1cmVkIHNlcnZlcnMgb3IgZWxzZSByb3V0
ZXIgbGluayBhZGRyZXNzaW5nLiAgTmVpdGhlciBvZiB0aGVzZSBzaXR1YXRpb25zIHBhcnRp
Y3VsYXJseSBuZWVkIGxpbmstbG9jYWxzLiAgTkRQIHdvcmtzIGZpbmUgd2l0aCBHVUFzLiAg
T3RoZXIgcHJvdG9jb2xzIGFzc29jaWF0ZWQgd2l0aCBhdXRvY29uZmlnIGJyZWFrIChlLmcu
IFJBLCBEQUQsIGV0YyksIGJ1dCB0aGVzZSBhcmVuJ3QgcmVsZXZhbnQuDQoNClRvIGRpc2Fi
bGUgbGluay1sb2NhbHMgb24gYSBjaXNjbyByb3V0ZXIsIHVzZSAibm8gaXB2NiBlbmFibGUi
IG9uIHlvdXIgaW50ZXJmYWNlLiAgSXQgd29ya3MgZmluZSBpZiB5b3UgZG9uJ3QgbmVlZCBp
dC4NCg0KDQpOaWNrDQoKClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21t
dW5pY2F0aW9uIGlzIGhpZ2hseSBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVs
eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVu
aWNhdGlvbiBpcyBkaXJlY3RlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw
aWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWlu
ZywgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBw
cm9oaWJpdGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFp
bCBvciB0ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0
aGUgb3JpZ2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2luZyBhbnkgY29waWVzLgogCiBCbHVl
IENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0d29yayBv
ZiBNaWNoaWdhbiBhcmUgbm9ucHJvZml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRlbnQg
bGljZW5zZWVzIG9mIHRoZSBCbHVlIENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lhdGlv
bi4K


From nobody Fri Apr 10 09:29: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 3461B1A6FEF for ; Fri, 10 Apr 2015 09:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level: 
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 nYoee1DKGG48 for ; Fri, 10 Apr 2015 09:29:36 -0700 (PDT)
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 F25BA1A6F3C for ; Fri, 10 Apr 2015 09:29:35 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet-2.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t3AGTV66047089 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2015 17:29:31 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet-2.local
Message-ID: <5527FA6B.8020506@foobar.org>
Date: Fri, 10 Apr 2015 17:29:31 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Brian E Carpenter , v6ops@ietf.org
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com> <20150407123653.GS54385@Space.Net> <5526E4ED.3020405@gmail.com> <5526EA10.7040804@foobar.org> <55271231.1010405@gmail.com>
In-Reply-To: <55271231.1010405@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 16:29:38 -0000

On 10/04/2015 00:58, Brian E Carpenter wrote:
> On 10/04/2015 09:07, Nick Hilliard wrote:
>> products are designed to a budget and a performance spec.  There's no point
>> in building a router which will inspect 65536 byte packets for EH chains if
>> it's too expensive for anyone to buy, or if it trashes performance by
>> passing packets with headers that big.  There is always a
>> cost/speed/features compromise.
> 
> Of course. But we already changed the standard to limit this problem:
> 
> http://tools.ietf.org/html/rfc7112

a policy cannot change reality.  At best it can hope to complement it.

Nick



From nobody Fri Apr 10 10:01: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 3EFDA1B29B3 for ; Fri, 10 Apr 2015 10:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVVRxb1TdgZ2 for ; Fri, 10 Apr 2015 10:01:17 -0700 (PDT)
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 EFF901B29A3 for ; Fri, 10 Apr 2015 10:01:16 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet-2.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t3AH189X047685 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2015 18:01:08 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet-2.local
Message-ID: <552801D4.3000302@foobar.org>
Date: Fri, 10 Apr 2015 18:01:08 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Mark ZZZ Smith , "Ackermann, Michael" , Philip Matthews , "Fred Baker (fred)" 
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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: Fri, 10 Apr 2015 17:01:24 -0000

On 09/04/2015 23:42, Mark ZZZ Smith wrote:
> I think it is worth pointing out that Nick's use cases are or are
> probably Internet Exchange ones, where both he and his customers are
> highly technically competent. The mechanisms he's disabling by disabling
> link-locals e.g., DAD, are ones that in an IX environment are in effect
> provided by thorough attention to detail in both administration and
> manual configuration, hence the "(e.g. RA, DAD, etc), but these aren't
> relevant."

IXPs are one situation I was thinking of (note that I also do L3 ISP
engineering as well as IXP operations).  General servers installation with
static IP addressing is another case which does not benefit from dynamic
addressing.  YMMV though.  Just because they don't add anything for me
doesn't mean that they don't add anything for you.  Also, server stuff is
slightly separate from network design.

> I see the target for this draft to be more general cases, where there is
> less time or resources to spend on providing manual equivalents to these
> automated protocols that use link-locals.

IPv6 IGPs (e.g. ospf / isis) implicitly use link-locals.  That's fine;
there is technical benefit there because these are link-state protocols and
don't gain benefit from using GUAs.

I don't see any technical benefit for bgp though.  There are two situations
to note: using LLs for session addressing or using them for next-hop.

It's pointless to use them for session addressing because ibgp will
generally talk to an (often non-locally-connected) route reflector so
link-locals are impossible, and ebgp will generally require GUAs by policy
anyway.  In either case, bgp sessions are manually configured (or handled
by provisioning system) rather than auto-discovered locally on a router, so
if you need to manually set up a session, it's probably more obvious to use
GUAs.

LLs don't really work for NH either, if you have a non trivial network.  Do
you really want your network to converge at the speed of your MRAI?  I
don't.  Far more sensible to use your zippy igp for all that sort of thing
and let bgp do the heavy lifting of prefix propagation.

Nick


> ----- Original Message ----- From: Nick Hilliard  To:
> "Ackermann, Michael" ; Mark ZZZ Smith
> ; Philip Matthews ;
> Fred Baker (fred)  Cc: v6ops list  Sent:
> Friday, 10 April 2015, 7:01 Subject: Re: [v6ops] draIn
> ft-ietf-v6ops-design-choices WGLC
> 
> On 09/04/2015 16:58, Ackermann, Michael wrote:
>> Makes sense.   I can see where your BGP set up would be compelling.
>> 
>> One of my questions was if the Link Local Pros and Cons would be 
>> different for End Hosts vs Middle Boxes. Your comments make me think 
>> that it may be good for End Hosts, but not so much Middle Boxes,  in 
>> particular large scale provider networks.
>> 
>> You mention that you remove Link Locals wherever possible.    On what 
>> platforms is this possible without removing most of IPv6?    Does
>> this cause issues with intrinsic functions such as NDP, etc.?
> 
> link-locals are necessary on end-hosts due to autoconfig requirements. 
> Outside this, my use cases tend to be statically configured servers or
> else router link addressing.  Neither of these situations particularly
> need link-locals.  NDP works fine with GUAs.  Other protocols associated
> with autoconfig break (e.g. RA, DAD, etc), but these aren't relevant.
> 
> To disable link-locals on a cisco router, use "no ipv6 enable" on your 
> interface.  It works fine if you don't need it.
> 
> 
> Nick
> 


From nobody Fri Apr 10 10:02: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 0FD061A873D for ; Fri, 10 Apr 2015 10:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd1SQaZLnALc for ; Fri, 10 Apr 2015 10:02:28 -0700 (PDT)
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 DDD3C1A88D4 for ; Fri, 10 Apr 2015 10:02:27 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet-2.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t3AH2Mbp047712 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2015 18:02:22 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet-2.local
Message-ID: <5528021E.3010500@foobar.org>
Date: Fri, 10 Apr 2015 18:02:22 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Ackermann, Michael" , Mark ZZZ Smith , Philip Matthews , "Fred Baker (fred)" 
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com>
In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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: Fri, 10 Apr 2015 17:02:30 -0000

On 10/04/2015 16:42, Ackermann, Michael wrote:
> It seems that the advice to use Link Locals for next hop (or maybe even
> to use them at all?),  is situationally dependent.

Can you provide some concrete examples of where LLs are more appropriate
than GUAs for BGP NH, and why?  I'm genuinely struggling to see any advantage.

Nick


From nobody Fri Apr 10 10:30: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 2D2091A8865 for ; Fri, 10 Apr 2015 10:30:49 -0700 (PDT)
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 d83QjfLtqFXt for ; Fri, 10 Apr 2015 10:30:47 -0700 (PDT)
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 41D6F1A885B for ; Fri, 10 Apr 2015 10:30:46 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D871562CEF for ; Fri, 10 Apr 2015 19:30:44 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9310262CD6 for ; Fri, 10 Apr 2015 19:30:44 +0200 (CEST)
Received: (qmail 7981 invoked by uid 1007); 10 Apr 2015 19:30:44 +0200
Date: Fri, 10 Apr 2015 19:30:44 +0200
From: Gert Doering 
To: Nick Hilliard 
Message-ID: <20150410173044.GV54385@Space.Net>
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com> <5528021E.3010500@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5528021E.3010500@foobar.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: v6ops list , Philip Matthews 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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: Fri, 10 Apr 2015 17:30:49 -0000

Hi,

On Fri, Apr 10, 2015 at 06:02:22PM +0100, Nick Hilliard wrote:
> On 10/04/2015 16:42, Ackermann, Michael wrote:
> > It seems that the advice to use Link Locals for next hop (or maybe even
> > to use them at all?),  is situationally dependent.
> 
> Can you provide some concrete examples of where LLs are more appropriate
> than GUAs for BGP NH, and why?  I'm genuinely struggling to see any advantage.

Seconded.

LL NHs for BGP are one of the things causing serious pain today (you peer
with a peer router on the GUA, your BGP process installs the prefix with
the LL NH into the FIB, and if anything breaks in ND for the LL NH, you
blackhole traffic - with GUA NHs, if ND breaks for the GUA, BGP will not 
come up, so "no blackholing").  

And no, this is not a hypothetical example, we currently have at least 
one peer configured with static ND entries on our side because LL ND between
these two boxes is "unreliable", and we've seen blackholing as a consequence
(TAC investigating, but it's... complicated to debug ND on a shared network
with over 600 routers and significant traffic levels).

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 Apr 10 11:12: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 3F3A81B29EF for ; Fri, 10 Apr 2015 11:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKhQB8uKoQeO for ; Fri, 10 Apr 2015 11:11:56 -0700 (PDT)
Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 42EA91B29E5 for ; Fri, 10 Apr 2015 11:11:56 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 3FF6F2820DE for ; Fri, 10 Apr 2015 13:11:55 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id A85922820A1; Fri, 10 Apr 2015 13:11:54 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 69D9D2F5269; Fri, 10 Apr 2015 14:08:58 -0400 (EDT)
Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id 5C91C2F523F; Fri, 10 Apr 2015 14:08:58 -0400 (EDT)
Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([::1]) with mapi id 14.01.0438.000;  Fri, 10 Apr 2015 14:11:52 -0400
From: "Ackermann, Michael" 
To: Nick Hilliard , Mark ZZZ Smith , Philip Matthews , "Fred Baker (fred)" 
Thread-Topic: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
Thread-Index: AdBwejVZflkIuUqSRyO7yHiQggoOUQBQBUQAADGQMIAAFEHyUAAKlbwAAAe2V4AAA8flgAADhMYAABpqfEAADADhAAAF+U9g
Date: Fri, 10 Apr 2015 18:11:42 +0000
Message-ID: <4FC37E442D05A748896589E468752CAA0CDB10E8@PWN401EA160.ent.corp.bcbsm.com>
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com> <5528021E.3010500@foobar.org>
In-Reply-To: <5528021E.3010500@foobar.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.10.35]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-VPM-HOST: vmvpm02.z120.zixworks.com
X-VPM-GROUP-ID: 114c3ee0-8ec5-4bb3-bd96-0bb240f5f161
X-VPM-MSG-ID: 61a377b1-1c03-40cd-84b8-fa6d84fb7e3c
X-VPM-ENC-REGIME: Plaintext
X-VPM-CERT-FLAG: 0
X-VPM-IS-HYBRID: 0
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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: Fri, 10 Apr 2015 18:11:58 -0000

SSBkbyBub3Qgc2VlIGFueSBhZHZhbnRhZ2UgaW4gYSBCR1AgZW52aXJvbm1lbnQuICANCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5pY2sgSGlsbGlhcmQgW21haWx0
bzpuaWNrQGZvb2Jhci5vcmddIA0KU2VudDogRnJpZGF5LCBBcHJpbCAxMCwgMjAxNSAxOjAy
IFBNDQpUbzogQWNrZXJtYW5uLCBNaWNoYWVsOyBNYXJrIFpaWiBTbWl0aDsgUGhpbGlwIE1h
dHRoZXdzOyBGcmVkIEJha2VyIChmcmVkKQ0KQ2M6IHY2b3BzIGxpc3QNClN1YmplY3Q6IFJl
OiBbdjZvcHNdIGRyYUluIGZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMgV0dMQw0KDQpP
biAxMC8wNC8yMDE1IDE2OjQyLCBBY2tlcm1hbm4sIE1pY2hhZWwgd3JvdGU6DQo+IEl0IHNl
ZW1zIHRoYXQgdGhlIGFkdmljZSB0byB1c2UgTGluayBMb2NhbHMgZm9yIG5leHQgaG9wIChv
ciBtYXliZSANCj4gZXZlbiB0byB1c2UgdGhlbSBhdCBhbGw/KSwgIGlzIHNpdHVhdGlvbmFs
bHkgZGVwZW5kZW50Lg0KDQpDYW4geW91IHByb3ZpZGUgc29tZSBjb25jcmV0ZSBleGFtcGxl
cyBvZiB3aGVyZSBMTHMgYXJlIG1vcmUgYXBwcm9wcmlhdGUgdGhhbiBHVUFzIGZvciBCR1Ag
TkgsIGFuZCB3aHk/ICBJJ20gZ2VudWluZWx5IHN0cnVnZ2xpbmcgdG8gc2VlIGFueSBhZHZh
bnRhZ2UuDQoNCk5pY2sNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNv
bW11bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29s
ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21t
dW5pY2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj
aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5
aW5nLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlz
IHByb2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBt
YWlsIG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRl
IHRoZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJs
dWUgQ3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3Jr
IG9mIE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVu
dCBsaWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0
aW9uLgo=


From nobody Fri Apr 10 12:30: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 1EA3D1A6F32 for ; Fri, 10 Apr 2015 12:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IyvDW7t6lkYZ for ; Fri, 10 Apr 2015 12:30:08 -0700 (PDT)
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 EBC691A1BDA for ; Fri, 10 Apr 2015 12:30:07 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:0:0:0:110]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t3AJTvnR050218 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2015 20:29:58 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:110] claimed to be cupcake.foobar.org
Message-ID: <552824B5.3050503@foobar.org>
Date: Fri, 10 Apr 2015 20:29:57 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Ackermann, Michael" , Mark ZZZ Smith , Philip Matthews , "Fred Baker (fred)" 
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com> <5528021E.3010500@foobar.org> <4FC37E442D05A748896589E468752CAA0CDB10E8@PWN401EA160.ent.corp.bcbsm.com>
In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDB10E8@PWN401EA160.ent.corp.bcbsm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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: Fri, 10 Apr 2015 19:30:10 -0000

On 10/04/2015 19:11, Ackermann, Michael wrote:
> I do not see any advantage in a BGP environment.  

Ok, sure.

Can you now provide some concrete examples of where LLs are more
appropriate than GUAs for BGP NH, and why?

Nick

> -----Original Message-----
> From: Nick Hilliard [mailto:nick@foobar.org] 
> Sent: Friday, April 10, 2015 1:02 PM
> To: Ackermann, Michael; Mark ZZZ Smith; Philip Matthews; Fred Baker (fred)
> Cc: v6ops list
> Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
> 
> On 10/04/2015 16:42, Ackermann, Michael wrote:
>> It seems that the advice to use Link Locals for next hop (or maybe 
>> even to use them at all?),  is situationally dependent.
> 
> Can you provide some concrete examples of where LLs are more appropriate than GUAs for BGP NH, and why?  I'm genuinely struggling to see any advantage.
> 
> Nick
> 
> 
> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>  
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
> 


From nobody Fri Apr 10 13:35: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 D79B31A88C6 for ; Fri, 10 Apr 2015 13:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wvV3rIJ7hQi for ; Fri, 10 Apr 2015 13:35:29 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 506871A88C4 for ; Fri, 10 Apr 2015 13:35:29 -0700 (PDT)
Received: by paboj16 with SMTP id oj16so32070213pab.0 for ; Fri, 10 Apr 2015 13:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V+p8BxT44ktLy8NfzqY2ivthCvZCSv3DNFc+6G2zYak=; b=yztscdDOQybrZz25l3Y6gT+KpNgCnSf3svAg2RrMesxpqnq8CyQwZjeb0mwdfiD/66 Bj5+cHxXOeykaQC+aGNsjycPOXNo08iCjLIFq4qG8JgfIijblMRCfbBd8avpEY5BPQe+ +sUO/MgabMnhfXg3fvQ6PqQhH/aiy6l2rrhtvv6Vcy/TNcLc0MXDO5vgqTchtQQYCZHI yrEjx2VbUZlm/fIjBly1zsF8y9wSRhqdGHsu+yMQLl1cUkgKsz8FD59ktNTQJEQRp1/z rK7YslBnpzYbfQoFuV0WrK1SgMeh7anD4MguRMOsC0xm4mrF7/Bruob/Q2OkxYVdutSj MGZw==
X-Received: by 10.66.237.35 with SMTP id uz3mr5789979pac.46.1428698129065; Fri, 10 Apr 2015 13:35:29 -0700 (PDT)
Received: from ?IPv6:2406:e007:7e03:1:28cc:dc4c:9703:6781? ([2406:e007:7e03:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id dk5sm3131388pdb.88.2015.04.10.13.35.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 13:35:27 -0700 (PDT)
Message-ID: <55283418.5090108@gmail.com>
Date: Sat, 11 Apr 2015 08:35:36 +1200
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.6.0
MIME-Version: 1.0
To: Nick Hilliard , v6ops@ietf.org
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com> <20150407123653.GS54385@Space.Net> <5526E4ED.3020405@gmail.com> <5526EA10.7040804@foobar.org> <55271231.1010405@gmail.com> <5527FA6B.8020506@foobar.org>
In-Reply-To: <5527FA6B.8020506@foobar.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 20:35:31 -0000

On 11/04/2015 04:29, Nick Hilliard wrote:
> On 10/04/2015 00:58, Brian E Carpenter wrote:
>> On 10/04/2015 09:07, Nick Hilliard wrote:
>>> products are designed to a budget and a performance spec.  There's no point
>>> in building a router which will inspect 65536 byte packets for EH chains if
>>> it's too expensive for anyone to buy, or if it trashes performance by
>>> passing packets with headers that big.  There is always a
>>> cost/speed/features compromise.
>>
>> Of course. But we already changed the standard to limit this problem:
>>
>> http://tools.ietf.org/html/rfc7112
> 
> a policy cannot change reality.  At best it can hope to complement it.

True. But fixing our specs and encouraging implementers to do the
right thing are the only tools the IETF has.

    Brian


From nobody Fri Apr 10 17:11: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 A500C1B2EDF for ; Fri, 10 Apr 2015 17:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Il6v-IaE9cQ for ; Fri, 10 Apr 2015 17:11:44 -0700 (PDT)
Received: from tor-smtp-05.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id E44161B2EDE for ; Fri, 10 Apr 2015 17:11:43 -0700 (PDT)
Received: from [24.114.102.128] (helo=[172.20.10.4]) by tor-smtp-05.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1Ygj1S-0000HO-Ns; Fri, 10 Apr 2015 20:11:43 -0400
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Philip Matthews 
In-Reply-To: <552824B5.3050503@foobar.org>
Date: Fri, 10 Apr 2015 20:11:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <55935A5C-84BE-4551-81A6-4EFE8690F6A0@magma.ca>
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com> <5528021E.3010500@foobar.org> <4FC37E442D05A748896589E468752CAA0CDB10E8@PWN401EA160.ent.corp.bcbsm.com> <552824B5.3050503@foobar.org>
To: Michael Ackermann 
X-Mailer: Apple Mail (2.1085)
X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.102.128]
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 11 Apr 2015 00:11:45 -0000

Michael:

I am following this conversation with interest, especially since you =
seem to be new to IPv6 network design, and thus are exactly the intended =
audience for this draft.

The questions you are coming up with seem to be very similar to the ones =
I had when I first started doing IPv6 network design.  Those questions =
later prompted me to start the draft.

So far, I have not seen anything new in this conversation to add to the =
draft, but it could well be that I am suffering from "document fatigue". =
You, on the other hand, are reading it with fresh eyes and may well see =
things that I just miss.

I encourage you and everyone else on this thread to send me any =
suggestions you have for improving the document.

- Philip

On 2015-04-10, at 15:29 , Nick Hilliard wrote:

> On 10/04/2015 19:11, Ackermann, Michael wrote:
>> I do not see any advantage in a BGP environment. =20
>=20
> Ok, sure.
>=20
> Can you now provide some concrete examples of where LLs are more
> appropriate than GUAs for BGP NH, and why?
>=20
> Nick
>=20
>> -----Original Message-----
>> From: Nick Hilliard [mailto:nick@foobar.org]=20
>> Sent: Friday, April 10, 2015 1:02 PM
>> To: Ackermann, Michael; Mark ZZZ Smith; Philip Matthews; Fred Baker =
(fred)
>> Cc: v6ops list
>> Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
>>=20
>> On 10/04/2015 16:42, Ackermann, Michael wrote:
>>> It seems that the advice to use Link Locals for next hop (or maybe=20=

>>> even to use them at all?),  is situationally dependent.
>>=20
>> Can you provide some concrete examples of where LLs are more =
appropriate than GUAs for BGP NH, and why?  I'm genuinely struggling to =
see any advantage.
>>=20
>> Nick
>>=20
>>=20
>> The information contained in this communication is highly =
confidential and is intended solely for the use of the individual(s) to =
whom this communication is directed. If you are not the intended =
recipient, you are hereby notified that any viewing, copying, disclosure =
or distribution of this information is prohibited. Please notify the =
sender, by electronic mail or telephone, of any unintended receipt and =
delete the original message without making any copies.
>>=20
>> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan =
are nonprofit corporations and independent licensees of the Blue Cross =
and Blue Shield Association.
>>=20
>=20
>=20


From nobody Sat Apr 11 03:32: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 6CEDC1ACE15 for ; Sat, 11 Apr 2015 03:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level: 
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Gc4-Mmn2Jx6 for ; Sat, 11 Apr 2015 03:32:34 -0700 (PDT)
Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 130D11ACE1B for ; Sat, 11 Apr 2015 03:32:33 -0700 (PDT)
Received: from [127.0.0.1] (unknown [222.130.138.77]) by centos (Coremail) with SMTP id AQAAf3Drn+6z9ihV1bZSAA--.2103S5; Sat, 11 Apr 2015 18:25:58 +0800 (CST)
Message-ID: <5528F81F.1040905@cernet.edu.cn>
Date: Sat, 11 Apr 2015 18:31:59 +0800
From: Xing Li 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Ross Chandler 
References:             <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060605020102040205010901"
X-CM-TRANSID: AQAAf3Drn+6z9ihV1bZSAA--.2103S5
X-Coremail-Antispam: 1UD129KBjvJXoW7Zw4fJw45Ar47ZFWrWFW5GFg_yoW8Wr4xpF yUWFW7tF4DJF10yr9xCw4xuFnYvFs5Jwn8Ga4Uuw1kArZYkr1FgrZFqF9I9ry3C34fua10 qrWjvas5ua4fA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqFb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Jr0_Gr 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6c804VAFz4xC04v7McIj6I8E87Iv67AK xVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rV Aqx4xJMxkIecxEwVAFwVW8twCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r106r1r MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4 1lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1l IxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0x vEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07UA9NsUUUUU=
X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 11 Apr 2015 10:32:36 -0000

This is a multi-part message in MIME format.
--------------060605020102040205010901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Ross Chandler 写é“:
>> On 7 Apr 2015, at 06:23, Xing Li  wrote:
>>     
>>> Once IPv6-only with double IPv4/IPv6 translation is available the next stage to reach is IPv6-only. IPv4 literals will be with us for as long as IPv4 is.  
>>>       
>> If all the users on the Internet can access both the IPv4 (via double and single translation) and IPv6 (native) contents, who cares if the IPv4 literals will coexist with IPv4 and IPv6 for a long time?
>>     
>
> I think for 3GPP especially people care more about the IPv4 literals & IPv4 only apps issue as that necessitates IPv4+IPv6 on the PDP/PDN connection for Internet access. Having 464xlat stops this issue hindering adoption of IPv6. With the local-ipv4 socket transition solution efforts to fix IPv4 literals and IPv4 only apps can proceed in parallel with IPv6 deployment instead of impeding it.
>
> In fixed Internet, not having a local-ipv4 socket translation solution isn’t as bad a hinderance as the end hosts sit behind a CPE providing dual-stack on the LAN side. 
>   

In order not to downgrade the users experience, the choices are:
(1) Dual-stack: dual-stack network interface and dual-stack local sockets
(2) 464xlat:  IPv6-only network interface and dual-stack local sockets

I believe (2) provides a better chance to move to IPv6-only then (1), no 
matter with or without a CPE. Can we convince all the users turn off the 
IPv4 socket in their OS before the *whole* Internet fixes the IPv4 
literals & IPv4 only apps problem, even their ISP has IPv6 and NAT64 
services? Frankly speaking, it is very difficult, if not impossible.

Regards,

xing




> Ross
>
>
>
>   


--------------060605020102040205010901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




  


Ross Chandler 写é“:


  

    
On 7 Apr 2015, at 06:23, Xing Li <xing@cernet.edu.cn> wrote:
    

    

      
Once IPv6-only with double IPv4/IPv6 translation is available the next stage to reach is IPv6-only. IPv4 literals will be with us for as long as IPv4 is.  
      

    

    
If all the users on the Internet can access both the IPv4 (via double and single translation) and IPv6 (native) contents, who cares if the IPv4 literals will coexist with IPv4 and IPv6 for a long time?
    

  

  

I think for 3GPP especially people care more about the IPv4 literals & IPv4 only apps issue as that necessitates IPv4+IPv6 on the PDP/PDN connection for Internet access. Having 464xlat stops this issue hindering adoption of IPv6. With the local-ipv4 socket transition solution efforts to fix IPv4 literals and IPv4 only apps can proceed in parallel with IPv6 deployment instead of impeding it.

In fixed Internet, not having a local-ipv4 socket translation solution isn’t as bad a hinderance as the end hosts sit behind a CPE providing dual-stack on the LAN side. 
  




In order not to downgrade the
users
experience, the choices are:

(1) Dual-stack: dual-stack network interface and dual-stack local
sockets

(2) 464xlat:  IPv6-only network interface and dual-stack local sockets



I believe (2) provides a better chance to move to IPv6-only then (1),
no matter with or
without a CPE. Can we convince all the users turn off the IPv4 socket
in their
OS before the *whole* Internet fixes the IPv4 literals & IPv4 only
apps problem,
even their ISP has IPv6 and NAT64 services? Frankly speaking, it is
very
difficult, if not impossible.



Regards,



xing









  
Ross



  








--------------060605020102040205010901--



From nobody Sat Apr 11 05:06: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 4CA021AD2D5 for ; Sat, 11 Apr 2015 05:05:58 -0700 (PDT)
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, HTML_MESSAGE=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 65WX_4ziQENO for ; Sat, 11 Apr 2015 05:05:57 -0700 (PDT)
Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 75CBA1AD2B2 for ; Sat, 11 Apr 2015 05:05:56 -0700 (PDT)
Received: from [127.0.0.1] (unknown [123.114.52.101]) by centos (Coremail) with SMTP id AQAAf3Arzwa5DClVgeNSAA--.12600S5; Sat, 11 Apr 2015 19:59:54 +0800 (CST)
Message-ID: <55290E26.8080500@cernet.edu.cn>
Date: Sat, 11 Apr 2015 20:05:58 +0800
From: Xing Li 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: James Woodyatt 
References: 											<552102B0.6070904@cernet.edu.cn>	<35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net>	<552369C8.5000801@cernet.edu.cn> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010702060803060702000702"
X-CM-TRANSID: AQAAf3Arzwa5DClVgeNSAA--.12600S5
X-Coremail-Antispam: 1UD129KBjvdXoWrKrWrKr1UuFyrZF4fCrW3Jrb_yoWfKrXE9r yxKr1kuw4UAr12qwnFka1fAwn5u3yDWw10qrn8X34aga4xArZ5u3Z5Zr9rKry7JFWfJr4D Wr9xWrya9ry2gjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbjxYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwA2z4x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwVC2z280aVCY1x0267AKxVWUJVW8Jw AS0I0E0xvYzxvE52x082IY62kv0487Mc02F40ExcI2r2IE04Ijxs4lYx0Ex4A2jsIE14v2 6r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c 02F41l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AK xVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcV AFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8I cIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI 0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07UdrcfUUUUU=
X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 11 Apr 2015 12:05:58 -0000

This is a multi-part message in MIME format.
--------------010702060803060702000702
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

James Woodyatt 写é“:
> On Mon, Apr 6, 2015 at 10:23 PM, Xing Li  > wrote:
>
>
>     If all the users on the Internet can access both the IPv4 (via
>     double and single translation) and IPv6 (native) contents, who
>     cares if the IPv4 literals will coexist with IPv4 and IPv6 for a
>     long time?
>
>
> You have obviously never tried to sell recurring software maintenance 
> work to support IPv6 transition to the management of a commercial host 
> operating systems vendor.
>
No. I am an academic network service provider and my goal is to provide 
global IPv4/IPv6 Internet connectivity using an IPv6-only backbone and 
very limited public IPv4 addresses. If the end system has the RFC6145 
function, the subnet can be IPv6-only. If the end system does not have 
the RFC6145 function, the subnet must be dual stack and the RFC6145 
function is provided via access gateway (CPE).

Regards,

xing

>
> -- 
> james woodyatt >
> Nest Labs, Communications Engineering


--------------010702060803060702000702
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




  
  


James Woodyatt 写é“:


  

  

  
On Mon, Apr 6, 2015 at 10:23 PM, Xing Li <xing@cernet.edu.cn>
wrote:

  

    


    If all the users on the Internet can access both the IPv4
(via double
and single translation) and IPv6 (native) contents, who cares if the
IPv4 literals will coexist with IPv4 and IPv6 for a long time?

  

  

  

You have obviously never tried to sell recurring software maintenance
work to support IPv6 transition to the management of a commercial host
operating systems vendor.

  


  

  



No. I am an academic network service provider and my goal is to provide
global IPv4/IPv6 Internet connectivity using an IPv6-only backbone and
very limited public IPv4 addresses. If the end system has the RFC6145
function, the subnet can be IPv6-only. If the end system does not have
the RFC6145 function, the subnet must be dual stack and the RFC6145
function is provided via access gateway (CPE).



Regards,



xing





  

  

  


  

-- 

  

  
james woodyatt <jhw@nestlabs.com>
  
Nest Labs, Communications Engineering

  

  

  

  








--------------010702060803060702000702--



From nobody Sat Apr 11 15:05: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 4E3701B2FDC for ; Sat, 11 Apr 2015 15:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level: 
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 yJBlIQOiQ7th for ; Sat, 11 Apr 2015 15:05:43 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70E71B2FC4 for ; Sat, 11 Apr 2015 15:05:42 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 1571E1FCACC; Sat, 11 Apr 2015 22:05:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 51FC0160050; Sat, 11 Apr 2015 22:05:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 102BA160075; Sat, 11 Apr 2015 22:05:40 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 47Euobe939V1; Sat, 11 Apr 2015 22:05:39 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id B92D7160050; Sat, 11 Apr 2015 22:05:39 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 81B592CB77FF; Sun, 12 Apr 2015 08:05:35 +1000 (EST)
To: Xing Li 
From: Mark Andrews 
References:            <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>
In-reply-to: Your message of "Sat, 11 Apr 2015 20:05:58 +0800." <55290E26.8080500@cernet.edu.cn>
Date: Sun, 12 Apr 2015 08:05:34 +1000
Message-Id: <20150411220535.81B592CB77FF@rock.dv.isc.org>
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 11 Apr 2015 22:05:45 -0000

In message <55290E26.8080500@cernet.edu.cn>, Xing Li writes:
> James Woodyatt 写é“:
> > On Mon, Apr 6, 2015 at 10:23 PM, Xing Li  > > wrote:
> >
> >
> >     If all the users on the Internet can access both the IPv4 (via
> >     double and single translation) and IPv6 (native) contents, who
> >     cares if the IPv4 literals will coexist with IPv4 and IPv6 for a
> >     long time?
> >
> >
> > You have obviously never tried to sell recurring software maintenance 
> > work to support IPv6 transition to the management of a commercial host 
> > operating systems vendor.
> >
> No. I am an academic network service provider and my goal is to provide 
> global IPv4/IPv6 Internet connectivity using an IPv6-only backbone and 
> very limited public IPv4 addresses. If the end system has the RFC6145 
> function, the subnet can be IPv6-only. If the end system does not have 
> the RFC6145 function, the subnet must be dual stack and the RFC6145 
> function is provided via access gateway (CPE).
 
RFC6333 + RFC6334 also allows the subnet to be IPv6 only.

> Regards,
> 
> xing
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Sun Apr 12 15:39: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 16DBA1B3917 for ; Sun, 12 Apr 2015 15:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.802
X-Spam-Level: ***
X-Spam-Status: No, score=3.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, 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 s3hw2yxTzED3 for ; Sun, 12 Apr 2015 15:39:47 -0700 (PDT)
Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539D31B3916 for ; Sun, 12 Apr 2015 15:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1428878386; bh=ErHNYDChAoq1o86Vf08UAB1H4eAs/HWRk2uloPMgByM=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=p0iZhzaOdCxa6VYnr1hJgM7ZkjR3VKhNo/wQkjNCOnFR2qYAGfwC0yoxGfxYS44LuQUEviH7PUgpIO3NO5K50en5hzrWFjoJWCfwxn6iwu1z/zv83z74MTlhc1BKaXnDcqdrPht7aLkOEP6qkUDEgmReopVRaA/AUjCbvJQhYbmUiUFT3jOJOzNbS5zB9UYn7l1m2bBWbE3v7jDO/r5/135XqhJaevk1Atxj0FzhlKTGSAz/zUUC5kXVmaoL6VMAfun6iOnSh/CoHfjLDk93ML7zHdyXBL4PXkPU3pAebnH8BHf73ZTnZrzEUb0/+tyz59asR1O04fjTf6L4Iochuw==
Received: from [66.196.81.170] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 12 Apr 2015 22:39:46 -0000
Received: from [98.139.215.253] by tm16.bullet.mail.bf1.yahoo.com with NNFMP;  12 Apr 2015 22:39:46 -0000
Received: from [127.0.0.1] by omp1066.mail.bf1.yahoo.com with NNFMP; 12 Apr 2015 22:39:46 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 249679.11730.bm@omp1066.mail.bf1.yahoo.com
Received: by 76.13.27.132; Sun, 12 Apr 2015 22:39:45 +0000 
Date: Sun, 12 Apr 2015 22:39:42 +0000 (UTC)
From: Mark ZZZ Smith 
To: Ray Hunter , Nick Hilliard 
Message-ID: <801876926.1700956.1428878382483.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <552A6E86.6030807@globis.net>
References: <552A6E86.6030807@globis.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1700955_637924751.1428878382479"
Archived-At: 
Cc: v6ops list , Philip Matthews 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 12 Apr 2015 22:39:49 -0000

------=_Part_1700955_637924751.1428878382479
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



      From: Ray Hunter 
 To: Nick Hilliard =20
Cc: "Ackermann, Michael" ; Mark ZZZ Smith ; Philip Matthews ; Fred Baker (f=
red) ; v6ops list =20
 Sent: Sunday, 12 April 2015, 23:09
 Subject: Re: Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
  =20
Nick Hilliard wrote:
 On 10/04/2015 16:42, Ackermann, Michael wrote:
=20
It seems that the advice to use Link Locals for next hop (or maybe even
to use them at all?),  is situationally dependent.

 Can you provide some concrete examples of where LLs are more appropriate
than GUAs for BGP NH, and why?  I'm genuinely struggling to see any advanta=
ge.

Nick



I have to say I'm with you. I only see disadvantages using LL for BGP: tied=
 to specific interface, tied to specific hardware, slow reconvergence.


/ I think it is important to distinguish between eBGP and iBGP use cases. S=
ome of the disadvantages of using LLs for iBGP would be advantages in eBGP.
/ I value predictability and robustness. Having a eBGP session very specifi=
cally tied to an interface tightly couples the eBGP session and the traffic=
 for the prefixes that eBGP session is announcing. The small amount of extr=
a effort required to change a session to a different interface creates furt=
her opportunity to catch errors. In some cases, the actual error might be m=
inor, but the consequences of them can be very significant outages.
/ LLs don't have to be tied to specific hardware addresses, they can be sta=
tically set if this is a concern, and hopefully in the future, RFC7217 will=
 be implemented for them in routers, as this is one of the specific use cas=
es for them.
/ I don't understand the slow reconvergence concern. LLs as BGP next hops c=
ould only be used when the next hop is directly reachable on the router rec=
eiving the route, otherwise the next hop is unreachable (and will stay that=
 way), which I think only makes LLs applicable to eBGP announced routes. If=
 LLs are being used for the eBGP session, then ND would have already resolv=
ed the link layer address by the time the routes were received over the eBG=
P session. So I can't see where there would be a slow reconvergence when us=
ing LLs (where they can be used.)
/ Regards,Mark.

=20
=C2=A0 
------=_Part_1700955_637924751.1428878382479
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




  
 
 
 
   From: Ray Hunter <v6ops@globis.net=
>
 To: Nick Hilliard=
 <nick@foobar.org> 
Cc: "Ackermann, Michael" <MAckermann@bcbsm.com>; Mark ZZZ Smith &l=
t;markzzzsmith@yahoo.com.au>; Philip Matthews <philip_matthews@magma.=
ca>; Fred Baker (fred) <fred@cisco.com>; v6ops list <v6ops@ietf=
.org> 
 Sent: Sunday=
, 12 April 2015, 23:09
 Subject: Re: Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
  
 

Nick Hilliard wrote:


  
On 10/04/2015 16:42, Ackerma=
nn, Michael wrote:


  
It seems that the advice to use Link =
Locals for next hop (or maybe even
to use them at all?),  is situationally dependent.


  
Can you provide some concret=
e examples of where LLs are more appropriate
than GUAs for BGP NH, and why?  I'm genuinely struggling to see any advanta=
ge.

Nick






I have to say I'm with you. I only see disadvantages using LL for BGP:=20
tied to specific inter=
face, tied to specific hardware, slow
 reconvergence.





/ I think it is important to distinguish between eBGP and=
 iBGP use cases. Some of the disadvantages of using LLs for iBGP would be a=
dvantages in eBGP.

/ I=
 value predictability and robustness. Having a eBGP session very specifical=
ly tied to an interface tightly couples the eBGP session and the traffic fo=
r the prefixes that eBGP session is announcing. The small amount of extra e=
ffort required to change a session to a different interface creates further=
 opportunity to catch errors. In some cases, the actual error might be mino=
r, but the consequences of them can be very significant outages.

/ LLs don't have to be tied to specific hardwar=
e addresses, they can be statically set if this is a concern, and hopefully=
 in the future, RFC7217 will be implemented for them in routers, as this is=
 one of the specific use cases for them.

/ =
I don't understand the slow reconvergence concern. LLs as BGP next hops cou=
ld only be used when the next hop is directly reachable on the router recei=
ving the route, otherwise the next hop is unreachable (and will stay that w=
ay), which I think only makes LLs applicable to eBGP announced routes. If L=
Ls are being used for the eBGP session, then ND would have already resolved=
 the link layer address by the time the routes were received over the eBGP =
session. So I can't see where there would be a slow reconvergence when usin=
g LLs (where they can be used.)

/ Regards,
Mark.

 

 
 
  
------=_Part_1700955_637924751.1428878382479--


From nobody Sun Apr 12 22:46: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 2E41B1B2D07 for ; Sun, 12 Apr 2015 22:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.268
X-Spam-Level: 
X-Spam-Status: No, score=-110.268 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, 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 0z2oe2cp3I4D for ; Sun, 12 Apr 2015 22:46:05 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288C31B2D05 for ; Sun, 12 Apr 2015 22:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1428903965; x=1430113565; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=dY4EEbeuUVXbs7MWjoPWtqaV86FaRHEjwnahytR49IPBF/CHbF0mif4X 2uscTIHBdKcte6Pi5ueGWJpSk2KDi4vexKC+hoXfMA5HWFby0fG3fYoAG F1y2Y344LuRcqGhxZ32bEAnisWiF9VluO85eCds8RTCWvWE/z8vrdtq19 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C5BQATVytV/5hdJa1cgwy3egGVcYEwOxEBAQEBAQEBfYQiIVw8NIkKActhAQEBAQYBAQEBAQEckCcdhBcFiy6RCoM3kBgihA+DEgEBAQ
X-IronPort-AV: E=Sophos;i="5.11,568,1422921600"; d="scan'208";a="140623028"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 13 Apr 2015 05:46:04 +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 t3D5k37k006958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2015 05:46: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 t3D5k18N022639; Sun, 12 Apr 2015 22:46:03 -0700
Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t3CI03dR022647; Sun, 12 Apr 2015 11:00:03 -0700
Date: Sun, 12 Apr 2015 11:00:03 -0700
From: fred@cisco.com
Message-Id: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com>
To: v6ops@ietf.org
Archived-At: 
Subject: [v6ops] draft-ietf-v6ops-design-choices 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, 13 Apr 2015 05:46: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 Sun Apr 12 23:40: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 C73E11B2DD2 for ; Sun, 12 Apr 2015 23:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_82=0.6, 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 XxV32vnK9R8n for ; Sun, 12 Apr 2015 23:39:58 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D675C1B2DD0 for ; Sun, 12 Apr 2015 23:39:57 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 33E30A1; Mon, 13 Apr 2015 08:39:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1428907195; bh=A+umRZEqGzb/zEqtrYvNG5SI1mPJPRZ9UT6xUEcKDu0=; h=Date:From:To:Subject:In-Reply-To:References:From; b=FdSjDr6BrQxTelP9l2ne4fuocTIbrDBkucePSiPqZwKLqqqWijLZNUdHFDBwPMkCS QKohlZoTRG1md0PxKSOYGOPR/KDolclM12zB6zy+zRIEZkCkM3CXQcVQOCcnEzVqnj AiBh7Z9tiOQyZA6sexvppASnV/PwmPI8DrQet9rQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2D5479F for ; Mon, 13 Apr 2015 08:39:55 +0200 (CEST)
Date: Mon, 13 Apr 2015 08:39:55 +0200 (CEST)
From: Mikael Abrahamsson 
To: v6ops@ietf.org
In-Reply-To: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com>
Message-ID: 
References: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 13 Apr 2015 06:39:59 -0000

On Sun, 12 Apr 2015, fred@cisco.com wrote:

> The working group last call for this draft announced last week
> continues for another week.  Please feel free to comment on it.

Re-reading it as if I never read it before:

2.1.2. Regarding using ULAs. I have run into one instance in reality where 
an ISP numbered an interface from ULAs on a VERY popular large router 
vendor device. This meant that PTBs were generated with a ULA source 
address. This is obviously totally broken, and I think text warning about 
this should be added. Numbering interfaces with ULA and LLA only means one 
has to make VERY SURE that PTBs and other ICMP messsages are not sourced 
from these ULA addresses if the intent is to use this outside of a private 
network. I also question how common it is to use ULAs, with current 
wording it seems to indicate that both are quite common, which I don't 
agree with.

2.2.1. I agree with this, so my suggestion is that the ULA reference above 
is removed or severely downplay:ed, otherwise last sentence in 2.2.1 needs 
to say GUA or ULA as next-hop address.

2.3.1. I have personally been involved in running ISIS for IPv4 and OSPFv3 
for IPv6 at the same time (option b), due to IPv6 related ISIS vendor bug. 
I don't see why this wouldn't be known to work well? This isn't something 
I feel strongly about though...


Apart from these relatively small points above, I think this document is 
in good shape, useful, and ready to proceed.



-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Apr 13 06:43: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 6FC561A03FF for ; Mon, 13 Apr 2015 06:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.926
X-Spam-Level: **
X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 VNBaooJv9zW8 for ; Mon, 13 Apr 2015 06:43:30 -0700 (PDT)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3010C1A036B for ; Mon, 13 Apr 2015 06:43:29 -0700 (PDT)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,570,1422939600";  d="scan'208,217";a="238212539"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Apr 2015 09:29:45 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 13 Apr 2015 09:43:28 -0400
From: "George, Wes" 
To: v6ops list 
Date: Mon, 13 Apr 2015 09:43:43 -0400
Thread-Topic: [v6ops] draft-ietf-v6ops-design-choices WGLC
Thread-Index: AdB179LMEEZX9nlKSsSl4ti6nCs03Q==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D151356F4D293wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: 
Cc: Philip Matthews 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 13 Apr 2015 13:43:32 -0000

--_000_D151356F4D293wesleygeorgetwcablecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXQncyBhIGxpdHRsZSB1bmNsZWFyIHdobyBzYWlkIHdoYXQgZ2l2ZW4gdGhlIHdheSB0ZXh0IHdh
cyBxdW90ZWQsIHNvIEknbSBqdXN0IHJlcGx5aW5nIHRvIHRoZSBzbmlwcGV0IG9mIHRleHQgSSB0
aGluayBpcyByZWxldmFudCBpbmxpbmUgYmVsb3cgd2l0aCBXR10sIGFuZCB0aGVuIGEgZmV3IG90
aGVyIExDIGNvbW1lbnRzIGZvbGxvdyBiZWxvdyBpdC4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQov
IEkgdmFsdWUgcHJlZGljdGFiaWxpdHkgYW5kIHJvYnVzdG5lc3MuIEhhdmluZyBhIGVCR1Agc2Vz
c2lvbiB2ZXJ5IHNwZWNpZmljYWxseSB0aWVkIHRvIGFuIGludGVyZmFjZSB0aWdodGx5IGNvdXBs
ZXMgdGhlIGVCR1Agc2Vzc2lvbiBhbmQgdGhlIHRyYWZmaWMgZm9yIHRoZSBwcmVmaXhlcyB0aGF0
IGVCR1Agc2Vzc2lvbiBpcyBhbm5vdW5jaW5nLiBUaGUgc21hbGwgYW1vdW50IG9mIGV4dHJhIGVm
Zm9ydCByZXF1aXJlZCB0byBjaGFuZ2UgYSBzZXNzaW9uIHRvIGEgZGlmZmVyZW50IGludGVyZmFj
ZSBjcmVhdGVzIGZ1cnRoZXIgb3Bwb3J0dW5pdHkgdG8gY2F0Y2ggZXJyb3JzLiBJbiBzb21lIGNh
c2VzLCB0aGUgYWN0dWFsIGVycm9yIG1pZ2h0IGJlIG1pbm9yLCBidXQgdGhlIGNvbnNlcXVlbmNl
cyBvZiB0aGVtIGNhbiBiZSB2ZXJ5IHNpZ25pZmljYW50IG91dGFnZXMuDQoNCldHXSBUaGF0IGlz
IHRydWUgd2hldGhlciB5b3UgdXNlIGEgTEwgb3IgYSBHVUEgaWYgeW91IHVzZSB0aGUgaW50ZXJm
YWNlIElQIGFkZHJlc3MgZm9yIGVCR1AgcGVlcmluZyBpbnN0ZWFkIG9mIGxvb3BiYWNrIG11bHRp
IGhvcC4gV2hhdCdzIHlvdXIgcG9pbnQgaW4gZmF2b3Igb2YgTExOIGhlcmU/IEFsc28sIHdoYXQg
ZXJyb3JzIGFyZSB5b3UgdGFsa2luZyBhYm91dCBjYXRjaGluZyB3aGVyZSBtb3JlIG1hbnVhbCBy
ZWNvbmZpZ3VyYXRpb24gaXMgdGhlIHJpZ2h0IGFuc3dlcj8NCg0KLyBMTHMgZG9uJ3QgaGF2ZSB0
byBiZSB0aWVkIHRvIHNwZWNpZmljIGhhcmR3YXJlIGFkZHJlc3NlcywgdGhleSBjYW4gYmUgc3Rh
dGljYWxseSBzZXQgaWYgdGhpcyBpcyBhIGNvbmNlcm4sIGFuZCBob3BlZnVsbHkgaW4gdGhlIGZ1
dHVyZSwgUkZDNzIxNyB3aWxsIGJlIGltcGxlbWVudGVkIGZvciB0aGVtIGluIHJvdXRlcnMsIGFz
IHRoaXMgaXMgb25lIG9mIHRoZSBzcGVjaWZpYyB1c2UgY2FzZXMgZm9yIHRoZW0uDQoNCldHXSBp
dCdzIHdvcnNlIHRoYW4gdGhhdC4gSWYgeW91IGRvbid0IHN0YXRpY2FsbHkgc2V0IExMIGFkZHJl
c3NlcywgdGhleSBkb24ndCBzaG93IHVwIGluIHRoZSBpbnRlcmZhY2UgY29uZmlndXJhdGlvbiwg
YW5kIGJlY2F1c2UgdGhleSdyZSBvbmx5IGxvY2FsbHkgc2lnbmlmaWNhbnQsIHlvdSBoYXZlIGFu
IGF3ZnVsIHRpbWUgaWYgeW91IHdhbnQgdG8gYWN0dWFsbHkgZmluZCB0aGUgcm91dGVyIG9yIGlu
dGVyZmFjZSB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgbmV4dC1ob3AgKHNheSB3aGVuIGNo
YXNpbmcgYSBuZXh0LWhvcCByZXdyaXRlIHByb2JsZW0pLCBiZWNhdXNlIHlvdSBjYW4ndCBmaW5k
IGl0IGluIHRoZSByb3V0aW5nIHRhYmxlLCBhbmQgeW91IGNhbid0IGdyZXAgdGhyb3VnaCBhIGNv
bmZpZyByZXBvc2l0b3J5IGZvciB0aGUgYWRkcmVzcywgYW5kIGl0IGxpa2VseSB3b24ndCBiZSBp
biBETlMuIFRoZSBjbG9zZXN0IHlvdSBtaWdodCBiZSBhYmxlIHRvIGdldCBpcyB0byBncmVwIGZv
ciB0aGUgYWRkcmVzcyBhbmQgZmluZCB0aGUgcm91dGVyIHdpdGggdGhlIG90aGVyIHNpZGUgb2Yg
dGhlIGlCR1Agc2Vzc2lvbiwgYnV0IHRoaXMgd29uJ3Qgd29yayBmb3IgZUJHUCBiZWNhdXNlIHRo
ZXJlIGlzIG5vIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBuZWlnaGJvciBhZGRyZXNzZXMgbGlr
ZSB0aGVyZSBpcyB3aXRoIEdVQSAoKzEgLyAtMSkuDQoNClBoaWxpcCB5b3UgbWF5IHdhbnQgdG8g
YWRkIHNvbWV0aGluZyBsaWtlIHRoaXMgaW4gMi40LjIgKG9yIGluIDIuMS4yIHNpbmNlIGl0J3Mg
bm90IGp1c3QgcmVsZXZhbnQgdG8gQkdQLikNCg0KT3RoZXIgY29tbWVudHM6DQpZb3UgbWF5IHdh
bnQgdG8gYWRkIGEgcmVmZXJlbmNlIHRvIFJGQyA3NDM5IGluIDIuNC4xIGxhc3QgYnVsbGV0IGFi
b3V0IE1QTFMgYW5kIElQdjYNCjIuNC4yOiA1OTI1IGlzIG5vdCBNRDUuIEl0IG9ic29sZXRlZCBN
RDUsIGJ1dCBpdCBpcyBwcm9wZXJseSByZWZlcnJlZCB0byBhcyBUQ1AgQU8sIHNvIGl0J2QgYmUg
YmV0dGVyIHRvIHNheSAiTUQ1IChSRkMyMzg1KSwgd2hpY2ggd2hpbGUgc3RpbGwgaW4gd2lkZSB1
c2UsIGhhcyBiZWVuIG9ic29sZXRlZCBieSBUQ1AgQU8gKFJGQzU5MjUpIg0KDQoNCg0KQW55dGhp
bmcgYmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwg
c2VydmVyLCBJIGhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMg
YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5m
b3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0
byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBp
cyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5
IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl
Y2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkg
ZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4g
cmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFp
bCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZl
IHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg
aW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBj
b3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo=

--_000_D151356F4D293wesleygeorgetwcablecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdiBzdHlsZT0iZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pkl0J3MgYSBsaXR0
bGUgdW5jbGVhciB3aG8gc2FpZCB3aGF0IGdpdmVuIHRoZSB3YXkgdGV4dCB3YXMgcXVvdGVkLCBz
byBJJ20ganVzdCByZXBseWluZyB0byB0aGUgc25pcHBldCBvZiB0ZXh0IEkgdGhpbmsgaXMgcmVs
ZXZhbnQgaW5saW5lIGJlbG93IHdpdGggV0ddLCBhbmQgdGhlbiBhIGZldyBvdGhlciBMQyBjb21t
ZW50cyBmb2xsb3cgYmVsb3cgaXQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt
c2l6ZTogMTFwdDsiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+V2VzPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp
emU6IDExcHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxicj4NCjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP
TiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmb250LXNpemU6IDE2cHg7Ij4NCjxkaXYgc3R5bGU9
ImZvbnQtc2l6ZTogMTZweDsiIGlkPSJ5dWlfM18xNl8wXzFfMTQyODg3NjI1ODc2Nl8zMTAxMCI+
DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE2cHg7IiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg4NzYy
NTg3NjZfMzEwMDkiPg0KPGRpdiBjbGFzcz0ieV9tc2dfY29udGFpbmVyIiBpZD0ieXVpXzNfMTZf
MF8xXzE0Mjg4NzYyNTg3NjZfMzEwNTkiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl
bHZldGljYU5ldWUsICdIZWx2ZXRpY2EgTmV1ZScsIEhlbHZldGljYSwgQXJpYWwsICdMdWNpZGEg
R3JhbmRlJywgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnSGVsdmV0
aWNhIE5ldWUtTGlnaHQnLCAnSGVsdmV0aWNhIE5ldWUgTGlnaHQnLCAnSGVsdmV0aWNhIE5ldWUn
LCBIZWx2ZXRpY2EsIEFyaWFsLCAnTHVjaWRhIEdyYW5kZScsIHNhbnMtc2VyaWY7IiBjbGFzcz0i
IiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg4NzYyNTg3NjZfMzEwNzYiPi8gSSB2YWx1ZSBwcmVkaWN0
YWJpbGl0eSBhbmQgcm9idXN0bmVzcy4gSGF2aW5nIGEgZUJHUCBzZXNzaW9uIHZlcnkgc3BlY2lm
aWNhbGx5DQogdGllZCB0byBhbiBpbnRlcmZhY2UgdGlnaHRseSBjb3VwbGVzIHRoZSBlQkdQIHNl
c3Npb24gYW5kIHRoZSB0cmFmZmljIGZvciB0aGUgcHJlZml4ZXMgdGhhdCBlQkdQIHNlc3Npb24g
aXMgYW5ub3VuY2luZy4gVGhlIHNtYWxsIGFtb3VudCBvZiBleHRyYSBlZmZvcnQgcmVxdWlyZWQg
dG8gY2hhbmdlIGEgc2Vzc2lvbiB0byBhIGRpZmZlcmVudCBpbnRlcmZhY2UgY3JlYXRlcyBmdXJ0
aGVyIG9wcG9ydHVuaXR5IHRvIGNhdGNoIGVycm9ycy4gSW4gc29tZQ0KIGNhc2VzLCB0aGUgYWN0
dWFsIGVycm9yIG1pZ2h0IGJlIG1pbm9yLCBidXQgdGhlIGNvbnNlcXVlbmNlcyBvZiB0aGVtIGNh
biBiZSB2ZXJ5IHNpZ25pZmljYW50IG91dGFnZXMuPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XR10g
VGhhdCBpcyB0cnVlIHdoZXRoZXIgeW91IHVzZSBhIExMIG9yIGEgR1VBIGlmIHlvdSB1c2UgdGhl
IGludGVyZmFjZSBJUCBhZGRyZXNzIGZvciBlQkdQIHBlZXJpbmcgaW5zdGVhZCBvZiBsb29wYmFj
ayBtdWx0aSBob3AuIFdoYXQncyB5b3VyIHBvaW50IGluIGZhdm9yIG9mIExMTiBoZXJlPyBBbHNv
LCB3aGF0IGVycm9ycyBhcmUgeW91IHRhbGtpbmcgYWJvdXQgY2F0Y2hpbmcgd2hlcmUNCjxzcGFu
IHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPm1vcmU8L3NwYW4+Jm5ic3A7bWFudWFsIHJlY29u
ZmlndXJhdGlvbiBpcyB0aGUgcmlnaHQgYW5zd2VyPzwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf
Qk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBi
YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGZvbnQtc2l6ZTogMTZweDsiPg0K
PGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNnB4OyIgaWQ9Inl1aV8zXzE2XzBfMV8xNDI4ODc2MjU4
NzY2XzMxMDEwIj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTZweDsiIGlkPSJ5dWlfM18xNl8w
XzFfMTQyODg3NjI1ODc2Nl8zMTAwOSI+DQo8ZGl2IGNsYXNzPSJ5X21zZ19jb250YWluZXIiIGlk
PSJ5dWlfM18xNl8wXzFfMTQyODg3NjI1ODc2Nl8zMTA1OSIgZGlyPSJsdHIiIHN0eWxlPSJmb250
LWZhbWlseTogJ0hlbHZldGljYSBOZXVlLUxpZ2h0JywgJ0hlbHZldGljYSBOZXVlIExpZ2h0Jywg
J0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCBBcmlhbCwgJ0x1Y2lkYSBHcmFuZGUnLCBzYW5z
LXNlcmlmOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InlfbXNnX2NvbnRhaW5lciIgaWQ9
Inl1aV8zXzE2XzBfMV8xNDI4ODc2MjU4NzY2XzMxMDU5IiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQt
ZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUtTGlnaHQnLCAnSGVsdmV0aWNhIE5ldWUgTGlnaHQnLCAn
SGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsIEFyaWFsLCAnTHVjaWRhIEdyYW5kZScsIHNhbnMt
c2VyaWY7Ij4NCi8gTExzIGRvbid0IGhhdmUgdG8gYmUgdGllZCB0byBzcGVjaWZpYyBoYXJkd2Fy
ZSBhZGRyZXNzZXMsIHRoZXkgY2FuIGJlIHN0YXRpY2FsbHkgc2V0IGlmIHRoaXMgaXMgYSBjb25j
ZXJuLCBhbmQgaG9wZWZ1bGx5IGluIHRoZSBmdXR1cmUsIFJGQzcyMTcgd2lsbCBiZSBpbXBsZW1l
bnRlZCBmb3IgdGhlbSBpbiByb3V0ZXJzLCBhcyB0aGlzIGlzIG9uZSBvZiB0aGUgc3BlY2lmaWMg
dXNlIGNhc2VzIGZvciB0aGVtLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XR10gaXQncyB3b3JzZSB0aGFuIHRo
YXQuIElmIHlvdSBkb24ndCBzdGF0aWNhbGx5IHNldCBMTCBhZGRyZXNzZXMsIHRoZXkgZG9uJ3Qg
c2hvdyB1cCBpbiB0aGUgaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24sIGFuZCBiZWNhdXNlIHRoZXkn
cmUgb25seSBsb2NhbGx5IHNpZ25pZmljYW50LCB5b3UgaGF2ZSBhbiBhd2Z1bCB0aW1lIGlmIHlv
dSB3YW50IHRvIGFjdHVhbGx5IGZpbmQgdGhlIHJvdXRlciBvciBpbnRlcmZhY2UgdGhhdCBpcyBh
c3NvY2lhdGVkDQogd2l0aCB0aGUgbmV4dC1ob3AgKHNheSB3aGVuIGNoYXNpbmcgYSBuZXh0LWhv
cCByZXdyaXRlIHByb2JsZW0pLCBiZWNhdXNlIHlvdSBjYW4ndCBmaW5kIGl0IGluIHRoZSByb3V0
aW5nIHRhYmxlLCBhbmQgeW91IGNhbid0IGdyZXAgdGhyb3VnaCBhIGNvbmZpZyByZXBvc2l0b3J5
IGZvciB0aGUgYWRkcmVzcywgYW5kIGl0IGxpa2VseSB3b24ndCBiZSBpbiBETlMuIFRoZSBjbG9z
ZXN0IHlvdSBtaWdodCBiZSBhYmxlIHRvIGdldCBpcyB0byBncmVwDQogZm9yIHRoZSBhZGRyZXNz
IGFuZCBmaW5kIHRoZSByb3V0ZXIgd2l0aCB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgaUJHUCBzZXNz
aW9uLCBidXQgdGhpcyB3b24ndCB3b3JrIGZvciBlQkdQIGJlY2F1c2UgdGhlcmUgaXMgbm8gcmVs
YXRpb25zaGlwIGJldHdlZW4gdGhlIG5laWdoYm9yIGFkZHJlc3NlcyBsaWtlIHRoZXJlIGlzIHdp
dGggR1VBICgmIzQzOzEgLyAtMSkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QaGls
aXAgeW91IG1heSB3YW50IHRvIGFkZCBzb21ldGhpbmcgbGlrZSB0aGlzIGluIDIuNC4yIChvciBp
biAyLjEuMiBzaW5jZSBpdCdzIG5vdCBqdXN0IHJlbGV2YW50IHRvIEJHUC4pPC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj5PdGhlciBjb21tZW50czombmJzcDs8L2Rpdj4NCjxkaXY+WW91
IG1heSB3YW50IHRvIGFkZCBhIHJlZmVyZW5jZSB0byBSRkMgNzQzOSBpbiAyLjQuMSBsYXN0IGJ1
bGxldCBhYm91dCBNUExTIGFuZCBJUHY2PC9kaXY+DQo8ZGl2PjIuNC4yOiA1OTI1IGlzIG5vdCBN
RDUuIEl0IG9ic29sZXRlZCBNRDUsIGJ1dCBpdCBpcyBwcm9wZXJseSByZWZlcnJlZCB0byBhcyBU
Q1AgQU8sIHNvIGl0J2QgYmUgYmV0dGVyIHRvIHNheSAmcXVvdDtNRDUgKFJGQzIzODUpLCB3aGlj
aCB3aGlsZSBzdGlsbCBpbiB3aWRlIHVzZSwgaGFzIGJlZW4gb2Jzb2xldGVkIGJ5IFRDUCBBTyAo
UkZDNTkyNSkmcXVvdDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiBy
Z2IoMTI3LCAxMjcsIDEyNyk7Ij5Bbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRk
ZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkgaGF2ZSBubyBjb250cm9sIG92ZXIg
aXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNv
bG9yOiByZ2IoMTI3LCAxMjcsIDEyNyk7Ij4tLS0tLS0tLS0tLTwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48
c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsiPjxicj4NCjwvc3Bhbj48L2Rp
dj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+
VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBX
YXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQs
IGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUg
V2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCiBmb3IgdGhlIHVz
ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJ
ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3Ug
YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24s
IGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2Yg
YW5kIGF0dGFjaG1lbnRzIHRvDQogdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBh
bmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBl
cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRs
eSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55
IHByaW50b3V0Ljxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D151356F4D293wesleygeorgetwcablecom_--


From nobody Mon Apr 13 07:35: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 299461AC415 for ; Mon, 13 Apr 2015 07:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNf6dxUGv8zp for ; Mon, 13 Apr 2015 07:35:21 -0700 (PDT)
Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 D24A01AC3FF for ; Mon, 13 Apr 2015 07:35:20 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id E9A60102D4B for ; Mon, 13 Apr 2015 09:35:18 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id AF7F913381B; Mon, 13 Apr 2015 09:35:17 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 47A252F5353; Mon, 13 Apr 2015 10:32:13 -0400 (EDT)
Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id 37FFC2F532D; Mon, 13 Apr 2015 10:32:13 -0400 (EDT)
Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([::1]) with mapi id 14.01.0438.000;  Mon, 13 Apr 2015 10:35:16 -0400
From: "Ackermann, Michael" 
To: Philip Matthews 
Thread-Topic: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC
Thread-Index: AdBwejVZflkIuUqSRyO7yHiQggoOUQBQBUQAADGQMIAAFEHyUAAKlbwAAAe2V4AAA8flgAADhMYAABpqfEAADADhAAAF+U9g///5cYCAAE62AP/8LbDQ
Date: Mon, 13 Apr 2015 14:34:59 +0000
Message-ID: <4FC37E442D05A748896589E468752CAA0CDB1C6F@PWN401EA160.ent.corp.bcbsm.com>
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com> <5528021E.3010500@foobar.org> <4FC37E442D05A748896589E468752CAA0CDB10E8@PWN401EA160.ent.corp.bcbsm.com> <552824B5.3050503@foobar.org> <55935A5C-84BE-4551-81A6-4EFE8690F6A0@magma.ca>
In-Reply-To: <55935A5C-84BE-4551-81A6-4EFE8690F6A0@magma.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.10.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-VPM-HOST: vmvpm01.z120.zixworks.com
X-VPM-GROUP-ID: 8241568f-f959-42e1-8359-de1845deafbd
X-VPM-MSG-ID: 6b304841-9188-409f-973d-cadafebbdf0e
X-VPM-ENC-REGIME: Plaintext
X-VPM-CERT-FLAG: 0
X-VPM-IS-HYBRID: 0
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 13 Apr 2015 14:35:23 -0000

Thanks Phillip

Yes, this document will be very helpful to those of us just beginning to =
deploy IPv6.  =20

Most of the very recent dialogue has centered around LL and BGP.   We do =
not use BGP, so I will be listening intently, but may not have much to =
comment on that specific  facet.=20

Thanks again

Mike



-----Original Message-----
From: Philip Matthews =5Bmailto:philip_matthews=40magma.ca=5D=20
Sent: Friday, April 10, 2015 8:12 PM
To: Ackermann, Michael
Cc: v6ops list; Nick Hilliard; Mark ZZZ Smith; Fred Baker (fred)
Subject: Re: =5Bv6ops=5D draIn ft-ietf-v6ops-design-choices WGLC

Michael:

I am following this conversation with interest, especially since you seem =
to be new to IPv6 network design, and thus are exactly the intended =
audience for this draft.

The questions you are coming up with seem to be very similar to the ones I =
had when I first started doing IPv6 network design.  Those questions later =
prompted me to start the draft.

So far, I have not seen anything new in this conversation to add to the =
draft, but it could well be that I am suffering from =22document =
fatigue=22. You, on the other hand, are reading it with fresh eyes and may =
well see things that I just miss.

I encourage you and everyone else on this thread to send me any =
suggestions you have for improving the document.

- Philip

On 2015-04-10, at 15:29 , Nick Hilliard wrote:

> On 10/04/2015 19:11, Ackermann, Michael wrote:
>> I do not see any advantage in a BGP environment. =20
>=20
> Ok, sure.
>=20
> Can you now provide some concrete examples of where LLs are more=20
> appropriate than GUAs for BGP NH, and why?
>=20
> Nick
>=20
>> -----Original Message-----
>> From: Nick Hilliard =5Bmailto:nick=40foobar.org=5D
>> Sent: Friday, April 10, 2015 1:02 PM
>> To: Ackermann, Michael; Mark ZZZ Smith; Philip Matthews; Fred Baker=20
>> (fred)
>> Cc: v6ops list
>> Subject: Re: =5Bv6ops=5D draIn ft-ietf-v6ops-design-choices WGLC
>>=20
>> On 10/04/2015 16:42, Ackermann, Michael wrote:
>>> It seems that the advice to use Link Locals for next hop (or maybe=20
>>> even to use them at all?),  is situationally dependent.
>>=20
>> Can you provide some concrete examples of where LLs are more =
appropriate than GUAs for BGP NH, and why?  I'm genuinely struggling to =
see any advantage.
>>=20
>> Nick
>>=20
>>=20
>> The information contained in this communication is highly confidential =
and is intended solely for the use of the individual(s) to whom this =
communication is directed. If you are not the intended recipient, you are =
hereby notified that any viewing, copying, disclosure or distribution of =
this information is prohibited. Please notify the sender, by electronic =
mail or telephone, of any unintended receipt and delete the original =
message without making any copies.
>>=20
>> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan =
are nonprofit corporations and independent licensees of the Blue Cross and =
Blue Shield Association.
>>=20
>=20
>=20



The information contained in this communication is highly confidential and =
is intended solely for the use of the individual(s) to whom this =
communication is directed. If you are not the intended recipient, you are =
hereby notified that any viewing, copying, disclosure or distribution of =
this information is prohibited. Please notify the sender, by electronic =
mail or telephone, of any unintended receipt and delete the original =
message without making any copies.
=20
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are =
nonprofit corporations and independent licensees of the Blue Cross and =
Blue Shield Association.


From nobody Mon Apr 13 12:22: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 76D491B3203 for ; Mon, 13 Apr 2015 12:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.521
X-Spam-Level: 
X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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] 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 2KDpaL3q4HSA for ; Mon, 13 Apr 2015 12:22:21 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 EAAC51B320A for ; Mon, 13 Apr 2015 12:21:22 -0700 (PDT)
Received: by wiun10 with SMTP id n10so78841602wiu.1 for ; Mon, 13 Apr 2015 12:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yJhDT8kvm46Q9jAvF7OPPQt04/1QWjuYaCd5028ZPB4=; b=BA88YcJ2SGVotP7FJNIHT0Hla/hxHLIUf7rhYh73KtGOMBxG77jYfBhMa/lsFDiOtM YJ6vuj/fDap+C3QKcLe2asa9f0/yvsYcoZq9ZejiE/93AbIU0oX6hIu8ksTmq5GKjk1T 12cWRKg48E7R+YU3rHrgHyJiuVq1nxnGs6ZHc=
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=yJhDT8kvm46Q9jAvF7OPPQt04/1QWjuYaCd5028ZPB4=; b=gN8jLEWu+TFgpXhKeRYxNFDVLdH3ShBV8PU8ANzQBeH2RSeZqgt4GEMfgzN1SchIC9 MNBFLXxfpwBmU5I3hBBcDSNL89sVYN8VxXY8l7tqCOsnpKvIVuhj6ZGKCXJ7Lkeuma4h tOkCRIHq5tSKDj5CUF6sTcUdMs6iGJdC8MYSeHuNIxivAL9ec74HlxRQqPtPHhz7Wl5F /z5/Vcws9y58dFn2tx19t6YGTXF3uyqXIRhJEvaooEUHJnzvIbmjow5WmSHRErzUxGSV QkxXuXewPoQilPBNt4ax/2kz1R5JVHGKFKzm+0q3bjMsK5iUjSBOgh7zVSakcMSqne2F PArA==
X-Gm-Message-State: ALoCoQld4kxpEfIx+eRdQdhWqaVbkUnPeEZK4o5DOkjuyNOhnb4aC+vwR6eJj1b+COiR76c/Nxfr
MIME-Version: 1.0
X-Received: by 10.194.71.208 with SMTP id x16mr29696119wju.129.1428952881545;  Mon, 13 Apr 2015 12:21:21 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Mon, 13 Apr 2015 12:21:21 -0700 (PDT)
In-Reply-To: <55290E26.8080500@cernet.edu.cn>
References:            <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>
Date: Mon, 13 Apr 2015 12:21:21 -0700
Message-ID: 
From: James Woodyatt 
To: Xing Li 
Content-Type: multipart/alternative; boundary=047d7bfcead0e7dba80513a0042e
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 13 Apr 2015 19:22:22 -0000

--047d7bfcead0e7dba80513a0042e
Content-Type: text/plain; charset=UTF-8

On Sat, Apr 11, 2015 at 5:05 AM, Xing Li  wrote:

>  No. I am an academic network service provider and my goal is to provide
> global IPv4/IPv6 Internet connectivity using an IPv6-only backbone and very
> limited public IPv4 addresses.
>

I can understand the goal of providing service on your networks to global
IPv4 and IPv6 destinations, and I can understand how you may be limited by
the scarcity of public IPv4 address space, but I fail to see either A) how
that goal is best achieved by removing IPv4 service from your local
network, or B) how the negative effects of scarcity in public IPv4 space is
mitigated by the deployment of a CLAT in host operating systems.

>From my perspective, deploying a CLAT ubiquitously in host operating
systems will have two deleterious effects: 1) it will prolong the viability
of IPv4 literals in publicly reachable application services, requiring the
maintenance of the PLAT service, and the public IPv4 routing that entails,
over a longer period of transition, possibly indefinitely; and, 2) it will
slow the transition of applications in your local network to using IPv6
instead of IPv4, because the IPv4-only legacy interfaces will still be a
viable, if somewhat impaired, despite your having removed IPv4 routing from
local subnets.

I would think the negatives of this plan would obviously outweigh the
positives. On the plus side: you get to deploy a nice clean IPv6-only
network that nobody knows is IPv6-only. On the minus side: you may never
get to stop supporting IPv4 in the applications and the hosts, because if
you ever do, the users will howl about it, and this you cannot abide. I
would think it better to just decide you can't ever live without IPv4 and
commit yourself to running dual-stack forever.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--047d7bfcead0e7dba80513a0042e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
at, Apr 11, 2015 at 5:05 AM, Xing Li <xing@cernet.edu.cn> w=
rote:



 =20
 =20


No. I am an academic network serv=
ice provider and my goal is to provide
global IPv4/IPv6 Internet connectivity using an IPv6-only backbone and
very limited public IPv4 addresses.

I=
 can understand the goal of providing service on your networks to global IP=
v4 and IPv6 destinations, and I can understand how you may be limited by th=
e scarcity of public IPv4 address space, but I fail to see either A) how th=
at goal is best achieved by removing IPv4 service from your local network, =
or B) how the negative effects of scarcity in public IPv4 space is mitigate=
d by the deployment of a CLAT in host operating systems.

=

From my perspective, deploying a CLAT ubiquitously in host opera=
ting systems will have two deleterious effects: 1) it will prolong the viab=
ility of IPv4 literals in publicly reachable application services, requirin=
g the maintenance of the PLAT service, and the public IPv4 routing that ent=
ails, over a longer period of transition, possibly indefinitely; and, 2) it=
 will slow the transition of applications in your local network to using IP=
v6 instead of IPv4, because the IPv4-only legacy interfaces will still be a=
 viable, if somewhat impaired, despite your having removed IPv4 routing fro=
m local subnets.

I would think the negatives of th=
is plan would obviously outweigh the positives. On the plus side: you get t=
o deploy a nice clean IPv6-only network that nobody knows is IPv6-only. On =
the minus side: you may never get to stop supporting IPv4 in the applicatio=
ns and the hosts, because if you ever do, the users will howl about it, and=
 this you cannot abide. I would think it better to just decide you can'=
t ever live without IPv4 and commit yourself to running dual-stack forever.=



-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Comm=
unications Engineering




--047d7bfcead0e7dba80513a0042e--


From nobody Mon Apr 13 16:58: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 D73971B29E7; Mon, 13 Apr 2015 16:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -113.1
X-Spam-Level: 
X-Spam-Status: No, score=-113.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 jSge0bBy4gsG; Mon, 13 Apr 2015 16:58:21 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C001F1B29E2; Mon, 13 Apr 2015 16:57:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51478; q=dns/txt; s=iport; t=1428969473; x=1430179073; h=from:to:cc:subject:date:message-id:mime-version; bh=Oh+WKm0+n79GMtIe1k3DnsgJS2tE9/CphvxLi42noWY=; b=UWcQ+vlS2V9kDGmRENxIQtYX84HAlNcFdh2OHDZBbRqvDoxJTRzlGQZV lX9K7KhhFoH6znmjXhU/1JPQiVstaaLF5CXgqm+42SjnwdlqGi/WVo6dA psCfMei9tNfbrk1I+I5Ew2VnVEMeZUnn02Cs5cQ6SBXbLYXjS075XAva7 o=;
X-Files: v6ops-fred2-charter.txt, Diff_ v6ops-charter-old.txt - v6ops-fred2-charter.txt.html : 3444, 30466
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOBQBmVyxV/4ENJK1SCoMMUlwFgxCCCMFPhgEegSRMAQEBAQEBfoQiBCMKRwUSAUABCQIEMCcEDhMGB4gPDbZylhgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiiyFGAYLAVGCby+BFgWGWYgIgiuBboEzWIYWgR06hjyFT4M9g00igVuCFHCBCjl/AQEB
X-IronPort-AV: E=Sophos;i="5.11,573,1422921600";  d="txt'?html'217?scan'217,208,217";a="411548737"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 13 Apr 2015 23:57:52 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3DNvqoH003293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 23:57:52 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.151]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 18:57:52 -0500
From: "Fred Baker (fred)" 
To: IPv6 Ops WG 
Thread-Topic: v6ops charter update discussion
Thread-Index: AQHQdkWm8ikSWPZ7MU+dYPCm4QvW9g==
Date: Mon, 13 Apr 2015 23:57:52 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.68.220.154]
Content-Type: multipart/mixed; boundary="_003_AD667352663E4333ACFD2BA0919482E0ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: [v6ops] v6ops charter update discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 23:58:25 -0000

--_003_AD667352663E4333ACFD2BA0919482E0ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-ID: <2E3504B7AF2D084FBA9DB999E8CE6EF1@emea.cisco.com>
Content-Transfer-Encoding: base64

TGVlIGFuZCBJIGFyZSByZXZpZXdpbmcgdGhlIHY2b3BzIGNoYXJ0ZXIuIEkgaGF2ZSBhdHRhY2hl
ZCBhIHByb3Bvc2VkIGNoYXJ0ZXIgYW5kIGRpZmZzIGFnYWluc3QgdGhlIGN1cnJlbnQgb25lLiBK
b2VsIGhhcyBub3QgY29tbWVudGVkIG9uIHRoaXMgeWV0LCBhbmQgd2hpbGUgd2UgaGF2ZSBydW4g
aXQgYnkgdGhlIHN1bnNldDQgY2hhaXJzLCB3ZSBoYXZlbuKAmXQgZ290dGVuIGEgcmVhZGluZyBm
cm9tIHRoZW0uIFN1bnNldDQgaXMgcmVsZXZhbnQgYmVjYXVzZSBwb3NzaWJseSB0aGUgaXB2NC1h
cy1hLXNlcnZpY2UgZGlzY3Vzc2lvbiB3b3VsZCBiZSBiZXR0ZXIgaGFuZGxlZCB0aGVyZS4gSW4g
dGhpcyBlbWFpbCwgSeKAmW0gc29saWNpdGluZyBvcGluaW9ucyBpbiBnZW5lcmFsLg0KDQpUaGUg
Y2hhcnRlciB1cGRhdGUgc3RhcnRlZCB3aXRoIExlZSBmZWVsaW5nIHRoYXQgdGhlIGZvdXJ0aCBi
dWxsZXQgb2Ygb3VyIGN1cnJlbnQgY2hhcnRlciwgd2hpY2ggcmVhZHMNCiAgICA0LiBQdWJsaXNo
IEluZm9ybWF0aW9uYWwgb3IgQkNQIFJGQ3MgdGhhdCBpZGVudGlmeSBhbmQgYW5hbHl6ZSANCiAg
ICAgICBzb2x1dGlvbnMgZm9yIGRlcGxveWluZyBJUHY2IHdpdGhpbiBjb21tb24gbmV0d29yayBl
bnZpcm9ubWVudHMsDQogICAgICAgc3VjaCBhcyBJU1AgTmV0d29ya3MsIEVudGVycHJpc2UgTmV0
d29ya3MsIFVubWFuYWdlZCBOZXR3b3Jrcw0KICAgICAgIChIb21lL1NtYWxsIE9mZmljZSksIGFu
ZCBDZWxsdWxhciBOZXR3b3Jrcy4NCiAgICAgICAoaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn
L3dnL3Y2b3BzL2NoYXJ0ZXIvKQ0KaXMgbGFyZ2VseSBkb25lLiBXZSBrbm93IGhvdyB0byBkZXBs
b3kgSVB2Ni4NCg0KSW4gYWRkaXRpb24sIEkgdGhpbmsgd2UgbmVlZCwgY29sbGVjdGl2ZWx5LCB0
byBmaWd1cmUgb3V0IGhvdyB0byBnZXQgdG8gSVB2Ni1vbmx5LiBBIGxhcmdlIGlzc3VlIGlzIOKA
nHNvIGhvdyBkbyB3ZSBjb25uZWN0IHRvIElQdjQgY29udGVudCBhbmQgc2VydmljZXMgZnJvbSBh
biBJUHY2LW9ubHkgbmV0d29ya+KAnSwgd2hpY2ggaXMgd2hlcmUgaXB2NC1hcy1hLXNlcnZpY2Ug
Y29tZXMgaW4uIEkgcHJvcG9zZSBhZGRpbmcgYSBidWxsZXQgaXRlbSByZWdhcmRpbmcgYSByb2Fk
IG1hcCB0byBJUHY2LW9ubHkuDQoNCiAgICA0LiBEZXNjcmliZSBhbiBvcGVyYXRpb25hbCByb2Fk
bWFwIHRvIElQdjYtb25seSBuZXR3b3JrIGRlcGxveW1lbnQsIA0KICAgICAgIHdpdGggb3Igd2l0
aG91dCBJUHY0IGRlbGl2ZXJlZCBhcyBhbiBvdmVybGF5IG9yIHRyYW5zbGF0aW9uDQogICAgICAg
c2VydmljZS4NCg0KSW4gbXkgbWluZCwgdGhhdCBpbmNsdWRlcyBvcGVyYXRpb25hbCBkaXNjdXNz
aW9ucyBvZiBkZXBsb3ltZW50cyBhbmQgZGVwbG95bWVudCBpc3N1ZXMgaW4gSVB2NC1hcy1hLXNl
cnZpY2U7IG9uZSBwb3NzaWJsZSB1cGRhdGUgd291bGQgYmUgdG8gbWFrZSB0aGF0IG1vcmUgZXhw
bGljaXQuDQoNCkluIG90aGVyIHJlc3BlY3RzLCB0aGUgdXBkYXRlIGlzIG1vc3RseSBlZGl0b3Jp
YWwuDQoNClRoZSBvdGhlciB0aHJlZSB0YXNrcyByZW1haW4gdW5jaGFuZ2VkIC0gY29sbGVjdCBv
cGVyYXRpb25hbCBleHBlcmllbmNlLCBpZGVudGlmeSBvcGVyYXRpb25hbCBhbmQgc2VjdXJpdHkg
cmlza3MsIGFuZCB0dXJuIHRoZW0gb3ZlciB0byBvdGhlciB3b3JraW5nIGdyb3VwcyAtIG5vdGFi
bHkgNm1hbi4NCg0KSG9waW5nIGZvciB5b3VyIGlucHV0LiBEbyB5b3UgYWdyZWUgd2l0aCB0aGVz
ZSBjaGFuZ2VzPyBJZiBub3QsIHdoYXQgY2hhbmdlcywgb3IgZnVydGhlciBjaGFuZ2VzLCB3b3Vs
ZCB5b3UgcmVjb21tZW5kPyANCg0KQXMgdG8gcHJvcG9zZWQgbWlsZXN0b25lcywgSeKAmWQgbGlr
ZSB0byBiZWxpZXZlIHRoYXQgDQoNCnRoZXNlIGFyZSBkb25lOg0KICAgZHJhZnQtaWV0Zi12Nm9w
cy02dG80LXRvLWhpc3RvcmljDQogICBkcmFmdC1pZXRmLXY2b3BzLWNpZHItcHJlZml4DQoNCndl
IGNhbiBmaW5hbGl6ZSBhbmQgc2hpcCB0aGVzZSBieSBKdWx5Og0KICAgZHJhZnQtaWV0Zi12Nm9w
cy1kZXNpZ24tY2hvaWNlcw0KICAgZHJhZnQtaWV0Zi12Nm9wcy1wbXR1ZC1lY21wLXByb2JsZW0N
Cg0KYW5kIHRoZXNlIGJ5IE5vdmVtYmVyOg0KICAgZHJhZnQtaWV0Zi12Nm9wcy1zaWl0LWRjLSoN
CiAgICh3b3VsZCBsaWtlIGEgZGVwbG95bWVudCByZXBvcnQgZm9yIHNpaXQtZGMgYW5kIHNpaXQt
ZGMtMnhsYXQgaW4gc3VwcG9ydCkNCiAgICh3b3VsZCBsaWtlIG9uZSBmb3IgNDY0eGxhdCBhcyB3
ZWxsKQ0KDQpPbiBhbm90aGVyIHBvaW50LCBMZWUgYW5kIEkgaGF2ZSBiZWVuIGRpc2N1c3Npbmcg
dGhlIG9wZXJhdGlvbmFsIHJlcG9ydHMgd2UgaGFkIGF0IElFVEYgOTIsIGFuZCBmZWVsIHRoYXQg
d2FzIHRpbWUgd2VsbCBzcGVudC4gVGhvc2UgaGFkIGEgY29tbW9uIHRocmVhZCwgd2hpY2ggd2Fz
IHRoZSBkZXBsb3ltZW50IG9mIFNvZnR3aXJl4oCZcyBNQVAtRSBhbmQgTUFQLVQgdGVjaG5vbG9n
aWVzIGluIHRoZWlyIG5ldHdvcmtzLiBXZSBhcmUgdGhpbmtpbmcgYWJvdXQgYXNraW5nIGNvbXBh
bmllcyBkZXBsb3lpbmcgSVB2NiBpbiBFdXJvcGUsIEFzaWEsIGFuZCBTb3V0aCBBbWVyaWNhIHRv
IG1ha2UgcmVwb3J0cyBpbiB0aGUgY29taW5nIHRocmVlIG1lZXRpbmdzLCBvbiB0aGVpciBJUHY2
IGRlcGxveW1lbnRzIGFuZCB0aGUgaXNzdWVzIHRoZXkgZmFjZS4gV291bGQgdGhhdCBiZSBvZiBn
ZW5lcmFsIGludGVyZXN0PyBIb3cgd291bGQgeW91IHByb3Bvc2UgdG8gdHVuZSB0aGF0IGNvbmNl
cHQ/DQoNCg==

--_003_AD667352663E4333ACFD2BA0919482E0ciscocom_
Content-Type: text/plain; name="v6ops-fred2-charter.txt"
Content-Description: v6ops-fred2-charter.txt
Content-Disposition: attachment; filename="v6ops-fred2-charter.txt";
	size=3444; creation-date="Mon, 13 Apr 2015 23:57:52 GMT";
	modification-date="Mon, 13 Apr 2015 23:57:52 GMT"
Content-ID: <8300F2BBF0405043ABCAC39D0275EB6B@emea.cisco.com>
Content-Transfer-Encoding: base64

Q2hhcnRlciBmb3IgV29ya2luZyBHcm91cA0KDQoNClRoZSBnbG9iYWwgZGVwbG95bWVudCBvZiBJ
UHY2IGlzIHVuZGVyd2F5LCBjcmVhdGluZyBhbiBJUHY0L0lQdjYNCkludGVybmV0IGNvbnNpc3Rp
bmcgb2YgSVB2NC1vbmx5LCBJUHY2LW9ubHkgYW5kIElQdjQvSVB2NiBuZXR3b3Jrcw0KYW5kIG5v
ZGVzLiBUaGlzIGRlcGxveW1lbnQgbXVzdCBiZSBwcm9wZXJseSBoYW5kbGVkIHRvIGF2b2lkIHRo
ZQ0KZGl2aXNpb24gb2YgdGhlIEludGVybmV0IGludG8gc2VwYXJhdGUgSVB2NCBhbmQgSVB2NiBu
ZXR3b3JrcywNCmVuc3VyaW5nIGFkZHJlc3NpbmcgYW5kIGNvbm5lY3Rpdml0eSBmb3IgYWxsIElQ
djQgYW5kIElQdjYgbm9kZXMuDQoNClRoZSBJUHY2IE9wZXJhdGlvbnMgV29ya2luZyBHcm91cCAo
djZvcHMpIGRldmVsb3BzIGd1aWRlbGluZXMgZm9yDQp0aGUgb3BlcmF0aW9uIG9mIGEgc2hhcmVk
IElQdjQvSVB2NiBJbnRlcm5ldCBhbmQgcHJvdmlkZXMgb3BlcmF0aW9uYWwNCmd1aWRhbmNlIG9u
IGhvdyB0byBkZXBsb3kgYW5kIG9wZXJhdGUgSVB2NiBpbiBuZXcgYW5kIGV4aXN0aW5nDQpuZXR3
b3Jrcy4NCg0KVGhlIG1haW4gZm9jdXMgb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXb3JraW5nIEdy
b3VwIGlzIHRvIGxvb2sgYXQNCnRoZSBkZXBsb3ltZW50IGFuZCBvcGVyYXRpb25hbCBpc3N1ZXMg
aW4gSVB2NiBuZXR3b3Jrcy4NCg0KVGhlIGdvYWxzIG9mIHRoZSB2Nm9wcyB3b3JraW5nIGdyb3Vw
IGFyZToNCg0KMS4gU29saWNpdCBpbnB1dCBmcm9tIG5ldHdvcmsgb3BlcmF0b3JzIGFuZCB1c2Vy
cyB0byBpZGVudGlmeQ0Kb3BlcmF0aW9uYWwgaXNzdWVzIHdpdGggdGhlIElQdjQvSVB2NiBJbnRl
cm5ldCwgYW5kIGRldGVybWluZQ0Kc29sdXRpb25zIG9yIHdvcmthcm91bmRzIHRvIHRob3NlIGlz
c3Vlcy4gVGhlc2UgaXNzdWVzIHdpbGwgYmUNCmRvY3VtZW50ZWQgaW4gSW5mb3JtYXRpb25hbCBv
ciBCQ1AgUkZDcywgb3IgaW4gSW50ZXJuZXQtRHJhZnRzLg0KDQpUaGlzIHdvcmsgc2hvdWxkIHBy
aW1hcmlseSBiZSBjb25kdWN0ZWQgYnkgdGhvc2UgYXJlYXMgYW5kIFdvcmtpbmcNCkdyb3VwcyB3
aGljaCBhcmUgcmVzcG9uc2libGUgYW5kIGJlc3QgZml0IHRvIGFuYWx5emUgdGhlc2UgcHJvYmxl
bXMsDQpidXQgdjZvcHMgbWF5IGFsc28gY29vcGVyYXRlIGluIGZvY3VzaW5nIHN1Y2ggd29yay4N
Cg0KMi4gUHVibGlzaCBJbmZvcm1hdGlvbmFsIG9yIEJDUCBSRkNzIHRoYXQgaWRlbnRpZnkgcG90
ZW50aWFsIHNlY3VyaXR5DQpyaXNrcyBpbiB0aGUgb3BlcmF0aW9uIG9mIHNoYXJlZCBJUHY0L0lQ
djYgbmV0d29ya3MsIGFuZCBkb2N1bWVudA0Kb3BlcmF0aW9uYWwgcHJhY3RpY2VzIHRvIGVsaW1p
bmF0ZSBvciBtaXRpZ2F0ZSB0aG9zZSByaXNrcy4NCg0KVGhpcyB3b3JrIHdpbGwgYmUgZG9uZSBp
biBjb29wZXJhdGlvbiB3aXRoIHRoZSBTZWN1cml0eSBhcmVhIGFuZA0Kb3RoZXIgcmVsZXZhbnQg
YXJlYXMgb3Igd29ya2luZyBncm91cHMuDQoNCjMuIEFzIGEgcGFydGljdWxhciBpbnN0YW5jZSBv
ZiAoMSkgYW5kICgyKSwgcHJvdmlkZSBmZWVkYmFjayB0byB0aGUNCklQdjYgTWFpbnRlbmFuY2Ug
V29ya2luZyBHcm91cCByZWdhcmRpbmcgcG9ydGlvbnMgb2YgdGhlIElQdjYNCnNwZWNpZmljYXRp
b25zIHRoYXQgY2F1c2UsIG9yIGFyZSBsaWtlbHkgdG8gY2F1c2UsIG9wZXJhdGlvbmFsIG9yDQpz
ZWN1cml0eSBjb25jZXJucywgYW5kIHdvcmsgd2l0aCB0aGUgSVB2NiBXb3JraW5nIEdyb3VwIHRv
IHJlc29sdmUNCnRob3NlIGNvbmNlcm5zLiBUaGlzIGZlZWRiYWNrIHdpbGwgYmUgcHVibGlzaGVk
IGluIEludGVybmV0LURyYWZ0cw0Kb3IgUkZDcy4NCg0KNC4gRGVzY3JpYmUgYW4gb3BlcmF0aW9u
YWwgcm9hZG1hcCB0byBJUHY2LW9ubHkgbmV0d29yayBkZXBsb3ltZW50LA0Kd2l0aCBvciB3aXRo
b3V0IElQdjQgZGVsaXZlcmVkIGFzIGFuIG92ZXJsYXkgb3IgdHJhbnNsYXRpb24gc2VydmljZS4N
Cg0KVGhlc2UgZG9jdW1lbnRzIHNob3VsZCBkb2N1bWVudCBJUHY2IG9wZXJhdGlvbmFsIGV4cGVy
aWVuY2UsIGluY2x1ZGluZw0KaW50ZXJhY3Rpb25zIHdpdGggSVB2NCwgaW4gZHVhbCBzdGFjayBu
ZXR3b3JrcywgSVB2NiBuZXR3b3JrcyB3aXRoDQpJUHY0IGRlbGl2ZXJlZCBhcyBhbiBvdmVybGF5
IG9yIHRyYW5zbGF0aW9uIHNlcnZpY2UsIG9yIElQdjYtb25seQ0KbmV0d29ya3MuIFRoZXkgc2hv
dWxkIG5vdCBiZSBub3JtYXRpdmUgZ3VpZGVzIGZvciBJUHY2IGRlcGxveW1lbnQuDQpUaGVpciBw
cmltYXJ5IGludGVudCBpcyBub3QgdG8gY2FwdHVyZSB0aGUgbmVlZHMgZm9yIG5ldyBzb2x1dGlv
bnMsDQpidXQgcmF0aGVyIHRvIGRlc2NyaWJlIHdoaWNoIGFwcHJvYWNoZXMgd29yaywgYW5kIGlu
IHdoYXQgY2lyY3Vtc3RhbmNlcy4NCg0KSVB2NiBvcGVyYXRpb25hbCBhbmQgZGVwbG95bWVudCBp
c3N1ZXMgd2l0aCBzcGVjaWZpYyBwcm90b2NvbHMgb3INCnRlY2hub2xvZ2llcyAoc3VjaCBhcyBB
cHBsaWNhdGlvbnMsIFRyYW5zcG9ydCBQcm90b2NvbHMsIFJvdXRpbmcNClByb3RvY29scywgRE5T
IG9yIFN1Yi1JUCBQcm90b2NvbHMpIGFyZSB0aGUgcHJpbWFyeSByZXNwb25zaWJpbGl0eQ0Kb2Yg
dGhlIGdyb3VwcyBvciBhcmVhcyByZXNwb25zaWJsZSBmb3IgdGhvc2UgcHJvdG9jb2xzIG9yIHRl
Y2hub2xvZ2llcy4NCkhvd2V2ZXIsIHRoZSB2Nm9wcyBXb3JraW5nIEdyb3VwIG1heSBwcm92aWRl
IGlucHV0IHRvIHRob3NlDQphcmVhcy9ncm91cHMsIGFzIG5lZWRlZCwgYW5kIGNvb3BlcmF0ZSB3
aXRoIHRob3NlIGFyZWFzL2dyb3VwcyBpbg0KcmV2aWV3aW5nIHNvbHV0aW9ucyB0byBJUHY2IG9w
ZXJhdGlvbmFsIGFuZCBkZXBsb3ltZW50IHByb2JsZW1zLg0KDQpGdXR1cmUgd29yayBpdGVtcyB3
aXRoaW4gdGhpcyBzY29wZSB3aWxsIGJlIGFkb3B0ZWQgYnkgdGhlIFdvcmtpbmcNCkdyb3VwIG9u
bHkgaWYgdGhlcmUgaXMgYSBzdWJzdGFudGlhbCBleHByZXNzaW9uIG9mIGludGVyZXN0IGZyb20N
CnRoZSBjb21tdW5pdHkgYW5kIGlmIHRoZSB3b3JrIGNsZWFybHkgZG9lcyBub3QgZml0IGVsc2V3
aGVyZSBpbiB0aGUNCklFVEYuDQoNClRoZXJlIG11c3QgYmUgYSBjb250aW51b3VzIGV4cHJlc3Np
b24gb2YgaW50ZXJlc3QgZm9yIHRoZSBXb3JraW5nDQpHcm91cCB0byB3b3JrIG9uIGEgcGFydGlj
dWxhciB3b3JrIGl0ZW0uIElmIHRoZXJlIGlzIG5vIGxvbmdlcg0Kc3VmZmljaWVudCBpbnRlcmVz
dCBpbiB0aGUgV29ya2luZyBHcm91cCBpbiBhIHdvcmsgaXRlbSwgdGhlIGl0ZW0NCm1heSBiZSBy
ZW1vdmVkIGZyb20gdGhlIGxpc3Qgb2YgV29ya2luZyBHcm91cCBpdGVtcy4NCg0KU3BlY2lmeWlu
ZyBhbnkgcHJvdG9jb2xzIG9yIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBpcyBvdXQgb2Ygc2NvcGUN
Cm9mIHRoZSBXb3JraW5nIEdyb3VwLg0K

--_003_AD667352663E4333ACFD2BA0919482E0ciscocom_
Content-Type: text/html;
	name="Diff_ v6ops-charter-old.txt - v6ops-fred2-charter.txt.html"
Content-Description: Diff_ v6ops-charter-old.txt -
 v6ops-fred2-charter.txt.html
Content-Disposition: attachment;
	filename="Diff_ v6ops-charter-old.txt - v6ops-fred2-charter.txt.html";
	size=30466; creation-date="Mon, 13 Apr 2015 23:57:52 GMT";
	modification-date="Mon, 13 Apr 2015 23:57:52 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs
Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h
bC5kdGQiPg0KPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQyOiByZmNkaWZmICAtLT4NCjwh
LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv
bmFsIiA+IC0tPg0KPCEtLSBTeXN0ZW06IExpbnV4IHppbmZhbmRlbCAzLjIuMC00LWFtZDY0ICMx
IFNNUCBEZWJpYW4gMy4yLjM1LTIgeDg2XzY0IEdOVS9MaW51eCAtLT4NCjwhLS0gVXNpbmcgYXdr
OiAvdXNyL2Jpbi9nYXdrOiBHTlUgQXdrIDQuMC4xIC0tPg0KPCEtLSBVc2luZyBkaWZmOiAvdXNy
L2Jpbi9kaWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAzLjIgLS0+DQo8IS0tIFVzaW5nIHdkaWZm
OiAvdXNyL2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikgMS4xLjIgLS0+DQo8aHRtbD48aGVh
ZD4gDQogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s
OyBjaGFyc2V0PVVURi04Ij4gDQogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUtVHlw
ZSIgY29udGVudD0idGV4dC9jc3MiPiANCiAgPHRpdGxlPkRpZmY6IHY2b3BzLWNoYXJ0ZXItb2xk
LnR4dCAtIHY2b3BzLWZyZWQyLWNoYXJ0ZXIudHh0PC90aXRsZT4gDQogIDxzdHlsZSB0eXBlPSJ0
ZXh0L2NzcyI+IA0KICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1
dG87IH0gDQogICAgdHIgICAgICB7IH0gDQogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7
IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTog
MC44NmVtO30gDQogICAgdGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IA0KICAgIC5zbWFs
bCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBW
ZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gDQogICAgLmxlZnQgICB7IGJhY2tncm91
bmQtY29sb3I6ICNFRUU7IH0gDQogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7
IH0gDQogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gDQogICAgLmxibG9j
ayB7IGJhY2tncm91bmQtY29sb3I6ICNCRkI7IH0gDQogICAgLnJibG9jayB7IGJhY2tncm91bmQt
Y29sb3I6ICNGRjg7IH0gDQogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0g
DQogICAgLmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNBQ0Y7IH0gDQogICAgLnZvaWQgICB7
IGJhY2tncm91bmQtY29sb3I6ICNGRkI7IH0gDQogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29s
b3I6ICNFRUU7IH0gDQogICAgLmxpbmViciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gDQog
ICAgLmxpbmVubyB7IGNvbG9yOiByZWQ7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6
ZTogMC43ZW07IHRleHQtYWxpZ246IHJpZ2h0OyBwYWRkaW5nOiAwIDJweDsgfSANCiAgICAuZWxp
cHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSANCiAgICAubGVmdCAuY29udCB7IGJhY2tn
cm91bmQtY29sb3I6ICNEREQ7IH0gDQogICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xv
cjogI0VFRTsgfSANCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsg
fSANCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RENjsgfSANCiAgICAu
aW5zZXJ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzBERDsgfSANCiAgICAuZGVsZXRlIC5j
b250IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsgfSANCiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwg
LnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgcGFkZGluZzogMnB4IDA7IH0gDQog
IDwvc3R5bGU+IA0KPC9oZWFkPiANCjxib2R5PiANCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBh
ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4gDQogIDx0Ym9keT48dHIgYmdjb2xvcj0ib3Jhbmdl
Ij48dGg+PC90aD48dGg+Jm5ic3A7djZvcHMtY2hhcnRlci1vbGQudHh0Jm5ic3A7PC90aD48dGg+
IDwvdGg+PHRoPiZuYnNwO3Y2b3BzLWZyZWQyLWNoYXJ0ZXIudHh0Jm5ic3A7PC90aD48dGg+PC90
aD48L3RyPiANCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij5DaGFydGVyIGZvciBXb3JraW5nIEdyb3VwPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+Q2hhcnRlciBmb3IgV29ya2luZyBHcm91cDwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij5UaGUgZ2xvYmFsIGRlcGxveW1lbnQgb2YgSVB2NiBpcyB1bmRlcndh
eSwgY3JlYXRpbmcgYW4gSVB2NC9JUHY2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
VGhlIGdsb2JhbCBkZXBsb3ltZW50IG9mIElQdjYgaXMgdW5kZXJ3YXksIGNyZWF0aW5nIGFuIElQ
djQvSVB2NjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+SW50ZXJuZXQgY29uc2lzdGluZyBvZiBJUHY0LW9ubHksIElQdjYtb25seSBhbmQgSVB2
NC9JUHY2IG5ldHdvcmtzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQg
Y29uc2lzdGluZyBvZiBJUHY0LW9ubHksIElQdjYtb25seSBhbmQgSVB2NC9JUHY2IG5ldHdvcmtz
PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5h
bmQgbm9kZXMuIFRoaXMgZGVwbG95bWVudCBtdXN0IGJlIHByb3Blcmx5IGhhbmRsZWQgdG8gYXZv
aWQgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+YW5kIG5vZGVzLiBUaGlzIGRl
cGxveW1lbnQgbXVzdCBiZSBwcm9wZXJseSBoYW5kbGVkIHRvIGF2b2lkIHRoZTwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5h
bWU9ImRpZmYwMDAxIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ZGl2aXNpb24gb2YgdGhlIElu
dGVybmV0IGludG8gc2VwYXJhdGUgSVB2NCBhbmQgSVB2NiBuZXR3b3JrczxzcGFuIGNsYXNzPSJk
ZWxldGUiPiB3aGlsZTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ZGl2
aXNpb24gb2YgdGhlIEludGVybmV0IGludG8gc2VwYXJhdGUgSVB2NCBhbmQgSVB2NiBuZXR3b3Jr
czxzcGFuIGNsYXNzPSJpbnNlcnQiPiw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5lbnN1cmluZyBhZGRyZXNzaW5nIGFuZCBjb25u
ZWN0aXZpdHkgZm9yIGFsbCBJUHY0IGFuZCBJUHY2IG5vZGVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPmVuc3VyaW5nIGFkZHJlc3NpbmcgYW5kIGNvbm5lY3Rpdml0eSBmb3IgYWxs
IElQdjQgYW5kIElQdjYgbm9kZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlRoZSBJ
UHY2IE9wZXJhdGlvbnMgV29ya2luZyBHcm91cCAodjZvcHMpIGRldmVsb3BzIGd1aWRlbGluZXMg
Zm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGhlIElQdjYgT3BlcmF0aW9ucyBX
b3JraW5nIEdyb3VwICh2Nm9wcykgZGV2ZWxvcHMgZ3VpZGVsaW5lcyBmb3I8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPnRoZSBvcGVyYXRpb24g
b2YgYSBzaGFyZWQgSVB2NC9JUHY2IEludGVybmV0IGFuZCBwcm92aWRlcyBvcGVyYXRpb25hbDwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPnRoZSBvcGVyYXRpb24gb2YgYSBzaGFyZWQg
SVB2NC9JUHY2IEludGVybmV0IGFuZCBwcm92aWRlcyBvcGVyYXRpb25hbDwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxhIG5hbWU9
ImRpZmYwMDAyIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+Z3VpZGFuY2Ugb24gaG93IHRvIGRl
cGxveSBJUHY2IDxzcGFuIGNsYXNzPSJkZWxldGUiPmludG8gZXhpc3RpbmcgSVB2NC1vbmx5IG5l
dHdvcmtzLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+Z3VpZGFuY2Ug
b24gaG93IHRvIGRlcGxveSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hbmQgb3BlcmF0ZTwvc3Bhbj4g
SVB2NiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5pbjwvc3Bhbj4gbmV3IDxzcGFuIGNsYXNzPSJpbnNl
cnQiPmFuZCBleGlzdGluZzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+YXMgd2VsbCBhcyBp
bnRvPC9zcGFuPiBuZXcgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bmV0d29yayBpbnN0YWxsYXRpb25z
Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu
c2VydCI+bmV0d29ya3MuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48
dGQ+PGEgbmFtZT0iZGlmZjAwMDMiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5UaGUgbWFpbiBm
b2N1cyBvZiB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+djZvcHMgV0c8L3NwYW4+IGlzIHRvIGxv
b2sgYXQgdGhlIDxzcGFuIGNsYXNzPSJkZWxldGUiPmltbWVkaWF0ZSBkZXBsb3ltZW50PC9zcGFu
PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5UaGUgbWFpbiBmb2N1cyBvZiB0aGUg
PHNwYW4gY2xhc3M9Imluc2VydCI+SVB2NiBPcGVyYXRpb25zIFdvcmtpbmcgR3JvdXA8L3NwYW4+
IGlzIHRvIGxvb2sgYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+aXNzdWVzOyBtb3JlIGFkdmFuY2Vk
IHN0YWdlcyBvZjwvc3Bhbj4gZGVwbG95bWVudCBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dHJh
bnNpdGlvbiBhcmUgYTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+dGhl
IGRlcGxveW1lbnQgYW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm9wZXJhdGlvbmFsIGlzc3VlcyBp
biBJUHY2IG5ldHdvcmtzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+bG93ZXIgcHJpb3Jp
dHkuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+VGhlIGdvYWxzIG9mIHRoZSB2Nm9wcyB3b3JraW5nIGdyb3VwIGFy
ZTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5UaGUgZ29hbHMgb2YgdGhlIHY2b3Bz
IHdvcmtpbmcgZ3JvdXAgYXJlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xLiBTb2xp
Y2l0IGlucHV0IGZyb20gbmV0d29yayBvcGVyYXRvcnMgYW5kIHVzZXJzIHRvIGlkZW50aWZ5PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MS4gU29saWNpdCBpbnB1dCBmcm9tIG5ldHdv
cmsgb3BlcmF0b3JzIGFuZCB1c2VycyB0byBpZGVudGlmeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+b3BlcmF0aW9uYWwgaXNzdWVzIHdpdGgg
dGhlIElQdjQvSVB2NiBJbnRlcm5ldCwgYW5kIGRldGVybWluZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPm9wZXJhdGlvbmFsIGlzc3VlcyB3aXRoIHRoZSBJUHY0L0lQdjYgSW50ZXJu
ZXQsIGFuZCBkZXRlcm1pbmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPnNvbHV0aW9ucyBvciB3b3JrYXJvdW5kcyB0byB0aG9zZSBpc3N1ZXMu
IFRoZXNlIGlzc3VlcyB3aWxsIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+c29s
dXRpb25zIG9yIHdvcmthcm91bmRzIHRvIHRob3NlIGlzc3Vlcy4gVGhlc2UgaXNzdWVzIHdpbGwg
YmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PmRvY3VtZW50ZWQgaW4gSW5mb3JtYXRpb25hbCBvciBCQ1AgUkZDcywgb3IgaW4gSW50ZXJuZXQt
RHJhZnRzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPmRvY3VtZW50ZWQgaW4gSW5m
b3JtYXRpb25hbCBvciBCQ1AgUkZDcywgb3IgaW4gSW50ZXJuZXQtRHJhZnRzLjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDQiPjwvYT48L3RkPjwv
dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj5UaGlzIHdvcmsgc2hvdWxkIHByaW1hcmlseSBiZSBjb25kdWN0ZWQgYnkg
dGhvc2UgYXJlYXMgYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPldHczwvc3Bhbj4gd2hpY2g8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+VGhpcyB3b3JrIHNob3VsZCBwcmltYXJpbHkg
YmUgY29uZHVjdGVkIGJ5IHRob3NlIGFyZWFzIGFuZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Xb3Jr
aW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGJsb2NrIj5hcmUgcmVzcG9uc2libGUgYW5kIGJlc3QgZml0IHRvIGFuYWx5emUgdGhlc2Ug
cHJvYmxlbXMsIGJ1dCB2Nm9wczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh
biBjbGFzcz0iaW5zZXJ0Ij5Hcm91cHM8L3NwYW4+IHdoaWNoIGFyZSByZXNwb25zaWJsZSBhbmQg
YmVzdCBmaXQgdG8gYW5hbHl6ZSB0aGVzZSBwcm9ibGVtcyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+bWF5IGFsc28gY29vcGVyYXRlIGlu
IGZvY3VzaW5nIHN1Y2ggd29yay48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+YnV0
IHY2b3BzIG1heSBhbHNvIGNvb3BlcmF0ZSBpbiBmb2N1c2luZyBzdWNoIHdvcmsuPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuIFB1Ymxpc2ggSW5mb3JtYXRpb25hbCBvciBCQ1AgUkZD
cyB0aGF0IGlkZW50aWZ5IHBvdGVudGlhbCBzZWN1cml0eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjIuIFB1Ymxpc2ggSW5mb3JtYXRpb25hbCBvciBCQ1AgUkZDcyB0aGF0IGlkZW50
aWZ5IHBvdGVudGlhbCBzZWN1cml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+cmlza3MgaW4gdGhlIG9wZXJhdGlvbiBvZiBzaGFyZWQgSVB2
NC9JUHY2IG5ldHdvcmtzLCBhbmQgZG9jdW1lbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij5yaXNrcyBpbiB0aGUgb3BlcmF0aW9uIG9mIHNoYXJlZCBJUHY0L0lQdjYgbmV0d29ya3Ms
IGFuZCBkb2N1bWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+b3BlcmF0aW9uYWwgcHJhY3RpY2VzIHRvIGVsaW1pbmF0ZSBvciBtaXRpZ2F0
ZSB0aG9zZSByaXNrcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5vcGVyYXRpb25h
bCBwcmFjdGljZXMgdG8gZWxpbWluYXRlIG9yIG1pdGlnYXRlIHRob3NlIHJpc2tzLjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5UaGlzIHdvcmsgd2lsbCBiZSBkb25lIGluIGNvb3BlcmF0
aW9uIHdpdGggdGhlIFNlY3VyaXR5IGFyZWEgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+VGhpcyB3b3JrIHdpbGwgYmUgZG9uZSBpbiBjb29wZXJhdGlvbiB3aXRoIHRoZSBTZWN1
cml0eSBhcmVhIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+b3RoZXIgcmVsZXZhbnQgYXJlYXMgb3Igd29ya2luZyBncm91cHMuPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+b3RoZXIgcmVsZXZhbnQgYXJlYXMgb3Igd29ya2lu
ZyBncm91cHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuIEFzIGEgcGFydGljdWxh
ciBpbnN0YW5jZSBvZiAoMSkgYW5kICgyKSwgcHJvdmlkZSBmZWVkYmFjayB0byB0aGU8L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLiBBcyBhIHBhcnRpY3VsYXIgaW5zdGFuY2Ugb2Yg
KDEpIGFuZCAoMiksIHByb3ZpZGUgZmVlZGJhY2sgdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw
MDUiPjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5JUHY2IDxzcGFuIGNsYXNzPSJkZWxldGUiPldH
PC9zcGFuPiByZWdhcmRpbmcgcG9ydGlvbnMgb2YgdGhlIElQdjYgc3BlY2lmaWNhdGlvbnMgdGhh
dCBjYXVzZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+SVB2NiA8c3BhbiBjbGFz
cz0iaW5zZXJ0Ij5NYWludGVuYW5jZSBXb3JraW5nIEdyb3VwPC9zcGFuPiByZWdhcmRpbmcgcG9y
dGlvbnMgb2YgdGhlIElQdjY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxibG9jayI+b3IgYXJlIGxpa2VseSB0byBjYXVzZSwgb3BlcmF0aW9uYWwgb3Ig
c2VjdXJpdHkgY29uY2VybnMsIGFuZCB3b3JrPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPnNwZWNpZmljYXRpb25zIHRoYXQgY2F1c2UsIG9yIGFyZSBsaWtlbHkgdG8gY2F1c2UsIG9w
ZXJhdGlvbmFsIG9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90
cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs
YXNzPSJsYmxvY2siPndpdGggdGhlIElQdjYgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+V0c8L3NwYW4+
IHRvIHJlc29sdmUgdGhvc2UgY29uY2VybnMuIFRoaXMgZmVlZGJhY2sgd2lsbCBiZTwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5zZWN1cml0eSBjb25jZXJucywgYW5kIHdvcmsgd2l0
aCB0aGUgSVB2NiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Xb3JraW5nIEdyb3VwPC9zcGFuPiB0byBy
ZXNvbHZlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
YmxvY2siPnB1Ymxpc2hlZCBpbiBJbnRlcm5ldC1EcmFmdHMgb3IgUkZDcy48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJibG9jayI+dGhvc2UgY29uY2VybnMuIFRoaXMgZmVlZGJhY2sgd2lsbCBi
ZSBwdWJsaXNoZWQgaW4gSW50ZXJuZXQtRHJhZnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+b3IgUkZDcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+NC4g
UHVibGlzaCBJbmZvcm1hdGlvbmFsIG9yIEJDUCBSRkNzIHRoYXQgaWRlbnRpZnkgYW5kIGFuYWx5
emU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i
ZGVsZXRlIj5zb2x1dGlvbnMgZm9yIGRlcGxveWluZyBJUHY2IHdpdGhpbiBjb21tb24gbmV0d29y
ayBlbnZpcm9ubWVudHMsPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+
PHNwYW4gY2xhc3M9ImRlbGV0ZSI+c3VjaCBhcyBJU1AgTmV0d29ya3MsIEVudGVycHJpc2UgTmV0
d29ya3MsIFVubWFuYWdlZCBOZXR3b3Jrczwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4N
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz
PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPihIb21lL1NtYWxsIE9mZmljZSksIGFuZCBD
ZWxsdWxhciBOZXR3b3Jrcy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDYi
PjwvYT48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGVzZSBkb2N1
bWVudHMgc2hvdWxkIHNlcnZlIGFzIHVzZWZ1bCBndWlkZXM8L3NwYW4+IHRvIG5ldHdvcmsgPHNw
YW4gY2xhc3M9ImRlbGV0ZSI+b3BlcmF0b3JzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij40LiBEZXNjcmliZSBhbiBvcGVyYXRpb25h
bCByb2FkbWFwPC9zcGFuPiB0byA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5JUHY2LW9ubHk8L3NwYW4+
IG5ldHdvcmsgPHNwYW4gY2xhc3M9Imluc2VydCI+ZGVwbG95bWVudCw8L3NwYW4+PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs
YXNzPSJkZWxldGUiPmFuZCB1c2VycyBvbiBwb3NzaWJsZSB3YXlzIGhvdyB0byBkZXBsb3kgSVB2
NiB3aXRoaW4gdGhlaXIgZXhpc3Rpbmc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPndpdGggb3Igd2l0aG91dDwvc3Bhbj4gSVB2NCA8
c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kZWxpdmVyZWQ8L3NwYW4+IGFzIDxzcGFuIGNsYXNzPSJpbnNl
cnQiPmFuIG92ZXJsYXkgb3IgdHJhbnNsYXRpb24gc2VydmljZS48L3NwYW4+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPklQdjQgPHNwYW4g
Y2xhc3M9ImRlbGV0ZSI+bmV0d29ya3MsPC9zcGFuPiBhcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj53
ZWxsIGFzIGluIG5ldyBuZXR3b3JrIGluc3RhbGxhdGlvbnMuPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk
PjxhIG5hbWU9ImRpZmYwMDA3Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+VGhlc2UgZG9jdW1l
bnRzIHNob3VsZCBub3QgYmUgbm9ybWF0aXZlIGd1aWRlcyBmb3IgSVB2NiA8c3BhbiBjbGFzcz0i
ZGVsZXRlIj5kZXBsb3ltZW50LDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j
ayI+VGhlc2UgZG9jdW1lbnRzIHNob3VsZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kb2N1bWVudCBJ
UHY2IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UsIGluY2x1ZGluZzwvc3Bhbj48L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9
ImRlbGV0ZSI+YW5kIHRoZTwvc3Bhbj4gcHJpbWFyeSBpbnRlbnQgaXMgbm90IGNhcHR1cmUgdGhl
IG5lZWRzIGZvciBuZXcgc29sdXRpb25zLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5pbnRlcmFjdGlvbnMgd2l0aCBJUHY0LCBpbiBkdWFsIHN0
YWNrIG5ldHdvcmtzLCBJUHY2IG5ldHdvcmtzIHdpdGg8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPmJ1dCByYXRoZXIgZGVzY3Jp
YmUgd2hpY2ggYXBwcm9hY2hlcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj53b3JrPC9zcGFuPiBhbmQg
PHNwYW4gY2xhc3M9ImRlbGV0ZSI+d2hpY2ggZG8gbm90Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+SVB2NCBkZWxpdmVyZWQgYXMg
YW4gb3ZlcmxheSBvciB0cmFuc2xhdGlvbiBzZXJ2aWNlLCBvciBJUHY2LW9ubHk8L3NwYW4+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5uZXR3
b3Jrcy4gVGhleSBzaG91bGQ8L3NwYW4+IG5vdCBiZSBub3JtYXRpdmUgZ3VpZGVzIGZvciBJUHY2
IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRlcGxveW1lbnQuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+VGhlaXI8L3NwYW4+IHByaW1h
cnkgaW50ZW50IGlzIG5vdCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50bzwvc3Bhbj4gY2FwdHVyZSB0
aGUgbmVlZHMgZm9yIG5ldyBzb2x1dGlvbnMsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs
b2NrIj5idXQgcmF0aGVyIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRvPC9zcGFuPiBkZXNjcmliZSB3
aGljaCBhcHByb2FjaGVzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPndvcmssPC9zcGFuPiBhbmQgPHNw
YW4gY2xhc3M9Imluc2VydCI+aW4gd2hhdCBjaXJjdW1zdGFuY2VzLjwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SVB2NiBvcGVyYXRpb25hbCBhbmQgZGVwbG95bWVudCBpc3N1
ZXMgd2l0aCBzcGVjaWZpYyBwcm90b2NvbHMgb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij5JUHY2IG9wZXJhdGlvbmFsIGFuZCBkZXBsb3ltZW50IGlzc3VlcyB3aXRoIHNwZWNpZmlj
IHByb3RvY29scyBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+dGVjaG5vbG9naWVzIChzdWNoIGFzIEFwcGxpY2F0aW9ucywgVHJhbnNwb3J0
IFByb3RvY29scywgUm91dGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPnRlY2hu
b2xvZ2llcyAoc3VjaCBhcyBBcHBsaWNhdGlvbnMsIFRyYW5zcG9ydCBQcm90b2NvbHMsIFJvdXRp
bmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PlByb3RvY29scywgRE5TIG9yIFN1Yi1JUCBQcm90b2NvbHMpIGFyZSB0aGUgcHJpbWFyeSByZXNw
b25zaWJpbGl0eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlByb3RvY29scywgRE5T
IG9yIFN1Yi1JUCBQcm90b2NvbHMpIGFyZSB0aGUgcHJpbWFyeSByZXNwb25zaWJpbGl0eTwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+b2YgdGhl
IGdyb3VwcyBvciBhcmVhcyByZXNwb25zaWJsZSBmb3IgdGhvc2UgcHJvdG9jb2xzIG9yIHRlY2hu
b2xvZ2llcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5vZiB0aGUgZ3JvdXBzIG9y
IGFyZWFzIHJlc3BvbnNpYmxlIGZvciB0aG9zZSBwcm90b2NvbHMgb3IgdGVjaG5vbG9naWVzLjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+
PHRkPjxhIG5hbWU9ImRpZmYwMDA4Ij48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+SG93ZXZlciwg
dGhlIHY2b3BzIDxzcGFuIGNsYXNzPSJkZWxldGUiPldHPC9zcGFuPiBtYXkgcHJvdmlkZSBpbnB1
dCB0byB0aG9zZSBhcmVhcy9ncm91cHMsIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPkhvd2V2ZXIsIHRoZSB2Nm9wcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Xb3JraW5nIEdyb3Vw
PC9zcGFuPiBtYXkgcHJvdmlkZSBpbnB1dCB0byB0aG9zZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5uZWVkZWQsIGFuZCBjb29wZXJhdGUg
d2l0aCB0aG9zZSBhcmVhcy9ncm91cHMgaW4gcmV2aWV3aW5nIHNvbHV0aW9uczwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5hcmVhcy9ncm91cHMsIGFzIG5lZWRlZCwgYW5kIGNvb3Bl
cmF0ZSB3aXRoIHRob3NlIGFyZWFzL2dyb3VwcyBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj50byBJUHY2IG9wZXJhdGlvbmFsIGFuZCBk
ZXBsb3ltZW50IHByb2JsZW1zLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5yZXZp
ZXdpbmcgc29sdXRpb25zIHRvIElQdjYgb3BlcmF0aW9uYWwgYW5kIGRlcGxveW1lbnQgcHJvYmxl
bXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAw
OSI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkZ1dHVyZSB3b3JrIGl0ZW1zIHdpdGhpbiB0aGlz
IHNjb3BlIHdpbGwgYmUgYWRvcHRlZCBieSB0aGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+V0c8L3Nw
YW4+IG9ubHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RnV0dXJlIHdvcmsgaXRl
bXMgd2l0aGluIHRoaXMgc2NvcGUgd2lsbCBiZSBhZG9wdGVkIGJ5IHRoZSA8c3BhbiBjbGFzcz0i
aW5zZXJ0Ij5Xb3JraW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5pZiB0aGVyZSBpcyBhIHN1YnN0YW50aWFsIGV4cHJlc3Np
b24gb2YgaW50ZXJlc3QgZnJvbSB0aGUgY29tbXVuaXR5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPkdyb3VwPC9zcGFuPiBvbmx5IGlmIHRoZXJl
IGlzIGEgc3Vic3RhbnRpYWwgZXhwcmVzc2lvbiBvZiBpbnRlcmVzdCBmcm9tPC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPmFuZCBpZiB0aGUg
d29yayBjbGVhcmx5IGRvZXMgbm90IGZpdCBlbHNld2hlcmUgaW4gdGhlIElFVEYuPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPnRoZSBjb21tdW5pdHkgYW5kIGlmIHRoZSB3b3JrIGNs
ZWFybHkgZG9lcyBub3QgZml0IGVsc2V3aGVyZSBpbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyYmxvY2siPklFVEYuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48
YSBuYW1lPSJkaWZmMDAxMCI+PC9hPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPlRoZXJlIG11c3QgYmUg
YSBjb250aW51b3VzIGV4cHJlc3Npb24gb2YgaW50ZXJlc3QgZm9yIHRoZSA8c3BhbiBjbGFzcz0i
ZGVsZXRlIj5XRzwvc3Bhbj4gdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+VGhl
cmUgbXVzdCBiZSBhIGNvbnRpbnVvdXMgZXhwcmVzc2lvbiBvZiBpbnRlcmVzdCBmb3IgdGhlIDxz
cGFuIGNsYXNzPSJpbnNlcnQiPldvcmtpbmc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPndvcmsgb24gYSBwYXJ0aWN1bGFyIHdv
cmsgaXRlbS4gSWYgdGhlcmUgaXMgbm8gbG9uZ2VyIHN1ZmZpY2llbnQ8L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+R3JvdXA8L3NwYW4+IHRvIHdv
cmsgb24gYSBwYXJ0aWN1bGFyIHdvcmsgaXRlbS4gSWYgdGhlcmUgaXMgbm8gbG9uZ2VyPC90ZD48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPmludGVy
ZXN0IGluIHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5XRzwvc3Bhbj4gaW4gYSB3b3JrIGl0ZW0s
IHRoZSBpdGVtIG1heSBiZSByZW1vdmVkIGZyb20gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPnN1ZmZpY2llbnQgaW50ZXJlc3QgaW4gdGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQi
PldvcmtpbmcgR3JvdXA8L3NwYW4+IGluIGEgd29yayBpdGVtLCB0aGUgaXRlbTwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5saXN0IG9mIDxz
cGFuIGNsYXNzPSJkZWxldGUiPldHPC9zcGFuPiBpdGVtcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJibG9jayI+bWF5IGJlIHJlbW92ZWQgZnJvbSB0aGUgbGlzdCBvZiA8c3BhbiBjbGFzcz0i
aW5zZXJ0Ij5Xb3JraW5nIEdyb3VwPC9zcGFuPiBpdGVtcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+U3BlY2lmeWluZyBhbnkgcHJvdG9jb2xzIG9yIHRyYW5zaXRpb24gbWVjaGFuaXNt
cyBpcyBvdXQgb2Ygc2NvcGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5TcGVjaWZ5
aW5nIGFueSBwcm90b2NvbHMgb3IgdHJhbnNpdGlvbiBtZWNoYW5pc21zIGlzIG91dCBvZiBzY29w
ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8
dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDExIj48L2E+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+b2YgdGhl
IFc8c3BhbiBjbGFzcz0iZGVsZXRlIj5HPC9zcGFuPi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJibG9jayI+b2YgdGhlIFc8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5vcmtpbmcgR3JvdXA8L3NwYW4+
LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQoNCiAgICAg
PHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPg0KICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRoIGNv
bHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxhIG5hbWU9ImVuZCI+Jm5ic3A7RW5kIG9mIGNoYW5n
ZXMuIDExIGNoYW5nZSBibG9ja3MuJm5ic3A7PC9hPjwvdGg+PC90cj4NCiAgICAgPHRyIGNsYXNz
PSJzdGF0cyI+PHRkPjwvdGQ+PHRoPjxpPjM0IGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48
L3RoPjx0aD48aT4gPC9pPjwvdGg+PHRoPjxpPjMyIGxpbmVzIGNoYW5nZWQgb3IgYWRkZWQ8L2k+
PC90aD48dGQ+PC90ZD48L3RyPg0KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGNsYXNzPSJzbWFs
bCIgYWxpZ249ImNlbnRlciI+PGJyPlRoaXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNk
aWZmIDEuNDIuIFRoZSBsYXRlc3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJo
dHRwOi8vd3d3LnRvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8vdG9vbHMuaWV0
Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4NCiAgIDwvdGJvZHk+PC90YWJsZT4N
CiAgIA0KICAgDQpYLUdlbmVyYXRvcjogcHlodCAwLjM1DQoNCjwhLS0gYXJnczogeyctLW9sZGNv
bG91cic6ICdyZWQnLCAnLS13aWR0aCc6ICcnLCAnZGlmZnR5cGUnOiAnLS1odG1sJywgJ2ZpbGVu
YW1lMic6ICdDaGFydGVyIGZvciBXb3JraW5nIEdyb3VwXG5cblxuVGhlIGdsb2JhbCBkZXBsb3lt
ZW50IG9mIElQdjYgaXMgdW5kZXJ3YXksIGNyZWF0aW5nIGFuIElQdjQvSVB2NlxuSW50ZXJuZXQg
Y29uc2lzdGluZyBvZiBJUHY0LW9ubHksIElQdjYtb25seSBhbmQgSVB2NC9JUHY2IG5ldHdvcmtz
XG5hbmQgbm9kZXMuIFRoaXMgZGVwbG95bWVudCBtdXN0IGJlIHByb3Blcmx5IGhhbmRsZWQgdG8g
YXZvaWQgdGhlXG5kaXZpc2lvbiBvZiB0aGUgSW50ZXJuZXQgaW50byBzZXBhcmF0ZSBJUHY0IGFu
ZCBJUHY2IG5ldHdvcmtzLFxuZW5zdXJpbmcgYWRkcmVzc2luZyBhbmQgY29ubmVjdGl2aXR5IGZv
ciBhbGwgSVB2NCBhbmQgSVB2NiBub2Rlcy5cblxuVGhlIElQdjYgT3BlcmF0aW9ucyBXb3JraW5n
IEdyb3VwICh2Nm9wcykgZGV2ZWxvcHMgZ3VpZGVsaW5lcyBmb3JcbnRoZSBvcGVyYXRpb24gb2Yg
YSBzaGFyZWQgSVB2NC9JUHY2IEludGVybmV0IGFuZCBwcm92aWRlcyBvcGVyYXRpb25hbFxuZ3Vp
ZGFuY2Ugb24gaG93IHRvIGRlcGxveSBhbmQgb3BlcmF0ZSBJUHY2IGluIG5ldyBhbmQgZXhpc3Rp
bmdcbm5ldHdvcmtzLlxuXG5UaGUgbWFpbiBmb2N1cyBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdv
cmtpbmcgR3JvdXAgaXMgdG8gbG9vayBhdFxudGhlIGRlcGxveW1lbnQgYW5kIG9wZXJhdGlvbmFs
IGlzc3VlcyBpbiBJUHY2IG5ldHdvcmtzLlxuXG5UaGUgZ29hbHMgb2YgdGhlIHY2b3BzIHdvcmtp
bmcgZ3JvdXAgYXJlOlxuXG4xLiBTb2xpY2l0IGlucHV0IGZyb20gbmV0d29yayBvcGVyYXRvcnMg
YW5kIHVzZXJzIHRvIGlkZW50aWZ5XG5vcGVyYXRpb25hbCBpc3N1ZXMgd2l0aCB0aGUgSVB2NC9J
UHY2IEludGVybmV0LCBhbmQgZGV0ZXJtaW5lXG5zb2x1dGlvbnMgb3Igd29ya2Fyb3VuZHMgdG8g
dGhvc2UgaXNzdWVzLiBUaGVzZSBpc3N1ZXMgd2lsbCBiZVxuZG9jdW1lbnRlZCBpbiBJbmZvcm1h
dGlvbmFsIG9yIEJDUCBSRkNzLCBvciBpbiBJbnRlcm5ldC1EcmFmdHMuXG5cblRoaXMgd29yayBz
aG91bGQgcHJpbWFyaWx5IGJlIGNvbmR1Y3RlZCBieSB0aG9zZSBhcmVhcyBhbmQgV29ya2luZ1xu
R3JvdXBzIHdoaWNoIGFyZSByZXNwb25zaWJsZSBhbmQgYmVzdCBmaXQgdG8gYW5hbHl6ZSB0aGVz
ZSBwcm9ibGVtcyxcbmJ1dCB2Nm9wcyBtYXkgYWxzbyBjb29wZXJhdGUgaW4gZm9jdXNpbmcgc3Vj
aCB3b3JrLlxuXG4yLiBQdWJsaXNoIEluZm9ybWF0aW9uYWwgb3IgQkNQIFJGQ3MgdGhhdCBpZGVu
dGlmeSBwb3RlbnRpYWwgc2VjdXJpdHlcbnJpc2tzIGluIHRoZSBvcGVyYXRpb24gb2Ygc2hhcmVk
IElQdjQvSVB2NiBuZXR3b3JrcywgYW5kIGRvY3VtZW50XG5vcGVyYXRpb25hbCBwcmFjdGljZXMg
dG8gZWxpbWluYXRlIG9yIG1pdGlnYXRlIHRob3NlIHJpc2tzLlxuXG5UaGlzIHdvcmsgd2lsbCBi
ZSBkb25lIGluIGNvb3BlcmF0aW9uIHdpdGggdGhlIFNlY3VyaXR5IGFyZWEgYW5kXG5vdGhlciBy
ZWxldmFudCBhcmVhcyBvciB3b3JraW5nIGdyb3Vwcy5cblxuMy4gQXMgYSBwYXJ0aWN1bGFyIGlu
c3RhbmNlIG9mICgxKSBhbmQgKDIpLCBwcm92aWRlIGZlZWRiYWNrIHRvIHRoZVxuSVB2NiBNYWlu
dGVuYW5jZSBXb3JraW5nIEdyb3VwIHJlZ2FyZGluZyBwb3J0aW9ucyBvZiB0aGUgSVB2Nlxuc3Bl
Y2lmaWNhdGlvbnMgdGhhdCBjYXVzZSwgb3IgYXJlIGxpa2VseSB0byBjYXVzZSwgb3BlcmF0aW9u
YWwgb3JcbnNlY3VyaXR5IGNvbmNlcm5zLCBhbmQgd29yayB3aXRoIHRoZSBJUHY2IFdvcmtpbmcg
R3JvdXAgdG8gcmVzb2x2ZVxudGhvc2UgY29uY2VybnMuIFRoaXMgZmVlZGJhY2sgd2lsbCBiZSBw
dWJsaXNoZWQgaW4gSW50ZXJuZXQtRHJhZnRzXG5vciBSRkNzLlxuXG40LiBEZXNjcmliZSBhbiBv
cGVyYXRpb25hbCByb2FkbWFwIHRvIElQdjYtb25seSBuZXR3b3JrIGRlcGxveW1lbnQsXG53aXRo
IG9yIHdpdGhvdXQgSVB2NCBkZWxpdmVyZWQgYXMgYW4gb3ZlcmxheSBvciB0cmFuc2xhdGlvbiBz
ZXJ2aWNlLlxuXG5UaGVzZSBkb2N1bWVudHMgc2hvdWxkIGRvY3VtZW50IElQdjYgb3BlcmF0aW9u
YWwgZXhwZXJpZW5jZSwgaW5jbHVkaW5nXG5pbnRlcmFjdGlvbnMgd2l0aCBJUHY0LCBpbiBkdWFs
IHN0YWNrIG5ldHdvcmtzLCBJUHY2IG5ldHdvcmtzIHdpdGhcbklQdjQgZGVsaXZlcmVkIGFzIGFu
IG92ZXJsYXkgb3IgdHJhbnNsYXRpb24gc2VydmljZSwgb3IgSVB2Ni1vbmx5XG5uZXR3b3Jrcy4g
VGhleSBzaG91bGQgbm90IGJlIG5vcm1hdGl2ZSBndWlkZXMgZm9yIElQdjYgZGVwbG95bWVudC5c
blRoZWlyIHByaW1hcnkgaW50ZW50IGlzIG5vdCB0byBjYXB0dXJlIHRoZSBuZWVkcyBmb3IgbmV3
IHNvbHV0aW9ucyxcbmJ1dCByYXRoZXIgdG8gZGVzY3JpYmUgd2hpY2ggYXBwcm9hY2hlcyB3b3Jr
LCBhbmQgaW4gd2hhdCBjaXJjdW1zdGFuY2VzLlxuXG5JUHY2IG9wZXJhdGlvbmFsIGFuZCBkZXBs
b3ltZW50IGlzc3VlcyB3aXRoIHNwZWNpZmljIHByb3RvY29scyBvclxudGVjaG5vbG9naWVzIChz
dWNoIGFzIEFwcGxpY2F0aW9ucywgVHJhbnNwb3J0IFByb3RvY29scywgUm91dGluZ1xuUHJvdG9j
b2xzLCBETlMgb3IgU3ViLUlQIFByb3RvY29scykgYXJlIHRoZSBwcmltYXJ5IHJlc3BvbnNpYmls
aXR5XG5vZiB0aGUgZ3JvdXBzIG9yIGFyZWFzIHJlc3BvbnNpYmxlIGZvciB0aG9zZSBwcm90b2Nv
bHMgb3IgdGVjaG5vbG9naWVzLlxuSG93ZXZlciwgdGhlIHY2b3BzIFdvcmtpbmcgR3JvdXAgbWF5
IHByb3ZpZGUgaW5wdXQgdG8gdGhvc2VcbmFyZWFzL2dyb3VwcywgYXMgbmVlZGVkLCBhbmQgY29v
cGVyYXRlIHdpdGggdGhvc2UgYXJlYXMvZ3JvdXBzIGluXG5yZXZpZXdpbmcgc29sdXRpb25zIHRv
IElQdjYgb3BlcmF0aW9uYWwgYW5kIGRlcGxveW1lbnQgcHJvYmxlbXMuXG5cbkZ1dHVyZSB3b3Jr
IGl0ZW1zIHdpdGhpbiB0aGlzIHNjb3BlIHdpbGwgYmUgYWRvcHRlZCBieSB0aGUgV29ya2luZ1xu
R3JvdXAgb25seSBpZiB0aGVyZSBpcyBhIHN1YnN0YW50aWFsIGV4cHJlc3Npb24gb2YgaW50ZXJl
c3QgZnJvbVxudGhlIGNvbW11bml0eSBhbmQgaWYgdGhlIHdvcmsgY2xlYXJseSBkb2VzIG5vdCBm
aXQgZWxzZXdoZXJlIGluIHRoZVxuSUVURi5cblxuVGhlcmUgbXVzdCBiZSBhIGNvbnRpbnVvdXMg
ZXhwcmVzc2lvbiBvZiBpbnRlcmVzdCBmb3IgdGhlIFdvcmtpbmdcbkdyb3VwIHRvIHdvcmsgb24g
YSBwYXJ0aWN1bGFyIHdvcmsgaXRlbS4gSWYgdGhlcmUgaXMgbm8gbG9uZ2VyXG5zdWZmaWNpZW50
IGludGVyZXN0IGluIHRoZSBXb3JraW5nIEdyb3VwIGluIGEgd29yayBpdGVtLCB0aGUgaXRlbVxu
bWF5IGJlIHJlbW92ZWQgZnJvbSB0aGUgbGlzdCBvZiBXb3JraW5nIEdyb3VwIGl0ZW1zLlxuXG5T
cGVjaWZ5aW5nIGFueSBwcm90b2NvbHMgb3IgdHJhbnNpdGlvbiBtZWNoYW5pc21zIGlzIG91dCBv
ZiBzY29wZVxub2YgdGhlIFdvcmtpbmcgR3JvdXAuXG4nLCAnZmlsZW5hbWUxJzogJ0NoYXJ0ZXIg
Zm9yIFdvcmtpbmcgR3JvdXBcblxuXG5UaGUgZ2xvYmFsIGRlcGxveW1lbnQgb2YgSVB2NiBpcyB1
bmRlcndheSwgY3JlYXRpbmcgYW4gSVB2NC9JUHY2XG5JbnRlcm5ldCBjb25zaXN0aW5nIG9mIElQ
djQtb25seSwgSVB2Ni1vbmx5IGFuZCBJUHY0L0lQdjYgbmV0d29ya3NcbmFuZCBub2Rlcy4gVGhp
cyBkZXBsb3ltZW50IG11c3QgYmUgcHJvcGVybHkgaGFuZGxlZCB0byBhdm9pZCB0aGVcbmRpdmlz
aW9uIG9mIHRoZSBJbnRlcm5ldCBpbnRvIHNlcGFyYXRlIElQdjQgYW5kIElQdjYgbmV0d29ya3Mg
d2hpbGVcbmVuc3VyaW5nIGFkZHJlc3NpbmcgYW5kIGNvbm5lY3Rpdml0eSBmb3IgYWxsIElQdjQg
YW5kIElQdjYgbm9kZXMuXG5cblRoZSBJUHY2IE9wZXJhdGlvbnMgV29ya2luZyBHcm91cCAodjZv
cHMpIGRldmVsb3BzIGd1aWRlbGluZXMgZm9yXG50aGUgb3BlcmF0aW9uIG9mIGEgc2hhcmVkIElQ
djQvSVB2NiBJbnRlcm5ldCBhbmQgcHJvdmlkZXMgb3BlcmF0aW9uYWxcbmd1aWRhbmNlIG9uIGhv
dyB0byBkZXBsb3kgSVB2NiBpbnRvIGV4aXN0aW5nIElQdjQtb25seSBuZXR3b3JrcyxcbmFzIHdl
bGwgYXMgaW50byBuZXcgbmV0d29yayBpbnN0YWxsYXRpb25zLlxuXG5UaGUgbWFpbiBmb2N1cyBv
ZiB0aGUgdjZvcHMgV0cgaXMgdG8gbG9vayBhdCB0aGUgaW1tZWRpYXRlIGRlcGxveW1lbnRcbmlz
c3VlczsgbW9yZSBhZHZhbmNlZCBzdGFnZXMgb2YgZGVwbG95bWVudCBhbmQgdHJhbnNpdGlvbiBh
cmUgYVxubG93ZXIgcHJpb3JpdHkuXG5cblRoZSBnb2FscyBvZiB0aGUgdjZvcHMgd29ya2luZyBn
cm91cCBhcmU6XG5cbjEuIFNvbGljaXQgaW5wdXQgZnJvbSBuZXR3b3JrIG9wZXJhdG9ycyBhbmQg
dXNlcnMgdG8gaWRlbnRpZnlcbm9wZXJhdGlvbmFsIGlzc3VlcyB3aXRoIHRoZSBJUHY0L0lQdjYg
SW50ZXJuZXQsIGFuZCBkZXRlcm1pbmVcbnNvbHV0aW9ucyBvciB3b3JrYXJvdW5kcyB0byB0aG9z
ZSBpc3N1ZXMuIFRoZXNlIGlzc3VlcyB3aWxsIGJlXG5kb2N1bWVudGVkIGluIEluZm9ybWF0aW9u
YWwgb3IgQkNQIFJGQ3MsIG9yIGluIEludGVybmV0LURyYWZ0cy5cblxuVGhpcyB3b3JrIHNob3Vs
ZCBwcmltYXJpbHkgYmUgY29uZHVjdGVkIGJ5IHRob3NlIGFyZWFzIGFuZCBXR3Mgd2hpY2hcbmFy
ZSByZXNwb25zaWJsZSBhbmQgYmVzdCBmaXQgdG8gYW5hbHl6ZSB0aGVzZSBwcm9ibGVtcywgYnV0
IHY2b3BzXG5tYXkgYWxzbyBjb29wZXJhdGUgaW4gZm9jdXNpbmcgc3VjaCB3b3JrLlxuXG4yLiBQ
dWJsaXNoIEluZm9ybWF0aW9uYWwgb3IgQkNQIFJGQ3MgdGhhdCBpZGVudGlmeSBwb3RlbnRpYWwg
c2VjdXJpdHlcbnJpc2tzIGluIHRoZSBvcGVyYXRpb24gb2Ygc2hhcmVkIElQdjQvSVB2NiBuZXR3
b3JrcywgYW5kIGRvY3VtZW50XG5vcGVyYXRpb25hbCBwcmFjdGljZXMgdG8gZWxpbWluYXRlIG9y
IG1pdGlnYXRlIHRob3NlIHJpc2tzLlxuXG5UaGlzIHdvcmsgd2lsbCBiZSBkb25lIGluIGNvb3Bl
cmF0aW9uIHdpdGggdGhlIFNlY3VyaXR5IGFyZWEgYW5kXG5vdGhlciByZWxldmFudCBhcmVhcyBv
ciB3b3JraW5nIGdyb3Vwcy5cblxuMy4gQXMgYSBwYXJ0aWN1bGFyIGluc3RhbmNlIG9mICgxKSBh
bmQgKDIpLCBwcm92aWRlIGZlZWRiYWNrIHRvIHRoZVxuSVB2NiBXRyByZWdhcmRpbmcgcG9ydGlv
bnMgb2YgdGhlIElQdjYgc3BlY2lmaWNhdGlvbnMgdGhhdCBjYXVzZSxcbm9yIGFyZSBsaWtlbHkg
dG8gY2F1c2UsIG9wZXJhdGlvbmFsIG9yIHNlY3VyaXR5IGNvbmNlcm5zLCBhbmQgd29ya1xud2l0
aCB0aGUgSVB2NiBXRyB0byByZXNvbHZlIHRob3NlIGNvbmNlcm5zLiBUaGlzIGZlZWRiYWNrIHdp
bGwgYmVcbnB1Ymxpc2hlZCBpbiBJbnRlcm5ldC1EcmFmdHMgb3IgUkZDcy5cblxuNC4gUHVibGlz
aCBJbmZvcm1hdGlvbmFsIG9yIEJDUCBSRkNzIHRoYXQgaWRlbnRpZnkgYW5kIGFuYWx5emVcbnNv
bHV0aW9ucyBmb3IgZGVwbG95aW5nIElQdjYgd2l0aGluIGNvbW1vbiBuZXR3b3JrIGVudmlyb25t
ZW50cyxcbnN1Y2ggYXMgSVNQIE5ldHdvcmtzLCBFbnRlcnByaXNlIE5ldHdvcmtzLCBVbm1hbmFn
ZWQgTmV0d29ya3NcbihIb21lL1NtYWxsIE9mZmljZSksIGFuZCBDZWxsdWxhciBOZXR3b3Jrcy5c
blxuVGhlc2UgZG9jdW1lbnRzIHNob3VsZCBzZXJ2ZSBhcyB1c2VmdWwgZ3VpZGVzIHRvIG5ldHdv
cmsgb3BlcmF0b3JzXG5hbmQgdXNlcnMgb24gcG9zc2libGUgd2F5cyBob3cgdG8gZGVwbG95IElQ
djYgd2l0aGluIHRoZWlyIGV4aXN0aW5nXG5JUHY0IG5ldHdvcmtzLCBhcyB3ZWxsIGFzIGluIG5l
dyBuZXR3b3JrIGluc3RhbGxhdGlvbnMuXG5cblRoZXNlIGRvY3VtZW50cyBzaG91bGQgbm90IGJl
IG5vcm1hdGl2ZSBndWlkZXMgZm9yIElQdjYgZGVwbG95bWVudCxcbmFuZCB0aGUgcHJpbWFyeSBp
bnRlbnQgaXMgbm90IGNhcHR1cmUgdGhlIG5lZWRzIGZvciBuZXcgc29sdXRpb25zLFxuYnV0IHJh
dGhlciBkZXNjcmliZSB3aGljaCBhcHByb2FjaGVzIHdvcmsgYW5kIHdoaWNoIGRvIG5vdC5cblxu
SVB2NiBvcGVyYXRpb25hbCBhbmQgZGVwbG95bWVudCBpc3N1ZXMgd2l0aCBzcGVjaWZpYyBwcm90
b2NvbHMgb3JcbnRlY2hub2xvZ2llcyAoc3VjaCBhcyBBcHBsaWNhdGlvbnMsIFRyYW5zcG9ydCBQ
cm90b2NvbHMsIFJvdXRpbmdcblByb3RvY29scywgRE5TIG9yIFN1Yi1JUCBQcm90b2NvbHMpIGFy
ZSB0aGUgcHJpbWFyeSByZXNwb25zaWJpbGl0eVxub2YgdGhlIGdyb3VwcyBvciBhcmVhcyByZXNw
b25zaWJsZSBmb3IgdGhvc2UgcHJvdG9jb2xzIG9yIHRlY2hub2xvZ2llcy5cbkhvd2V2ZXIsIHRo
ZSB2Nm9wcyBXRyBtYXkgcHJvdmlkZSBpbnB1dCB0byB0aG9zZSBhcmVhcy9ncm91cHMsIGFzXG5u
ZWVkZWQsIGFuZCBjb29wZXJhdGUgd2l0aCB0aG9zZSBhcmVhcy9ncm91cHMgaW4gcmV2aWV3aW5n
IHNvbHV0aW9uc1xudG8gSVB2NiBvcGVyYXRpb25hbCBhbmQgZGVwbG95bWVudCBwcm9ibGVtcy5c
blxuRnV0dXJlIHdvcmsgaXRlbXMgd2l0aGluIHRoaXMgc2NvcGUgd2lsbCBiZSBhZG9wdGVkIGJ5
IHRoZSBXRyBvbmx5XG5pZiB0aGVyZSBpcyBhIHN1YnN0YW50aWFsIGV4cHJlc3Npb24gb2YgaW50
ZXJlc3QgZnJvbSB0aGUgY29tbXVuaXR5XG5hbmQgaWYgdGhlIHdvcmsgY2xlYXJseSBkb2VzIG5v
dCBmaXQgZWxzZXdoZXJlIGluIHRoZSBJRVRGLlxuXG5UaGVyZSBtdXN0IGJlIGEgY29udGludW91
cyBleHByZXNzaW9uIG9mIGludGVyZXN0IGZvciB0aGUgV0cgdG9cbndvcmsgb24gYSBwYXJ0aWN1
bGFyIHdvcmsgaXRlbS4gSWYgdGhlcmUgaXMgbm8gbG9uZ2VyIHN1ZmZpY2llbnRcbmludGVyZXN0
IGluIHRoZSBXRyBpbiBhIHdvcmsgaXRlbSwgdGhlIGl0ZW0gbWF5IGJlIHJlbW92ZWQgZnJvbSB0
aGVcbmxpc3Qgb2YgV0cgaXRlbXMuXG5cblNwZWNpZnlpbmcgYW55IHByb3RvY29scyBvciB0cmFu
c2l0aW9uIG1lY2hhbmlzbXMgaXMgb3V0IG9mIHNjb3BlXG5vZiB0aGUgV0cuXG4nLCAndXJsMSc6
ICcnLCAnc3VibWl0JzogJ0dlbmVyYXRlIGRpZmYnLCAndXJsMic6ICcnLCAnLS1uZXdjb2xvdXIn
OiAnZ3JlZW4nfSAtLT48L2JvZHk+PC9odG1sPg==

--_003_AD667352663E4333ACFD2BA0919482E0ciscocom_--


From nobody Mon Apr 13 17:23: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 AB5001B2B65 for ; Mon, 13 Apr 2015 17:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.102
X-Spam-Level: *
X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, 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 5wST8Ue-msPF for ; Mon, 13 Apr 2015 17:23:07 -0700 (PDT)
Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D2B1B2B63 for ; Mon, 13 Apr 2015 17:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1428970986; bh=yPbNVsKvFBPlm0uo3iMMiGsZgGnyYRnbmQKeJ5lK91k=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=owR4b76O+Rq+Gi0D5rO0UxLixj5UOfo+RdG4Qki9iiRN4wd1nJMEfWUtqXpFZD++FjRgvQ7MH724XOhygkTz4Gqt+qcBcimui4ac8LNTQwEoCyTO91O4VZt0kt1kXnVv/5ySGBjUYwJLZN3CDBCQ4FSJjy9BVorHhEKjF92siBqDuK/P1yXPFWI9eG0Om5XAjezCTHurGY15I6GRzYh+JP8S6Ia/+2ctJIwnZNDpdEN0FIi2aYImujQH+cC0i7CTv4ldxlMJwf3FM30SXQoPl7SzJ7euGW75p5EG3172FnPL6K0ObQ+VsjpcpeR2muAnYMomXhcd+dm3tUalQsYtBg==
Received: from [98.139.215.140] by nm24.bullet.mail.bf1.yahoo.com with NNFMP;  14 Apr 2015 00:23:06 -0000
Received: from [98.139.212.210] by tm11.bullet.mail.bf1.yahoo.com with NNFMP;  14 Apr 2015 00:23:06 -0000
Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 14 Apr 2015 00:23:06 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 600921.13706.bm@omp1019.mail.bf1.yahoo.com
X-YMail-OSG: ZDTwhuYVM1lZdpK9czkJN31l8rn6lwhgln45RGDvMaZB_sZAPRJt9pduvYAA11U sfpJCWTtsNuUxgr.BTaLUWWinU5Q_r1Klv6RhL.jTYKdpWyoOUQ1SqJ5m5jXPH72eMuTL9x2rAsL KKb0IkECCncaog.DtLwOhHic5wh8VFoZcvRiNMFtB103kGTSynXSAQ1fUY7FX4uUnvs7G3gz45up W19BoetCx5iJHZ8Nv311CcFLPsFuuf4Xrn_p7k0P8.9EkQonKgppJxTO39nUd_.U1XNwiK9KJZaC dG0PtzNmvcWQF5Qxdh190H5BmsmrjqmkOM9FBP_OQzSoruh10rDuaO_f_TTvgvGwORqn97MXIyPF MOatZMKDBQQ1Ly8zvbOMqVkIwJpMyvOY4NyIdLTLGVVbsXtM.ebMAGwLpTW143GBafxN.77D7.4_ nYB2Idx43MDFBKgWp69FjUf93UrG0Cps50_DQWXjgayL.LqiJF9gMa5hSPh_dmqL3WqAcYYeR86k WBRZRjayRqFk0CvS5.e7.YGrx4ajEGrODDVX8mxBufHPB3lU-
Received: by 66.196.80.146; Tue, 14 Apr 2015 00:23:06 +0000 
Date: Tue, 14 Apr 2015 00:23:04 +0000 (UTC)
From: Mark ZZZ Smith 
To: "George, Wes" , v6ops list 
Message-ID: <2042630785.2773277.1428970984807.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_2773276_187473888.1428970984800"
Archived-At: 
Cc: Philip Matthews 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 00:23:10 -0000

------=_Part_2773276_187473888.1428970984800
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Wes,
      From: "George, Wes" 
 To: v6ops list =20
Cc: Philip Matthews =20
 Sent: Monday, 13 April 2015, 23:43
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =20
 It's a little unclear who said what given the way text was quoted, so I'm =
just replying to the snippet of text I think is relevant inline below with =
WG], and then a few other LC comments follow below it.
Thanks,  =C2=A0 Wes  =C2=A0=20
/ I value predictability and robustness. Having a eBGP session very specifi=
cally tied to an interface tightly couples the eBGP session and the traffic=
 for the prefixes that eBGP session is announcing. The small amount of extr=
a effort required to change a session to a different interface creates furt=
her opportunity to catch errors. In some cases, the actual error might be m=
inor, but the consequences of them can be very significant outages.
WG] That is true whether you use a LL or a GUA if you use the interface IP =
address for eBGP peering instead of loopback multi hop. What's your point i=
n favor of LLN here? Also, what errors are you talking about catching where=
more=C2=A0manual reconfiguration is the right answer?
/* It seams one of the objections people have is that to use a LL as an eBG=
P neighbor address you also have to specify the interface name, where as if=
 you used a GUA, the interface is implicit in the BGP configuration, as the=
 binding between the GUA address and interface is somewhere else within the=
 configuration. I think having the both the neighbor address and the interf=
ace to use to reach it explicitly specified in the BGP configuration is mor=
e robust, as how things are to operate is more obvious (I try to follow a p=
rinciple of making it obvious how things work, so that if they fail, it is =
more obvious where to look for the failure.)

/ LLs don't have to be tied to specific hardware addresses, they can be sta=
tically set if this is a concern, and hopefully in the future, RFC7217 will=
 be implemented for them in routers, as this is one of the specific use cas=
es for them.
WG] it's worse than that. If you don't statically set LL addresses, they do=
n't show up in the interface configuration, and because they're only locall=
y significant, you have an awful time if you want to actually find the rout=
er or interface that is associated with the next-hop (say when chasing a ne=
xt-hop rewrite problem), because you can't find it in the routing table, an=
d you can't grep through a config repository for the address, and it likely=
 won't be in DNS. The closest you might be able to get is to grep for the a=
ddress and find the router with the other side of the iBGP session, but thi=
s won't work for eBGP because there is no relationship between the neighbor=
 addresses like there is with GUA (+1 / -1).
/* Which I think is some more evidence that the more explicit and obvious t=
hings are, the easier they are to troubleshoot.
/* Regards,Mark.
Philip you may want to add something like this in 2.4.2 (or in 2.1.2 since =
it's not just relevant to BGP.)
Other comments:=C2=A0You may want to add a reference to RFC 7439 in 2.4.1 l=
ast bullet about MPLS and IPv62.4.2: 5925 is not MD5. It obsoleted MD5, but=
 it is properly referred to as TCP AO, so it'd be better to say "MD5 (RFC23=
85), which while still in wide use, has been obsoleted by TCP AO (RFC5925)"

=C2=A0Anything below this line has been added by my company=E2=80=99s mail =
server, I have no control over it. -----------

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

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


  
------=_Part_2773276_187473888.1428970984800
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Wes,

  
 
 
 
   From: "George, Wes" <wesley.george@twcable.com>
 To: v6ops list <v6ops@ietf.org> Cc: Philip Matthews <=
philip_matthews@magma.ca> 
 Sen=
t: Monday, 13 April 2015, 23:43
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices W=
GLC
  
 



=20








It's a little unclear who said=
 what given the way text was quoted, so I'm just replying to the snippet of=
 text I think is relevant inline below with WG], and then a few other LC co=
mments follow below it.









Thanks,
=20

  
=20

Wes
=20

  
=20






















/ I val=
ue predictability and robustness. Having a eBGP session very specifically
 tied to an interface tightly couples the eBGP session and the traffic for =
the prefixes that eBGP session is announcing. The small amount of extra eff=
ort required to change a session to a different interface creates further o=
pportunity to catch errors. In some
 cases, the actual error might be minor, but the consequences of them can b=
e very significant outages.
















WG] That is true whether you u=
se a LL or a GUA if you use the interface IP address for eBGP peering inste=
ad of loopback multi hop. What's your point in favor of LLN here? Also, wha=
t errors are you talking about catching where
more manual reconfiguration i=
s the right answer?















/* It seams one of the objections people have is t=
hat to use a LL as an eBGP neighbor address you also have to specify the in=
terface name, where as if you used a GUA, the interface is implicit in the =
BGP configuration, as the binding between the GUA address and interface is =
somewhere else within the configuration. I think having the both the neighb=
or address and the interface to use to reach it explicitly specified in the=
 BGP configuration is more robust, as how things are to operate is more obv=
ious (I try to follow a principle of making it obvious how things work, so =
that if they fail, it is more obvious where to look for the failure.)
=






/ LLs don't have to be tied to specific hardware addresses, they can be sta=
tically set if this is a concern, and hopefully in the future, RFC7217 will=
 be implemented for them in routers, as this is one of the specific use cas=
es for them.
















WG] it's worse than that. If y=
ou don't statically set LL addresses, they don't show up in the interface c=
onfiguration, and because they're only locally significant, you have an awf=
ul time if you want to actually find the router or interface that is associ=
ated
 with the next-hop (say when chasing a next-hop rewrite problem), because y=
ou can't find it in the routing table, and you can't grep through a config =
repository for the address, and it likely won't be in DNS. The closest you =
might be able to get is to grep
 for the address and find the router with the other side of the iBGP sessio=
n, but this won't work for eBGP because there is no relationship between th=
e neighbor addresses like there is with GUA (+1 / -1).

/* Which I think is some more evidence that the more =
explicit and obvious things are, the easier they are to troubleshoot.
=


/* Regards,
Mark.







Philip you may want to add som=
ething like this in 2.4.2 (or in 2.1.2 since it's not just relevant to BGP.=
)







Other comments: 


You may want to add a referenc=
e to RFC 7439 in 2.4.1 last bullet about MPLS and IPv6


2.4.2: 5925 is not MD5. It obs=
oleted MD5, but it is properly referred to as TCP AO, so it'd be better to =
say "MD5 (RFC2385), which while still in wide use, has been obsoleted by TC=
P AO (RFC5925)"












 






Anything below =
this line has been added by my company=E2=80=99s mail server, I have no con=
trol over it.
=20

-----------













This E-mail and any of its attachments may contain Time Warner =
Cable proprietary information, which is privileged, confidential, or subjec=
t to copyright belonging to Time Warner Cable. This E-mail is intended sole=
ly
 for the use of the individual or entity to which it is addressed. If you a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.







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

 
 
  

------=_Part_2773276_187473888.1428970984800--


From nobody Mon Apr 13 17: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 C70CB1B2B85 for ; Mon, 13 Apr 2015 17:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.102
X-Spam-Level: *
X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, 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 2BWVouafu2qF for ; Mon, 13 Apr 2015 17:34:13 -0700 (PDT)
Received: from nm34-vm2.bullet.mail.bf1.yahoo.com (nm34-vm2.bullet.mail.bf1.yahoo.com [72.30.239.74]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105701B2B84 for ; Mon, 13 Apr 2015 17:34:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1428971652; bh=7TDEQNECtX0jLR50F7MkbvsYde6VIyttGvTZDwoyv6M=;  h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject;  b=Xdlv+BksY8eV6+guSmGk1h9iVaR5fR/yDAqmGIICtROO2SMdcRLirXv2uT/C4kS/qfJ1TQCZD4N3KjUO6MUw0UT2H4L+rTNwE5rtQmnOpBzCImQ2+MiqX5d5ng3TYzeEpGnT63w4ExrllSf31Dj2mZKXkRZMBSISwVtXwoQ9MotsQeHJbd3o3wySFV1RFa/ifJd8IdPTc5XkQh7U01TqWUs5bateSoEwVfqLAsiSPmSI9ZhvcSeCP1UJONXVjiViPInJoIgmI3jJJaETtQClHHbtp9rVY7nh3BgP5wErdYZzkgT5z2qLyPMB76ysYoQuVppeNff215BWoyIBnAC7jw==
Received: from [98.139.170.181] by nm34.bullet.mail.bf1.yahoo.com with NNFMP;  14 Apr 2015 00:34:12 -0000
Received: from [98.139.212.232] by tm24.bullet.mail.bf1.yahoo.com with NNFMP;  14 Apr 2015 00:34:12 -0000
Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 14 Apr 2015 00:34:12 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 102187.75129.bm@omp1041.mail.bf1.yahoo.com
X-YMail-OSG: 5M2A70YVM1mNNrRkSX5TBRhvsj.av5bgM.VJMW7wJ71s89a2hMnLQYzPpsQsGG1 mazU2m.HsHnsddgsgNj0XF8xM6ugZ8Ps_Lnzw47b8WbKaM.YAIPVsfhjK3QvV7FrQ07D.RCqgdzm 4ftuAl1MKT7FoKyg6Z03aiBKjI.O..4CIhgXZulPwOSC5zN.zMkxZaw.RPy6qXo4s3EUvZu.5RTy H5v913F1Ue74TNHN6fbjM9GZV5JbZjVvoWTXSqHSnpx8pg9DVgsEY9lokEXvwGLRYn1.EkbItm9Z hPdgUhqpxFfcVDdtlHPVypkpPZPUS_.umn6qzNZ7hCwQV0gm3QYXMByFfhdO0LH0hpIzAjCqPuiK wyl1dtAQgxUR.HOiVge6RdmY8jSWj4Y0G2QFZdtFHVJ4ORiRMtHu7faCm17pu3xskqwdNd9jFWOp CGVTLEW5LydXtt3Fts2kjXhjwUwAnXSga1fouA04RABwqmolcUK746A8tniuheJ86GE36fiYYPt6 qFZs2SLAlzd._6F4kb5xZLdiifaGAWJ9OcD4OzeKupP6hiy73
Received: by 76.13.26.64; Tue, 14 Apr 2015 00:34:11 +0000 
Date: Tue, 14 Apr 2015 00:34:09 +0000 (UTC)
From: Mark ZZZ Smith 
To: Mikael Abrahamsson , "v6ops@ietf.org" 
Message-ID: <1182288247.2764905.1428971649957.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_2764904_1297850459.1428971649953"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 00:34:14 -0000

------=_Part_2764904_1297850459.1428971649953
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: Mikael Abrahamsson 
 To: v6ops@ietf.org=20
 Sent: Monday, 13 April 2015, 16:39
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =20
On Sun, 12 Apr 2015, fred@cisco.com wrote:

> The working group last call for this draft announced last week
> continues for another week.=C2=A0 Please feel free to comment on it.

Re-reading it as if I never read it before:

2.1.2. Regarding using ULAs. I have run into one instance in reality where=
=20
an ISP numbered an interface from ULAs on a VERY popular large router=20
vendor device. This meant that PTBs were generated with a ULA source=20
address. This is obviously totally broken, and I think text warning about=
=20
this should be added. Numbering interfaces with ULA and LLA only means one=
=20
has to make VERY SURE that PTBs and other ICMP messsages are not sourced=20
from these ULA addresses if the intent is to use this outside of a private=
=20
network.


/ RFC6752, "Issues with Private IP Addressing in the Internet" is on this t=
opic, although it is only discussing IPv4 private addressing, and is discus=
sing the case where there is only private/RFC1918 addressing on the link, n=
ot the where if you're going to be generating PTBs for network external dev=
ices, you source addresses that are valid outside your network i.e. PTB sou=
rce loopback assigned or on-link GUAs in addition to ULAs.
/ A generalised IPv4 and IPv6 version of RFC6752 would be useful, however i=
n the mean time, in this draft, that one could be referenced, with a couple=
 of paragraphs highlighting that while similar problems could occur with IP=
v6, that RFC is assuming just a single private addressing prefix on the lin=
k and that the alternative is a single public addressing prefix on the link=
, where as IPv6 fully supports concurrent private and public prefix on a li=
nk.


=C2=A0I also question how common it is to use ULAs, with current=20
wording it seems to indicate that both are quite common, which I don't=20
agree with.

2.2.1. I agree with this, so my suggestion is that the ULA reference above=
=20
is removed or severely downplay:ed, otherwise last sentence in 2.2.1 needs=
=20
to say GUA or ULA as next-hop address.

2.3.1. I have personally been involved in running ISIS for IPv4 and OSPFv3=
=20
for IPv6 at the same time (option b), due to IPv6 related ISIS vendor bug.=
=20
I don't see why this wouldn't be known to work well? This isn't something=
=20
I feel strongly about though...


Apart from these relatively small points above, I think this document is=20
in good shape, useful, and ready to proceed.



--=20
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se



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


  
------=_Part_2764904_1297850459.1428971649953
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



  
 
 
 
 =
  From: Mikael Ab=
rahamsson <swmike@swm.pp.se>
 To: v6ops@ietf.org 
 Sent: Monday, 13 April 2015, 16:39 Subject: =
Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
 =
 
 





 
<=
div class=3D"yiv7889997804yqt8832954110" id=3D"yiv7889997804yqtfd80173"> 
  

------=_Part_2764904_1297850459.1428971649953--


From nobody Mon Apr 13 22:19:41 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 B7FD91B3398; Mon, 13 Apr 2015 22:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_24=0.6, 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 ngK9_FaNhDW4; Mon, 13 Apr 2015 22:19:36 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C17C1B3393; Mon, 13 Apr 2015 22:19:35 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2A6ECA1; Tue, 14 Apr 2015 07:19:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1428988773; bh=fPFkXxnewBzGEKHs6pYpb3FCizibDBVtvSf4X8PRycg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ok8FrrroxWNo+j/QXy172vhUxn+vaMDlYIH3DQXnKTejMwGrpN9O7kJ+HxufwHigc aiO0cja1RgGENeAsK8sD58+bYed2y2bB2qsW7Pxq4HCSpz9GAzfm/ID4UicxzW/C/0 tjAqqXFpFxM/d10g3UIiJZwnHRNRLhAmPrk+IyVM=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1F8239F; Tue, 14 Apr 2015 07:19:33 +0200 (CEST)
Date: Tue, 14 Apr 2015 07:19:33 +0200 (CEST)
From: Mikael Abrahamsson 
To: "Fred Baker (fred)" 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1792334646-1428988773=:16871"
Archived-At: 
Cc: IPv6 Ops WG , "sunset4@ietf.org" 
Subject: Re: [v6ops] v6ops charter update discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 05:19:38 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-1792334646-1428988773=:16871
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 13 Apr 2015, Fred Baker (fred) wrote:

> Lee and I are reviewing the v6ops charter. I have attached a proposed charter and diffs against the current one. Joel has not commented on this yet, and while we have run it by the sunset4 chairs, we haven’t gotten a reading from them. Sunset4 is relevant because possibly the ipv4-as-a-service discussion would be better handled there. In this email, I’m soliciting opinions in general.
>
> The charter update started with Lee feeling that the fourth bullet of our current charter, which reads
>    4. Publish Informational or BCP RFCs that identify and analyze
>       solutions for deploying IPv6 within common network environments,
>       such as ISP Networks, Enterprise Networks, Unmanaged Networks
>       (Home/Small Office), and Cellular Networks.
>       (http://datatracker.ietf.org/wg/v6ops/charter/)
> is largely done. We know how to deploy IPv6.

Hm, while I generally agree with you, does this mean that these kinds of 
RFCs will be out-of-scope for v6ops going forward? I would hate for us to 
take this out of the charter and then turn people away when they show up 
with a document for a solution we didn't think of yet.

Or perhaps paragraph 1 is enough to allow for capturing these kinds of 
documents?

>    4. Describe an operational roadmap to IPv6-only network deployment,
>       with or without IPv4 delivered as an overlay or translation
>       service.

Fully agreed.

> On another point, Lee and I have been discussing the operational reports 
> we had at IETF 92, and feel that was time well spent. Those had a common 
> thread, which was the deployment of Softwire’s MAP-E and MAP-T 
> technologies in their networks. We are thinking about asking companies 
> deploying IPv6 in Europe, Asia, and South America to make reports in the 
> coming three meetings, on their IPv6 deployments and the issues they 
> face. Would that be of general interest? How would you propose to tune 
> that concept?

I think this is worthwile, as long as it's not going to be come a long 
list of 10-15 minute presentations saying the same thing. For those, we 
can keep it on the list. I always welcome operational reports in the 
meetings, but they need to contain news, not "we experienced the same 
thing as  and solved it the same way".

I would like to hear from the ds.lite deployers out there, I know they 
exist. Also from 464XLAT+NAT64 deployments (probably in mobile).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-1792334646-1428988773=:16871--


From nobody Mon Apr 13 22:31: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 645721B33B4 for ; Mon, 13 Apr 2015 22:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 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, 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 PW4oOlXPM_NN for ; Mon, 13 Apr 2015 22:31:42 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 0E4601B33B3 for ; Mon, 13 Apr 2015 22:31:41 -0700 (PDT)
Received: by qkgx75 with SMTP id x75so218101090qkg.1 for ; Mon, 13 Apr 2015 22:31:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bRky30UkvW1BOtf0e4GaVp30QQH5hJvaZwT/FdH1vuo=; b=BG1ER0cY8Q4FwaZ4WQAiPc9zkFqDAVMIl7VZMf/L+pFddmEqtCZ6Exd8iZ1sC/E00W RMnRsmiPzA3zEn5t7FPcBb3RffN/qSR/PNdry/XaS3mFkwxqM1ea/Q/9nozJobLH6sLz lNB9byYGlS5t7d1JZFlRtMe3FzQOx2xbMrSVAAG0qs0c43zU/VVzyQhDmbkX96y+Eo+p JN+RFUv0HyE3f1MZqXzrewyNWO15khaVYF6n0patQkek69Cak3maz6zXxbtMnLk2uJHM 80OhVKpQZ9+ItA7Ag8ZF8/2+cf6f9oW7buZovM+3BXJktJi4ygdtxmsI8vIR4ihaqQyD YyfA==
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=bRky30UkvW1BOtf0e4GaVp30QQH5hJvaZwT/FdH1vuo=; b=JI8yB3PCibFcpT7BUA1GncIhEiEq7ibjLUKF1meKwGd1jLWZyYKlEKh7nzPE5fLwlZ eoOb8/MeMYOnewRa4fdWTF+O68qpJ9bXAdt1ofKQ2yE4AZL7hNXm6sUieyYrNidXQIwL JNw8hDy5VH0Nbr87yQGZmld26mc/g2XVQ+Us+mlXy26YhKSA2HwPGCpiwPJXaeYrGu6d OiGeh42IYy32E/pJNS13HOJb6DCelbpqTLDSU4diPnBAkkpTo0awgN79f0NaCT2nhJuT QtbAnmWel0idNgg5bOD9XlpLF+htksqEcV8S0qZ+aoWU5HDzyYs795VRtO6rVDMr1AmL Y1Bg==
X-Gm-Message-State: ALoCoQkuNsx7fCSs4lGam7OgnA6vYVL6b2xb+sjjmXSsMYfxaYmzKxsJvu7at17I4TlF56UVLNNW
X-Received: by 10.55.24.215 with SMTP id 84mr37070914qky.8.1428989496880; Mon, 13 Apr 2015 22:31:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.135.9 with HTTP; Mon, 13 Apr 2015 22:31:16 -0700 (PDT)
In-Reply-To: 
References:            <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn> 
From: Erik Kline 
Date: Tue, 14 Apr 2015 14:31:16 +0900
Message-ID: 
To: James Woodyatt 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 14 Apr 2015 05:31:44 -0000

> From my perspective, deploying a CLAT ubiquitously in host operating systems
> will have two deleterious effects: 1) it will prolong the viability of IPv4
> literals in publicly reachable application services, requiring the
> maintenance of the PLAT service, and the public IPv4 routing that entails,
> over a longer period of transition, possibly indefinitely; and, 2) it will
> slow the transition of applications in your local network to using IPv6
> instead of IPv4, because the IPv4-only legacy interfaces will still be a
> viable, if somewhat impaired, despite your having removed IPv4 routing from
> local subnets.

Regarding "1": sure, fine, IPv4 literals and protocols with embedded
IPv4 addresses will be a thing for a while.  But let's be clear: it
*will* dwindle down to "rotary tone dialing" levels eventually.  So as
long as there's a mechanism that can support them I don't think our
future should be held hostage by them, as it were.

Regarding "2": I think this is not a function of any single network,
but rather the percentage of networks that have native IPv6 with
Carrier Pigeon IPv4.

One reason this whole thing, transition and discussion, is hard, I
would posit, is because we have to move through two or more integrals
to get to the desired end effect.  Allow me to be mathematically
dubious, just to make my point:

    [0a] Assumption: We're talking about IPv6-only networks being
preferred by operators over dualstack networks due to
[perceived|accrued] operational simplicity/cost/$METRIC.

    [0b] Assumption: A "general use" IPv6-only network requires some
form of IPv4 access, e.g. Carrier Pigeon IPv4, until a business
decision can be supported removing it.

These assumptions should be challenged of course, tempered by input
from operators with deployment experience.  My understanding is
something like this is the document actually under discussion (but not
yet drafted)?

    [1] How deployable an IPv6-only network may be is a kind of
integral, with respect to time, of the availability of Carrier Pigeon
IPv4 technologies, with respect to all the OSes on the devices that
might want to be attached to that network.

    [2] The number of deployed IPv6-only networks is a kind of
integral, with respect to time, of the deployable IPv6-only networks
in [1].

    [3] Awareness of native IPv6 versus Carrier Pigeon IPv4
performance problems and other issues is some function of the number
of deployed IPv6-only networks in [2], possibly as simple as a direct
proportionality but maybe also an integral with respect to time.

    [4] The prevalence of fixed/working IPv6-only applications,
websites, et cetera is a kind of integral, with respect to time, of
the awareness in [3].

So in this discussion, I think we're way back around #1 trying to
affect the kind of change in #4, but we have to move through 2 or 3
integrals to get there.

All this is not to say that it's hopeless.  Rather, I think there is
indeed a path here.


From nobody Tue Apr 14 01:42: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 E18141A0032 for ; Tue, 14 Apr 2015 01:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sks6oArRcpvv for ; Tue, 14 Apr 2015 01:42:13 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4271A002D for ; Tue, 14 Apr 2015 01:42:13 -0700 (PDT)
Received: from [186.134.14.206] (helo=[192.168.123.128]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YhwPw-000382-Rk; Tue, 14 Apr 2015 10:42:01 +0200
Message-ID: <552CD2CE.3070801@si6networks.com>
Date: Tue, 14 Apr 2015 05:41:50 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Merike Kaeo , v6ops@ietf.org
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 14 Apr 2015 08:42:15 -0000

Folks,

At the last v6ops meeting, there seemed to be agreement about including
some text noting that while results indicate that use of IPv6 EHs has
been found to result in packet drops, at least for transit ASes such
behavior is undesirable.

So this is a *first try* (please suggest edits to this text if you
think that's necessary):

"The results presented in this document indicate that in the scenarios
where the corresponding measurements were performed, the use of IPv6
extension headers can lead to packet drops. We note that, in particular,
packet drops occurring at transits Autonomous Systems is undesirable,
and it is expected that this situation will improve over time."

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492






From nobody Tue Apr 14 07:20: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 266F31ABD37 for ; Tue, 14 Apr 2015 07:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-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 vQ9xOngR7sxg for ; Tue, 14 Apr 2015 07:20:31 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6F1ABC75 for ; Tue, 14 Apr 2015 07:20:31 -0700 (PDT)
Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 997A246915 for ; Tue, 14 Apr 2015 10:20:33 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: JF Tremblay 
In-Reply-To: <552824B5.3050503@foobar.org>
Date: Tue, 14 Apr 2015 10:20:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B37499D-A0E0-4D33-9802-1F66E4EDB598@viagenie.ca>
References: <5526E8AD.2090201@foobar.org> <1314031813.3838791.1428619338706.JavaMail.yahoo@mail.yahoo.com> <4FC37E442D05A748896589E468752CAA0CDB0F11@PWN401EA160.ent.corp.bcbsm.com> <5528021E.3010500@foobar.org> <4FC37E442D05A748896589E468752CAA0CDB10E8@PWN401EA160.ent.corp.bcbsm.com> <552824B5.3050503@foobar.org>
To: v6ops list 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [v6ops] draIn ft-ietf-v6ops-design-choices 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, 14 Apr 2015 14:20:38 -0000

> On Apr 10, 2015, at 3:29 PM, Nick Hilliard  wrote:
>=20
> On 10/04/2015 19:11, Ackermann, Michael wrote:
>> I do not see any advantage in a BGP environment. =20
>=20
> Ok, sure.
>=20
> Can you now provide some concrete examples of where LLs are more
> appropriate than GUAs for BGP NH, and why?

I had the vague impression of having seen this discussion before=E2=80=A6.=
 after a bit of digging, this was covered in Chapter 3 of =E2=80=9CIPv6 =
Security=E2=80=9D, by Eric Vyncke and Scott Hogg. Pages 97-102 in my =
paper version.=20

While the pros and cons of using LL are discussed, the text doesn=E2=80=99=
t make a clear recommendation not to use them, so maybe this is where =
some people get the idea of using LL for single-hop BGP.=20

JF



From nobody Tue Apr 14 07:54: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 1634C1ACDFA for ; Tue, 14 Apr 2015 07:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level: 
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_82=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 fjhnXDteXCWt for ; Tue, 14 Apr 2015 07:54:17 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB6201ACE3C for ; Tue, 14 Apr 2015 07:53:32 -0700 (PDT)
Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E03B740219 for ; Tue, 14 Apr 2015 10:53:34 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: JF Tremblay 
In-Reply-To: 
Date: Tue, 14 Apr 2015 10:53:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com> 
To: v6ops list 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 14 Apr 2015 14:54:18 -0000

> On Apr 13, 2015, at 2:39 AM, Mikael Abrahamsson  =
wrote:
>=20
> 2.1.2. Regarding using ULAs. I have run into one instance in reality =
where an ISP numbered an interface from ULAs on a VERY popular large =
router vendor device. This meant that PTBs were generated with a ULA =
source address. This is obviously totally broken, and I think text =
warning about this should be added.

+1 on this, a warning regarding PTB would be a good addition. I=E2=80=99ve=
 seen this happen in an early 6RD deployment where ULAs were present on =
the relay. In that case, you almost have to add GUAs to every single =
interface where ULAs are present, as it can be hard to predict from =
which source the PTB will be generated.  =20

The limitation of using ULAs could be outlined better in this section =
(2.1.2), as they seem to be lumped together with GUAs in option b.


> I also question how common it is to use ULAs, with current wording it =
seems to indicate that both are quite common, which I don't agree with.

- Which part of the text indicates this? I read this again, but I must =
have missed it..=20

- Do you have actual data about ULA usage? As this is isn=E2=80=99t =
externally visible, one might be surprised at how commonly it is used. =20=



> 2.2.1. I agree with this, so my suggestion is that the ULA reference =
above is removed or severely downplay:ed, otherwise last sentence in =
2.2.1 needs to say GUA or ULA as next-hop address.

I somewhat agree here. ULA could very well be used as a next-hop, even =
for a multi-hop route.=20

JF




From nobody Tue Apr 14 09:48: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 E3D291B2EE4 for ; Tue, 14 Apr 2015 09:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.474
X-Spam-Level: 
X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NsobV6vXUceM for ; Tue, 14 Apr 2015 09:48:52 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id BF5AE1B2EE2 for ; Tue, 14 Apr 2015 09:48:51 -0700 (PDT)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,576,1422939600";  d="scan'208,217";a="853958351"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Apr 2015 12:34:01 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 14 Apr 2015 12:48:43 -0400
From: "George, Wes" 
To: Mark ZZZ Smith , v6ops list 
Date: Tue, 14 Apr 2015 12:48:42 -0400
Thread-Topic: [v6ops] draft-ietf-v6ops-design-choices WGLC
Thread-Index: AdB20t3iIMPRcbrDR92Duua5lZBIbA==
Message-ID: 
References:  <2042630785.2773277.1428970984807.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <2042630785.2773277.1428970984807.JavaMail.yahoo@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D152B96B4D776wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: 
Cc: Philip Matthews 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 14 Apr 2015 16:48:54 -0000

--_000_D152B96B4D776wesleygeorgetwcablecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpGcm9tOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdTxtYWlsdG86
bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4+DQpSZXBseS1UbzogTWFyayBaWlogU21pdGggPG1h
cmt6enpzbWl0aEB5YWhvby5jb20uYXU8bWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU+
Pg0KRGF0ZTogTW9uZGF5LCBBcHJpbCAxMywgMjAxNSBhdCA4OjIzIFBNDQpUbzogIkdlb3JnZSwg
V2VzIiA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTxtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2Nh
YmxlLmNvbT4+LCB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v
cmc+Pg0KQ2M6IFBoaWxpcCBNYXR0aGV3cyA8cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPG1haWx0
bzpwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2E+Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQt
aWV0Zi12Nm9wcy1kZXNpZ24tY2hvaWNlcyBXR0xDDQoNCg0KLyogSXQgc2VhbXMgb25lIG9mIHRo
ZSBvYmplY3Rpb25zIHBlb3BsZSBoYXZlIGlzIHRoYXQgdG8gdXNlIGEgTEwgYXMgYW4gZUJHUCBu
ZWlnaGJvciBhZGRyZXNzIHlvdSBhbHNvIGhhdmUgdG8gc3BlY2lmeSB0aGUgaW50ZXJmYWNlIG5h
bWUsIHdoZXJlIGFzIGlmIHlvdSB1c2VkIGEgR1VBLCB0aGUgaW50ZXJmYWNlIGlzIGltcGxpY2l0
IGluIHRoZSBCR1AgY29uZmlndXJhdGlvbiwgYXMgdGhlIGJpbmRpbmcgYmV0d2VlbiB0aGUgR1VB
IGFkZHJlc3MgYW5kIGludGVyZmFjZSBpcyBzb21ld2hlcmUgZWxzZSB3aXRoaW4gdGhlIGNvbmZp
Z3VyYXRpb24uIEkgdGhpbmsgaGF2aW5nIHRoZSBib3RoIHRoZSBuZWlnaGJvciBhZGRyZXNzIGFu
ZCB0aGUgaW50ZXJmYWNlIHRvIHVzZSB0byByZWFjaCBpdCBleHBsaWNpdGx5IHNwZWNpZmllZCBp
biB0aGUgQkdQIGNvbmZpZ3VyYXRpb24gaXMgbW9yZSByb2J1c3QsIGFzIGhvdyB0aGluZ3MgYXJl
IHRvIG9wZXJhdGUgaXMgbW9yZSBvYnZpb3VzIChJIHRyeSB0byBmb2xsb3cgYSBwcmluY2lwbGUg
b2YgbWFraW5nIGl0IG9idmlvdXMgaG93IHRoaW5ncyB3b3JrLCBzbyB0aGF0IGlmIHRoZXkgZmFp
bCwgaXQgaXMgbW9yZSBvYnZpb3VzIHdoZXJlIHRvIGxvb2sgZm9yIHRoZSBmYWlsdXJlLikNCg0K
DQpXR10gSW50ZXJlc3Rpbmcgdmlldy4gSSdtIG5vdCBjb252aW5jZWQgb2YgdGhlIHJvYnVzdG5l
c3Mgb2YgdGhhdCBjb21wYXJlZCB3aXRoIG90aGVyIG9wdGlvbnMgc2luY2UgaXQncyBhbHNvIHBv
c3NpYmxlIHRvIGFkZCBhIGNvbW1lbnQgdG8gdGhlIEJHUCBjb25maWcgaWRlbnRpZnlpbmcgd2hp
Y2ggaW50ZXJmYWNlIGl0J3MgYXNzb2NpYXRlZCB3aXRoLiBJIHRoaW5rIGl0IGNvdWxkIGJlIGFy
Z3VlZCBlaXRoZXIgd2F5IGFuZCB0aGlzIGxpa2VseSBjb21lcyBkb3duIHRvIHBlcnNvbmFsIHBy
ZWZlcmVuY2Ugb24geW91ciBwYXJ0LiBIb3dldmVyLCB3ZSdyZSBzdGFydGluZyB0byBnZXQgaW50
byBhIGRpc2N1c3Npb24gYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBpbnRlcmZh
Y2UsIHRoZSBCR1Agc2Vzc2lvbiwgYW5kIHRoZSBJUCwgYW5kIGhvdyB0aWdodGx5IGJvdW5kIG9u
ZSBzaG91bGQgYmUgdG8gdGhlIG90aGVyLiBXZSd2ZSBoYWQgYSB2YXJpYW50IG9mIHRoYXQgZGlz
Y3Vzc2lvbiB3aGVuIHRhbGtpbmcgYWJvdXQgaG93IGVhc3kvaGFyZCByZW51bWJlcmluZyBtaWdo
dCBiZSBzaW5jZSB0aGVyZSBhcmUgSVAtYWRkcmVzcyBkZXBlbmRlbnQgZWxlbWVudHMgb2YgdGhl
IGNvbmZpZ3VyYXRpb24gdGhhdCBleGlzdCBtdWx0aXBsZSBwbGFjZXMgaW5zdGVhZCBvZiBiZWlu
ZyBwYXJhbWV0ZXJpemVkIHNvIHRoYXQgdGhleSBjYW4gYmUgaW52b2tlZCBpbmRpcmVjdGx5IGFu
ZCBvbmx5IGRlZmluZWQgb25lIHBsYWNlLiBJdCdzIGludGVyZXN0aW5nIGZyb20gYSB0aGVvcmV0
aWNhbCBhbmQgcGhpbG9zb3BoaWNhbCBwZXJzcGVjdGl2ZSwgYnV0IEkgZG9uJ3Qga25vdyB0aGF0
IGl0IGhlbHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50IGluIHF1ZXN0aW9uLg0KDQoNClRoYW5r
cywNCg0KV2VzDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBt
eSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSSBoYXZlIG5vIGNvbnRyb2wgb3ZlciBpdC4NCi0t
LS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgRS1t
YWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENh
YmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRl
bnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBD
YWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp
bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUg
bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5
IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywg
b3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNo
bWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu
bGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNl
IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhl
IG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K

--_000_D152B96B4D776wesleygeorgetwcablecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf
U0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFw
dDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v
bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElO
Ry1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg
c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNw
YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5NYXJrIFpaWiBTbWl0aCAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXUiPm1hcmt6enpzbWl0
aEB5YWhvby5jb20uYXU8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk
Ij5SZXBseS1UbzogPC9zcGFuPk1hcmsgWlpaIFNtaXRoICZsdDs8YSBocmVmPSJtYWlsdG86bWFy
a3p6enNtaXRoQHlhaG9vLmNvbS5hdSI+bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdTwvYT4mZ3Q7
PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25kYXks
IEFwcmlsIDEzLCAyMDE1IGF0IDg6MjMgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6
Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtHZW9yZ2UsIFdlcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20iPndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208
L2E+Jmd0OywgdjZvcHMgbGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52
Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi
PkNjOiA8L3NwYW4+UGhpbGlwIE1hdHRoZXdzICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbGlwX21h
dHRoZXdzQG1hZ21hLmNhIj5waGlsaXBfbWF0dGhld3NAbWFnbWEuY2E8L2E+Jmd0Ozxicj4NCjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFt2Nm9wc10g
ZHJhZnQtaWV0Zi12Nm9wcy1kZXNpZ24tY2hvaWNlcyBXR0xDPGJyPg0KPC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjojMDAwOyBiYWNrZ3Jv
dW5kLWNvbG9yOiNmZmY7IGZvbnQtZmFtaWx5OkhlbHZldGljYSBOZXVlLUxpZ2h0LCBIZWx2ZXRp
Y2EgTmV1ZSBMaWdodCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgQXJpYWwsIEx1Y2lkYSBH
cmFuZGUsIFNhbnMtU2VyaWY7Zm9udC1zaXplOjE2cHgiPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8x
XzE0Mjg5Njk0MTg0NDJfOTk5MCIgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i
Zm9udC1mYW1pbHk6IEhlbHZldGljYSBOZXVlLUxpZ2h0LCBIZWx2ZXRpY2EgTmV1ZSBMaWdodCwg
SGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgQXJpYWwsIEx1Y2lkYSBHcmFuZGUsIFNhbnMtU2Vy
aWY7IGZvbnQtc2l6ZTogMTZweDsiIGlkPSJ5dWlfM18xNl8wXzFfMTQyODk2OTQxODQ0Ml85OTkz
Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2FOZXVlLCBIZWx2ZXRpY2EgTmV1
ZSwgSGVsdmV0aWNhLCBBcmlhbCwgTHVjaWRhIEdyYW5kZSwgU2Fucy1TZXJpZjsgZm9udC1zaXpl
OiAxNnB4OyIgaWQ9Inl1aV8zXzE2XzBfMV8xNDI4OTY5NDE4NDQyXzk5OTIiPg0KPGRpdiBjbGFz
cz0ieV9tc2dfY29udGFpbmVyIiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg5Njk0MTg0NDJfOTk5NCI+
DQo8ZGl2IGlkPSJ5aXYzNzY0OTI0MjYwIj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDI4OTY5
NDE4NDQyXzk5OTgiPjxzcGFuIGlkPSJ5aXYzNzY0OTI0MjYwT0xLX1NSQ19CT0RZX1NFQ1RJT04i
Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg5Njk0MTg0NDJfMTAwMTIiPg0KPGRpdiBzdHls
ZT0iY29sb3I6cmdiKDAsIDAsIDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjU1LCAyNTUp
O2ZvbnQtc2l6ZToxNnB4OyIgaWQ9Inl1aV8zXzE2XzBfMV8xNDI4OTY5NDE4NDQyXzEwMDExIj4N
CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyIgaWQ9InlpdjM3NjQ5MjQyNjB5dWlfM18xNl8w
XzFfMTQyODg3NjI1ODc2Nl8zMTAxMCI+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTZweDsiIGlk
PSJ5aXYzNzY0OTI0MjYweXVpXzNfMTZfMF8xXzE0Mjg4NzYyNTg3NjZfMzEwMDkiPg0KPGRpdiBj
bGFzcz0ieWl2Mzc2NDkyNDI2MHlfbXNnX2NvbnRhaW5lciIgaWQ9InlpdjM3NjQ5MjQyNjB5dWlf
M18xNl8wXzFfMTQyODg3NjI1ODc2Nl8zMTA1OSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWls
eTonSGVsdmV0aWNhIE5ldWUtTGlnaHQnLCAnSGVsdmV0aWNhIE5ldWUgTGlnaHQnLCAnSGVsdmV0
aWNhIE5ldWUnLCBIZWx2ZXRpY2EsIEFyaWFsLCAnTHVjaWRhIEdyYW5kZScsIHNhbnMtc2VyaWY7
Ij4NCi8qIEl0IHNlYW1zIG9uZSBvZiB0aGUgb2JqZWN0aW9ucyBwZW9wbGUgaGF2ZSBpcyB0aGF0
IHRvIHVzZSBhIExMIGFzIGFuIGVCR1AgbmVpZ2hib3IgYWRkcmVzcyB5b3UgYWxzbyBoYXZlIHRv
IHNwZWNpZnkgdGhlIGludGVyZmFjZSBuYW1lLCB3aGVyZSBhcyBpZiB5b3UgdXNlZCBhIEdVQSwg
dGhlIGludGVyZmFjZSBpcyBpbXBsaWNpdCBpbiB0aGUgQkdQIGNvbmZpZ3VyYXRpb24sIGFzIHRo
ZSBiaW5kaW5nIGJldHdlZW4gdGhlIEdVQSBhZGRyZXNzDQogYW5kIGludGVyZmFjZSBpcyBzb21l
d2hlcmUgZWxzZSB3aXRoaW4gdGhlIGNvbmZpZ3VyYXRpb24uIEkgdGhpbmsgaGF2aW5nIHRoZSBi
b3RoIHRoZSBuZWlnaGJvciBhZGRyZXNzIGFuZCB0aGUgaW50ZXJmYWNlIHRvIHVzZSB0byByZWFj
aCBpdCBleHBsaWNpdGx5IHNwZWNpZmllZCBpbiB0aGUgQkdQIGNvbmZpZ3VyYXRpb24gaXMgbW9y
ZSByb2J1c3QsIGFzIGhvdyB0aGluZ3MgYXJlIHRvIG9wZXJhdGUgaXMgbW9yZSBvYnZpb3VzIChJ
IHRyeSB0bw0KIGZvbGxvdyBhIHByaW5jaXBsZSBvZiBtYWtpbmcgaXQgb2J2aW91cyBob3cgdGhp
bmdzIHdvcmssIHNvIHRoYXQgaWYgdGhleSBmYWlsLCBpdCBpcyBtb3JlIG9idmlvdXMgd2hlcmUg
dG8gbG9vayBmb3IgdGhlIGZhaWx1cmUuKTwvZGl2Pg0KPGRpdiBjbGFzcz0ieWl2Mzc2NDkyNDI2
MHlfbXNnX2NvbnRhaW5lciIgaWQ9InlpdjM3NjQ5MjQyNjB5dWlfM18xNl8wXzFfMTQyODg3NjI1
ODc2Nl8zMTA1OSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhIE5ldWUt
TGlnaHQnLCAnSGVsdmV0aWNhIE5ldWUgTGlnaHQnLCAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRp
Y2EsIEFyaWFsLCAnTHVjaWRhIEdyYW5kZScsIHNhbnMtc2VyaWY7Ij4NCjxicj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldHXSBJbnRlcmVzdGluZyB2aWV3LiBJJ20gbm90IGNvbnZp
bmNlZCBvZiB0aGUgcm9idXN0bmVzcyBvZiB0aGF0IGNvbXBhcmVkIHdpdGggb3RoZXIgb3B0aW9u
cyBzaW5jZSBpdCdzIGFsc28gcG9zc2libGUgdG8gYWRkIGEgY29tbWVudCB0byB0aGUgQkdQIGNv
bmZpZyBpZGVudGlmeWluZyB3aGljaCBpbnRlcmZhY2UgaXQncyBhc3NvY2lhdGVkIHdpdGguIEkg
dGhpbmsgaXQgY291bGQgYmUgYXJndWVkIGVpdGhlciB3YXkgYW5kIHRoaXMgbGlrZWx5DQogY29t
ZXMgZG93biB0byBwZXJzb25hbCBwcmVmZXJlbmNlIG9uIHlvdXIgcGFydC4gSG93ZXZlciwgd2Un
cmUgc3RhcnRpbmcgdG8gZ2V0IGludG8gYSBkaXNjdXNzaW9uIGFib3V0IHRoZSByZWxhdGlvbnNo
aXAgYmV0d2VlbiB0aGUgaW50ZXJmYWNlLCB0aGUgQkdQIHNlc3Npb24sIGFuZCB0aGUgSVAsIGFu
ZCBob3cgdGlnaHRseSBib3VuZCBvbmUgc2hvdWxkIGJlIHRvIHRoZSBvdGhlci4gV2UndmUgaGFk
IGEgdmFyaWFudCBvZiB0aGF0IGRpc2N1c3Npb24NCiB3aGVuIHRhbGtpbmcgYWJvdXQgaG93IGVh
c3kvaGFyZCByZW51bWJlcmluZyBtaWdodCBiZSBzaW5jZSB0aGVyZSBhcmUgSVAtYWRkcmVzcyBk
ZXBlbmRlbnQgZWxlbWVudHMgb2YgdGhlIGNvbmZpZ3VyYXRpb24gdGhhdCBleGlzdCBtdWx0aXBs
ZSBwbGFjZXMgaW5zdGVhZCBvZiBiZWluZyBwYXJhbWV0ZXJpemVkIHNvIHRoYXQgdGhleSBjYW4g
YmUgaW52b2tlZCBpbmRpcmVjdGx5IGFuZCBvbmx5IGRlZmluZWQgb25lIHBsYWNlLiBJdCdzIGlu
dGVyZXN0aW5nDQogZnJvbSBhIHRoZW9yZXRpY2FsIGFuZCBwaGlsb3NvcGhpY2FsIHBlcnNwZWN0
aXZlLCBidXQgSSBkb24ndCBrbm93IHRoYXQgaXQgaGVscHMgdG8gaW1wcm92ZSB0aGUgZG9jdW1l
bnQgaW4gcXVlc3Rpb24uJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImNvbG9yOiMwMDA7IGJhY2tncm91bmQtY29sb3I6I2ZmZjsgZm9udC1mYW1p
bHk6SGVsdmV0aWNhIE5ldWUtTGlnaHQsIEhlbHZldGljYSBOZXVlIExpZ2h0LCBIZWx2ZXRpY2Eg
TmV1ZSwgSGVsdmV0aWNhLCBBcmlhbCwgTHVjaWRhIEdyYW5kZSwgU2Fucy1TZXJpZjtmb250LXNp
emU6MTZweCI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhIE5ldWUtTGlnaHQs
IEhlbHZldGljYSBOZXVlIExpZ2h0LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBBcmlhbCwg
THVjaWRhIEdyYW5kZSwgU2Fucy1TZXJpZjsgZm9udC1zaXplOiAxNnB4OyIgaWQ9Inl1aV8zXzE2
XzBfMV8xNDI4OTY5NDE4NDQyXzk5OTMiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl
dGljYU5ldWUsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIEFyaWFsLCBMdWNpZGEgR3JhbmRl
LCBTYW5zLVNlcmlmOyBmb250LXNpemU6IDE2cHg7IiBpZD0ieXVpXzNfMTZfMF8xXzE0Mjg5Njk0
MTg0NDJfOTk5MiI+DQo8ZGl2IGNsYXNzPSJ5X21zZ19jb250YWluZXIiIGlkPSJ5dWlfM18xNl8w
XzFfMTQyODk2OTQxODQ0Ml85OTk0Ij4NCjxkaXYgaWQ9InlpdjM3NjQ5MjQyNjAiPg0KPGRpdiBp
ZD0ieXVpXzNfMTZfMF8xXzE0Mjg5Njk0MTg0NDJfOTk5OCI+PHNwYW4gaWQ9InlpdjM3NjQ5MjQy
NjBPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyODk2OTQx
ODQ0Ml8xMDAxMiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwgMCwgMCk7YmFja2dyb3VuZC1j
b2xvcjpyZ2IoMjU1LCAyNTUsIDI1NSk7Zm9udC1zaXplOjE2cHg7IiBpZD0ieXVpXzNfMTZfMF8x
XzE0Mjg5Njk0MTg0NDJfMTAwMTEiPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOjE2cHg7IiBpZD0i
eWl2Mzc2NDkyNDI2MHl1aV8zXzE2XzBfMV8xNDI4ODc2MjU4NzY2XzMxMDEwIj4NCjxkaXYgc3R5
bGU9ImZvbnQtc2l6ZToxNnB4OyIgaWQ9InlpdjM3NjQ5MjQyNjB5dWlfM18xNl8wXzFfMTQyODg3
NjI1ODc2Nl8zMTAwOSI+DQo8ZGl2IGNsYXNzPSJ5aXYzNzY0OTI0MjYweV9tc2dfY29udGFpbmVy
IiBpZD0ieWl2Mzc2NDkyNDI2MHl1aV8zXzE2XzBfMV8xNDI4ODc2MjU4NzY2XzMxMDU5IiBkaXI9
Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5OidIZWx2ZXRpY2EgTmV1ZS1MaWdodCcsICdIZWx2ZXRp
Y2EgTmV1ZSBMaWdodCcsICdIZWx2ZXRpY2EgTmV1ZScsIEhlbHZldGljYSwgQXJpYWwsICdMdWNp
ZGEgR3JhbmRlJywgc2Fucy1zZXJpZjsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGli
cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+VGhhbmtz
LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250
LXNpemU6IDExcHQ7Ij5XZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTI3
LCAxMjcsIDEyNyk7Ij5Bbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkg
bXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkgaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiBy
Z2IoMTI3LCAxMjcsIDEyNyk7Ij4tLS0tLS0tLS0tLTwvc3Bhbj48L3A+DQo8ZGl2PjxzcGFuIHN0
eWxlPSJjb2xvcjogcmdiKDEyNywgMTI3LCAxMjcpOyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXpl
PSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBU
aW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmls
ZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8g
VGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0
aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNz
ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWws
IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1
dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50
cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJp
dGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWls
IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1h
bmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFu
ZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_D152B96B4D776wesleygeorgetwcablecom_--


From nobody Tue Apr 14 09:56: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 823561A0204 for ; Tue, 14 Apr 2015 09:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.511
X-Spam-Level: 
X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 g6CAxP0VPX3x for ; Tue, 14 Apr 2015 09:56:04 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5251A017D for ; Tue, 14 Apr 2015 09:56:04 -0700 (PDT)
Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3D509403E7 for ; Tue, 14 Apr 2015 12:56:06 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: JF Tremblay 
In-Reply-To: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com>
Date: Tue, 14 Apr 2015 12:56:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6FDD63A0-F4E4-4E7D-A74B-85B9236A6EF1@viagenie.ca>
References: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com>
To: v6ops list 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 14 Apr 2015 16:56:06 -0000

> On Apr 12, 2015, at 2:00 PM, fred@cisco.com wrote:
>=20
> The working group last call for this draft announced last week
> continues for another week.  Please feel free to comment on it.

I=E2=80=99ve read this draft again (previous read was a long time ago) =
and find it useful for IPv6 implementer, both in an ISP and enterprise =
environment. In general, it provides advice of good quality, although I =
found that GUA and ULAs are often lumped together while their usage =
could/should be differentiated. Sorry if my comments regarding this come =
a bit late.=20

Detailed comments:=20
1. In 2.1.1, it might have been clearer to separate =E2=80=9Cdifferent =
physical interfaces=E2=80=9D vs =E2=80=9Cdifferent logical =
interfaces=E2=80=9D, therefore having options a, b (vlans) and c =
(physical). Some of the advantages listed belong to both a and b, with =
the additional advantage in b that traffic statistics are independent. =
This is mentioned in the last paragraph, but could be expressed more =
clearly. I=E2=80=99d argue that (a) is the most attractive option, while =
b (vlans) could be applied at some specific locations requiring it. =20

2. In sections in sections 2.1.2 and 2.2.1 GUAs and ULAs are grouped =
together in option b. Separating them would allow for finer-grain =
distinctions.
For example:=20
  + Traceroute: using ULAs will allow internal debugging with the proper =
interfaces, while a traceroute from an external IP might be blocked or =
be non-useful by leaking ULA information.=20
  + DNS: ULAs are likely to having meaning and rDNS information only =
within the internal network boundary.=20
  + In 2.2.1, ULAs are usually suitable for indirect static routes and =
redistribution, adding a note to this effect would be desirable.=20

3. In 2.1.2, I second Mikael=E2=80=99s suggestion to add text around =
ICMP reachability (especially PTB) when LL or ULA is used on interfaces. =
Again, separating ULA and GUA would help this.=20

4. In 2.3.1, I=E2=80=99ve seen implementations where single topology =
ISIS had been taken by protocol implementers to mean =E2=80=9CIPv4 =
single-topology=E2=80=9D. I=E2=80=99ve met issues running ISIS as single =
IPv6 topology mode. It might be worth mentioning in a general fashion at =
the end of the second-last paragraph. (for example =
s/flexibility/flexibility and stability/). No strong feeling about this =
one.=20

5. Also in 2.3.1 (last sentence): =E2=80=9CISIS is more secure because =
it runs at layer 2=E2=80=9D. Last time I checked, ISIS ran using CLNS, =
which is an OSI layer-3 protocol.=20

6. In the same sentence (last one of 2.3.1): =E2=80=9Crouters generally =
support more nodes in an ISIS area=E2=80=9D. Any vendor-neutral data to =
back this?=20
My understanding is that area size is, on most devices, CPU-constrained =
by the SPF calculation. As both IGPs use the same algorithm, one would =
think that the area limitations would be fairly similar for both =
protocols. ISIS=E2=80=99s TLVs might be programmatically simpler to =
process and therefore allow a slightly larger number of nodes/updates =
for the same processing budget, but I=E2=80=99ve never seen this as =
significant. I suggest dropping this whole sentence.=20

7. Section 2.4.1.1, second bullet, refers to =E2=80=9Cnote 1 above=E2=80=9D=
. I guess this is the second bullet of 2.4.1, but this could be made =
clearer.=20

JF


From nobody Tue Apr 14 10:58: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 19CDD1A1B59 for ; Tue, 14 Apr 2015 10:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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] 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 b68y3Jfmt1wV for ; Tue, 14 Apr 2015 10:58:35 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 D1ED91A1B23 for ; Tue, 14 Apr 2015 10:58:28 -0700 (PDT)
Received: by widdi4 with SMTP id di4so123779991wid.0 for ; Tue, 14 Apr 2015 10:58:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tClZ7x1b4UkO69R8XL4HONsQ+RIJWpntbkOIcY8UFWY=; b=HvTsaRl/DR+ozuYgF/cN5qB/O96hCbjIS80f3H/+mQrklqsz7y8bZU6GC023DCexlO Clbbf+jPIWDwquGcRIxFzdsXIEqgWfBubbcZ5fpIA+2MHDVD6q+xW0l9Oe6TdJkGqFMm 4y0PHYdk9oHzwJo1Q8HpYLhhfn8PKCEzYymjY=
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=tClZ7x1b4UkO69R8XL4HONsQ+RIJWpntbkOIcY8UFWY=; b=g7xArFxqT2o/vw9+pNf7FqIJXfcvWjg9vdux0kjEOpzfSF25ziPYiplnqS1lGMc4Ko K+NTOrmWgUZdrdoBEjamxet/aZkp0n8xBDMLuJ5Gve7hSg1RBrwicYonzCCnUloXL+LV IXcBkiV8wHltGRR05ea3KmZycTDqKrPpqB6Lgu2uen1tffAEuns0XYy0PgD6VdypKG/W rfQreT46j/G7s9db02Ohe6WkJIfLUJpDJa+3EORYhmfoWW7ylVTvxLl+8mTzYpwpdrRf PC4pQVD67Tsh6YQVvwHHyk/WJ5KLNpxeUWp13ZGL06+1/W2jZ5U14T02+O5irWbj5Y3h JGnQ==
X-Gm-Message-State: ALoCoQmIm+wThh6uiXKs8PXuwMKlfnMF/4dTputAA15W9XL5mMboamj/4qlW5CI5D5220rk+VTzj
MIME-Version: 1.0
X-Received: by 10.194.71.208 with SMTP id x16mr40142396wju.129.1429034307514;  Tue, 14 Apr 2015 10:58:27 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Tue, 14 Apr 2015 10:58:27 -0700 (PDT)
In-Reply-To: 
References:            <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  
Date: Tue, 14 Apr 2015 10:58:27 -0700
Message-ID: 
From: James Woodyatt 
To: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary=047d7bfcead04583e20513b2fad4
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 14 Apr 2015 17:58:37 -0000

--047d7bfcead04583e20513b2fad4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 13, 2015 at 10:31 PM, Erik Kline  wrote:

> [I wrote:]

>                 [...] 1) it will prolong the viability of IPv4
> > literals in publicly reachable application services, requiring the
> > maintenance of the PLAT service, and the public IPv4 routing that
> entails,
> > over a longer period of transition, possibly indefinitely; and, 2) it
> will
> > slow the transition of applications in your local network to using IPv6
> > instead of IPv4, because the IPv4-only legacy interfaces will still be =
a
> > viable, if somewhat impaired, despite your having removed IPv4 routing
> from
> > local subnets.
>
> Regarding "1": sure, fine, IPv4 literals and protocols with embedded
> IPv4 addresses will be a thing for a while.  But let's be clear: it
> *will* dwindle down to "rotary tone dialing" levels eventually.  So as
> long as there's a mechanism that can support them I don't think our
> future should be held hostage by them, as it were.
>

Eew. That analogy smells bad to me because "rotary tone dialing" is a
localized network protocol between subscriber equipment and the signaling
system, whereas IPv4 literals are a global application signaling protocol
over the top of the network. The network effect is different in each case.
I think that's very relevant to the discussion.


> Regarding "2": I think this is not a function of any single network,
> but rather the percentage of networks that have native IPv6 with
> Carrier Pigeon IPv4.
>
> One reason this whole thing, transition and discussion, is hard, I
> would posit, is because we have to move through two or more integrals
> to get to the desired end effect.  Allow me to be mathematically
> dubious, just to make my point: [...]
>

This argument is the most persuasive one I currently see. It's neither
simple nor obvious, and I don't see any consensus behind it=E2=80=94 so, I =
doubt
it's well understood by the community. Shorter james: that's persuasive,
but not enough to make me think a BCP is in order.

Again, I repeat: I would probably support 6MAN publishing a matching pair
of Informational specifications that update RFC 3493 and RFC 3542 with
considerations for hosts with a CLAT function integrated. Let's see what
happens when we try to write those documents and get them published. Then
let's revisit the idea of publishing a BCP recommending the ubiquitous
deployment CLAT functions in host operating systems.


--=20
james woodyatt 
Nest Labs, Communications Engineering

--047d7bfcead04583e20513b2fad4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Apr 13, 2015 at 10:31 PM, Erik Kline <ek@google.com> wrote:<=
/div>
[I wrote:=
]=C2=A0
> =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]=C2=A01) it will prol=
ong the viability of IPv4

> literals in publicly reachable application services, requiring the

> maintenance of the PLAT service, and the public IPv4 routing that enta=
ils,

> over a longer period of transition, possibly indefinitely; and, 2) it =
will

> slow the transition of applications in your local network to using IPv=
6

> instead of IPv4, because the IPv4-only legacy interfaces will still be=
 a

> viable, if somewhat impaired, despite your having removed IPv4 routing=
 from

> local subnets.



Regarding "1": sure, fine, IPv4 literals and protocols wit=
h embedded

IPv4 addresses will be a thing for a while.=C2=A0 But let's be clear: i=
t

*will* dwindle down to "rotary tone dialing" levels eventually.=
=C2=A0 So as

long as there's a mechanism that can support them I don't think our=


future should be held hostage by them, as it were.
Eew. That analogy smells bad to me because "rotary tone di=
aling" is a localized network protocol between subscriber equipment an=
d the signaling system, whereas IPv4 literals are a global application sign=
aling protocol over the top of the network. The network effect is different=
 in each case. I think that's very relevant to the discussion.
=C2=A0

Regarding "2": I think this is not a function of any single netwo=
rk,

but rather the percentage of networks that have native IPv6 with

Carrier Pigeon IPv4.



One reason this whole thing, transition and discussion, is hard, I

would posit, is because we have to move through two or more integrals

to get to the desired end effect.=C2=A0 Allow me to be mathematically

dubious, just to make my point: [...]

This argume=
nt is the most persuasive one I currently see. It's neither simple nor =
obvious, and I don't see any consensus behind it=E2=80=94 so, I doubt i=
t's well understood by the community. Shorter james: that's persuas=
ive, but not enough to make me think a BCP is in order.

Again, I repeat:=C2=A0I would probably support 6MAN pub=
lishing a matching pair of Informational specifications that update RFC 349=
3 and RFC 3542 with considerations for hosts with a CLAT function integrate=
d. Let's see what happens when we try to write those documents and get =
them published. Then let's revisit the idea of publishing a BCP recomme=
nding the ubiquitous deployment CLAT functions in host operating systems.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Comm=
unications Engineering




--047d7bfcead04583e20513b2fad4--


From nobody Tue Apr 14 13:38: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 E36D51B2A84 for ; Tue, 14 Apr 2015 13:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyOOibCXg1k0 for ; Tue, 14 Apr 2015 13:38:25 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 A23811B2A81 for ; Tue, 14 Apr 2015 13:38:25 -0700 (PDT)
Received: by pabtp1 with SMTP id tp1so24217128pab.2 for ; Tue, 14 Apr 2015 13:38:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4GbMRlWlbjtcu8yPHNCPspvxqwlkmiAsTeSuGvnYJxI=; b=wriqaui4/SrEYMRGreXXkYE6Kae5+rxaQn6m/YsuFBj+trI0Dsf6hRXMHqSAm70vc6 +wjBr6y85c3K1QxORLTjUub70NqJqMXqyo6euKPNMQG/g6hlNhtA9FaPLp9RLRVNiLyk 8pC2DbPtr1vIwheWqCPhD7D9i6Kgc5QOyih8Ntc+0ZPsua6njxHFUWEcmXG63IVrZAqr 9/6S/IPw7CzvStYu3vtesb4YH5O3f7m0rvDw1mRpMF7C5P60fSy4Qvfzi69AlbAthPs/ EDNdYfzRAodkgi2hKspJeFydsMQxpvIA8nj98gI7hygs2uaGi+MEtPNdq3dBMkcDKZ6E hdrw==
X-Received: by 10.68.202.234 with SMTP id kl10mr38908339pbc.37.1429043905356;  Tue, 14 Apr 2015 13:38:25 -0700 (PDT)
Received: from ?IPv6:2406:e007:632e:1:28cc:dc4c:9703:6781? ([2406:e007:632e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id mt11sm1960369pbc.20.2015.04.14.13.38.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 13:38:24 -0700 (PDT)
Message-ID: <552D7ABF.1080509@gmail.com>
Date: Wed, 15 Apr 2015 08:38:23 +1200
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.6.0
MIME-Version: 1.0
To: Fernando Gont ,  Merike Kaeo , v6ops@ietf.org
References: <552CD2CE.3070801@si6networks.com>
In-Reply-To: <552CD2CE.3070801@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 14 Apr 2015 20:38:27 -0000

On 14/04/2015 20:41, Fernando Gont wrote:
...
> "The results presented in this document indicate that in the scenarios
> where the corresponding measurements were performed, the use of IPv6
> extension headers can lead to packet drops. We note that, in particular,
> packet drops occurring at transits Autonomous Systems is undesirable,
> and it is expected that this situation will improve over time."

s/expected/hoped/ perhaps.

   Brian


From nobody Tue Apr 14 13:51:52 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 CE4721A1BAA; Tue, 14 Apr 2015 13:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_24=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 9w_72xVkFwpt; Tue, 14 Apr 2015 13:51:49 -0700 (PDT)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (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 6C57F1A1B9C; Tue, 14 Apr 2015 13:51:49 -0700 (PDT)
Received: by pdbqd1 with SMTP id qd1so25368335pdb.2; Tue, 14 Apr 2015 13:51:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AfJqHyfZ1E7Upcakq1RAxDQ/ijrd2NViF7YZrmEaZ1o=; b=O6z6YhGu8H3XgFxY8Ly1PdhLdF+OjAysu6GPYdUeVa0PhvcjEtP6gdGxySFfBQLHMF M28VSabvVd4jbp29vxEUmU3xXdTe7grASVZVYWiSfAfz7BUy3C53vhmL2wgHmbXMDlRQ MV1JdhW+cRH8gnxXXIVom5gaAV9QM3Oc8WgTfDFFacssi+IRuC0JzY/CujGH6kP4ALLi L2H9c/BprEIi7Gr4797bAQ7hqHzQaHdPmU/KsK7BJI093FtrrXJBtY8b6J2DAjqbtZe2 1rScVP2ji3UCqcK+yaEVyCp3f8JbjfmiIdj8NAeIbF8QtffHi+5sRVMzRMO+q4EYvs2V L8wA==
X-Received: by 10.70.129.202 with SMTP id ny10mr39443189pdb.107.1429044709165;  Tue, 14 Apr 2015 13:51:49 -0700 (PDT)
Received: from ?IPv6:2406:e007:632e:1:28cc:dc4c:9703:6781? ([2406:e007:632e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id yy2sm1986641pbb.6.2015.04.14.13.51.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 13:51:47 -0700 (PDT)
Message-ID: <552D7DE3.8060607@gmail.com>
Date: Wed, 15 Apr 2015 08:51:47 +1200
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.6.0
MIME-Version: 1.0
To: Mikael Abrahamsson ,  "Fred Baker (fred)" 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: IPv6 Ops WG , "sunset4@ietf.org" 
Subject: Re: [v6ops] v6ops charter update discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 20:51:51 -0000

On 14/04/2015 17:19, Mikael Abrahamsson wrote:
> On Mon, 13 Apr 2015, Fred Baker (fred) wrote:
>=20
>> Lee and I are reviewing the v6ops charter. I have attached a proposed =
charter and diffs against the current one. Joel has not
>> commented on this yet, and while we have run it by the sunset4 chairs,=
 we haven=E2=80=99t gotten a reading from them. Sunset4 is
>> relevant because possibly the ipv4-as-a-service discussion would be be=
tter handled there. In this email, I=E2=80=99m soliciting
>> opinions in general.
>>
>> The charter update started with Lee feeling that the fourth bullet of =
our current charter, which reads
>>    4. Publish Informational or BCP RFCs that identify and analyze
>>       solutions for deploying IPv6 within common network environments,=

>>       such as ISP Networks, Enterprise Networks, Unmanaged Networks
>>       (Home/Small Office), and Cellular Networks.
>>       (http://datatracker.ietf.org/wg/v6ops/charter/)
>> is largely done. We know how to deploy IPv6.
>=20
> Hm, while I generally agree with you, does this mean that these kinds o=
f RFCs will be out-of-scope for v6ops going forward? I
> would hate for us to take this out of the charter and then turn people =
away when they show up with a document for a solution we
> didn't think of yet.

I agree that we should not exclude such work, and it could be that the
existing documents need corrections, but on the other hand the time
for soliciting new work in this area is past.

> Or perhaps paragraph 1 is enough to allow for capturing these kinds of =
documents?

Yes, because it mentions "solutions".

>>    4. Describe an operational roadmap to IPv6-only network deployment,=

>>       with or without IPv4 delivered as an overlay or translation
>>       service.
>=20
> Fully agreed.
>=20
>> On another point, Lee and I have been discussing the operational repor=
ts we had at IETF 92, and feel that was time well spent.
>> Those had a common thread, which was the deployment of Softwire=E2=80=99=
s MAP-E and MAP-T technologies in their networks. We are
>> thinking about asking companies deploying IPv6 in Europe, Asia, and So=
uth America to make reports in the coming three
>> meetings, on their IPv6 deployments and the issues they face. Would th=
at be of general interest? How would you propose to tune
>> that concept?
>=20
> I think this is worthwile, as long as it's not going to be come a long =
list of 10-15 minute presentations saying the same thing.
> For those, we can keep it on the list. I always welcome operational rep=
orts in the meetings, but they need to contain news, not
> "we experienced the same thing as  and solved it the same way".

Correct, and I don't think it needs to be strictly regional, although
that may be a travel optimisation. I would suggesting soliciting lightnin=
g
talks on ipv6-ops@lists.cluenet.de. There are handy messages there from
time to time, like
http://lists.cluenet.de/pipermail/ipv6-ops/2014-December/010402.html

   Brian

>=20
> I would like to hear from the ds.lite deployers out there, I know they =
exist. Also from 464XLAT+NAT64 deployments (probably in
> mobile).
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From nobody Tue Apr 14 14:09:41 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 0D49D1B2FD4 for ; Tue, 14 Apr 2015 14:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms6WlQtYo53A for ; Tue, 14 Apr 2015 14:09:38 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607281B2FD2 for ; Tue, 14 Apr 2015 14:09:35 -0700 (PDT)
Received: from [186.134.14.206] (helo=[192.168.123.128]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Yi85J-0006l0-83; Tue, 14 Apr 2015 23:09:29 +0200
Message-ID: <552D7D20.4020308@si6networks.com>
Date: Tue, 14 Apr 2015 17:48:32 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Brian E Carpenter ,  Merike Kaeo , v6ops@ietf.org
References: <552CD2CE.3070801@si6networks.com> <552D7ABF.1080509@gmail.com>
In-Reply-To: <552D7ABF.1080509@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 14 Apr 2015 21:09:40 -0000

On 04/14/2015 05:38 PM, Brian E Carpenter wrote:
> On 14/04/2015 20:41, Fernando Gont wrote:
> ...
>> "The results presented in this document indicate that in the scenarios
>> where the corresponding measurements were performed, the use of IPv6
>> extension headers can lead to packet drops. We note that, in particular,
>> packet drops occurring at transits Autonomous Systems is undesirable,
>> and it is expected that this situation will improve over time."
> 
> s/expected/hoped/ perhaps.

Yes -- that's what I really meant (English as 2nd language effect :-) ).

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Apr 14 19:31: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 82F561A8911 for ; Tue, 14 Apr 2015 19:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.578
X-Spam-Level: **
X-Spam-Status: No, score=2.578 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 DCFZh_Zvaoqj for ; Tue, 14 Apr 2015 19:31:06 -0700 (PDT)
Received: from tor-smtp-01.primus.ca (unknown [67.230.159.19]) by ietfa.amsl.com (Postfix) with ESMTP id B89C81A8873 for ; Tue, 14 Apr 2015 19:31:06 -0700 (PDT)
Received: from 191-247-224-10.3g.claro.net.br ([191.247.224.10] helo=[192.168.43.85]) by tor-smtp-01.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1YiD6V-0000m6-Qg; Tue, 14 Apr 2015 22:31:05 -0400
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-4--213715733
From: Philip Matthews 
In-Reply-To: 
Date: Tue, 14 Apr 2015 22:30:50 -0400
Message-Id: 
References: 
To: Wes George , Mark ZZZ Smith 
X-Mailer: Apple Mail (2.1085)
X-Authenticated: philip_matthews - 191-247-224-10.3g.claro.net.br ([192.168.43.85]) [191.247.224.10]
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 02:31:09 -0000

--Apple-Mail-4--213715733
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


Wes and Mark (and anyone else)

Would you agree with me that, if one does use LLAs for eBGP endpoints, =
then:
* One should use LLAs at both ends,  AND
* One should explicitly configure the LLAs at both ends
?

- Philip

PS. Wes: Will do on your "Other comments".  But it seems we are still =
debating your main point.


On 2015-04-13, at 9:43 , George, Wes wrote:

> It's a little unclear who said what given the way text was quoted, so =
I'm just replying to the snippet of text I think is relevant inline =
below with WG], and then a few other LC comments follow below it.
>=20
> Thanks,
> =20
> Wes
> =20
>=20
> / I value predictability and robustness. Having a eBGP session very =
specifically tied to an interface tightly couples the eBGP session and =
the traffic for the prefixes that eBGP session is announcing. The small =
amount of extra effort required to change a session to a different =
interface creates further opportunity to catch errors. In some cases, =
the actual error might be minor, but the consequences of them can be =
very significant outages.
>=20
> WG] That is true whether you use a LL or a GUA if you use the =
interface IP address for eBGP peering instead of loopback multi hop. =
What's your point in favor of LLN here? Also, what errors are you =
talking about catching where more manual reconfiguration is the right =
answer?
>=20
> / LLs don't have to be tied to specific hardware addresses, they can =
be statically set if this is a concern, and hopefully in the future, =
RFC7217 will be implemented for them in routers, as this is one of the =
specific use cases for them.
>=20
> WG] it's worse than that. If you don't statically set LL addresses, =
they don't show up in the interface configuration, and because they're =
only locally significant, you have an awful time if you want to actually =
find the router or interface that is associated with the next-hop (say =
when chasing a next-hop rewrite problem), because you can't find it in =
the routing table, and you can't grep through a config repository for =
the address, and it likely won't be in DNS. The closest you might be =
able to get is to grep for the address and find the router with the =
other side of the iBGP session, but this won't work for eBGP because =
there is no relationship between the neighbor addresses like there is =
with GUA (+1 / -1).
>=20
> Philip you may want to add something like this in 2.4.2 (or in 2.1.2 =
since it's not just relevant to BGP.)
>=20
> Other comments:=20
> You may want to add a reference to RFC 7439 in 2.4.1 last bullet about =
MPLS and IPv6
> 2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly referred =
to as TCP AO, so it'd be better to say "MD5 (RFC2385), which while still =
in wide use, has been obsoleted by TCP AO (RFC5925)"
>=20
>=20
> =20
> Anything below this line has been added by my company=92s mail server, =
I have no control over it.
> -----------
>=20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.


--Apple-Mail-4--213715733
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252




On 2015-04-13, at 9:43 , =
George, Wes wrote:












It's a little unclear who said what given the way text was quoted, =
so I'm just replying to the snippet of text I think is relevant inline =
below with WG], and then a few other LC comments follow below it.




























/ I =
value predictability and robustness. Having a eBGP session very =
specifically
 tied to an interface tightly couples the eBGP session and the traffic =
for the prefixes that eBGP session is announcing. The small amount of =
extra effort required to change a session to a different interface =
creates further opportunity to catch errors. In some
 cases, the actual error might be minor, but the consequences of them =
can be very significant outages.
















WG] That is true whether you use a LL or a GUA if you use the =
interface IP address for eBGP peering instead of loopback multi hop. =
What's your point in favor of LLN here? Also, what errors are you =
talking about catching where
more manual =
reconfiguration is the right answer?


















/ LLs don't have to be tied to specific hardware addresses, they can be =
statically set if this is a concern, and hopefully in the future, =
RFC7217 will be implemented for them in routers, as this is one of the =
specific use cases for them.
















WG] it's worse than that. If you don't statically set LL addresses, =
they don't show up in the interface configuration, and because they're =
only locally significant, you have an awful time if you want to actually =
find the router or interface that is associated
 with the next-hop (say when chasing a next-hop rewrite problem), =
because you can't find it in the routing table, and you can't grep =
through a config repository for the address, and it likely won't be in =
DNS. The closest you might be able to get is to grep
 for the address and find the router with the other side of the iBGP =
session, but this won't work for eBGP because there is no relationship =
between the neighbor addresses like there is with GUA (+1 / -1).







Philip you may want to add something like this in 2.4.2 (or in =
2.1.2 since it's not just relevant to BGP.)







Other comments: 


You may want to add a reference to RFC 7439 in 2.4.1 last bullet =
about MPLS and IPv6


2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly =
referred to as TCP AO, so it'd be better to say "MD5 (RFC2385), which =
while still in wide use, has been obsoleted by TCP AO (RFC5925)"












 




Anything below this line has been added by my =
company=92s mail server, I have no control over =
it.
-----------














This E-mail and any of =
its attachments may contain Time Warner Cable proprietary information, =
which is privileged, confidential, or subject to copyright belonging to =
Time Warner Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If =
you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have =
received this E-mail in error, please notify the sender immediately and =
permanently delete the original and any copy of this E-mail and any =
printout.







=

--Apple-Mail-4--213715733--


From nobody Tue Apr 14 19:48:59 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 D1A411B29AA for ; Tue, 14 Apr 2015 19:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.502
X-Spam-Level: **
X-Spam-Status: No, score=2.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, 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 vS7loj8eOuF5 for ; Tue, 14 Apr 2015 19:48:55 -0700 (PDT)
Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E646C1B29BC for ; Tue, 14 Apr 2015 19:48:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429066108; bh=elaOQMT6vqAghCKx8AQpmONrpLKY68WjA9VnJUNn8ac=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=XDLMVQFl/vawefOCJvnA7vKQzVg8zsJj8HXK4QOiujv/Le8qr6qOdV1sR7pXIPOpBF8MEGP76cbbqB123wUfiKMujEa/0XCl2iMZWLjaSljzfEkh3B1nN4uvbyTSSwVtYZG6uQveY5RJhM8jjYCzDgG72CnlFtqEdW/k2aWcSeSUFLKVhUBQMJEvUHHt6eZSiDPvv/L9tlVQkmcSfp39djuMhTr6RDj/mnUcx4ioFc43k/b++9CTebqWh0Gp35pe45lVDbUVEElxrLTmINMlSQl9nrRmOPcmbesHcJwA81neuH8gewTwh3pq/8RKbaof5HgeBSFI3foA87VdtXwPAA==
Received: from [66.196.81.174] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 15 Apr 2015 02:48:28 -0000
Received: from [98.139.212.193] by tm20.bullet.mail.bf1.yahoo.com with NNFMP;  15 Apr 2015 02:48:28 -0000
Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 15 Apr 2015 02:48:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 96164.89541.bm@omp1002.mail.bf1.yahoo.com
X-YMail-OSG: tQJ8RhsVM1lG_GznC9zQoUAp9tOLZM3CzjE1op9razd2cFXdTwouwmFNraN6UoS bDPqEjeBYltWJQVfmZGhnH7YQg1k5axzYUCEMNqB3Lfc4B7wj_Qi_l2_bm9xhTeOQxnliC_s1qDV OGiFqNfUC0n6oOoPJiaD7Z3O3Pg3nLxWiM4JksReGbePvbCOBh3OrMs6IqyTvB4I_4vXvyHaOR4R 0vG_Lx3okFyS5alQSUSQoqBp5HVspWI2few_IHFdLqL5nu3kmFRsie3IT9hRctErvsSASQy_9Ju0 dH8sdB863khyaBDTFdJ4krU27MW911wl7mfKtdzzMpGnvu.ELdiho8xeFHs2UIhetbpnzYfGJWDC 8NjGOIhKmXVmcdZ7PjMBP790EkhM0vJLwMdw5lL2oZ1IsFZFlNtUh4_ZKZ8XtiGZp5SvD2XBNyx0 S8aZO1Wqmh_Y9fY69GCrx0rPn6p6UwEdcnKkIXV.lsQrGW5XeiE1tnS1bOu43Tq9t2h6ia6whdPQ 8Q7wVaUzQJSPjItjrGc4dwte4o.uWd7yAkxqIvem5bS8OhAo.
Received: by 66.196.81.105; Wed, 15 Apr 2015 02:48:27 +0000 
Date: Wed, 15 Apr 2015 02:48:26 +0000 (UTC)
From: Mark ZZZ Smith 
To: Philip Matthews ,  Wes George 
Message-ID: <322748212.3927358.1429066106904.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_3927357_1951370893.1429066106891"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 02:48:57 -0000

------=_Part_3927357_1951370893.1429066106891
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes and Yes.
More generally it is probably good advice that if you are using a pair of a=
ddresses, use addresses of the same scope or type if possible, even though =
IPv6 can cope with different ones =C2=A0(e.g., LLs on both ends of an eBGP =
session, or ULAs or GUAs on both ends of a link rather than a GUA on one en=
d and a ULA on the other.).
I think this ties a bit back to something earlier I discussed about concept=
ually assigning a prefix to a "link" even though in actuality addresses fro=
m within a prefix are assigned to interfaces attached to the link, and not =
all interfaces need to have addresses from within the prefix. The common im=
plicit assumption in this "assigning prefixes to a link" mental model is th=
at all interfaces attached to the link will have addresses from within the =
prefix.
Regards,Mark.
      From: Philip Matthews 
 To: Wes George ; Mark ZZZ Smith =20
Cc: v6ops list =20
 Sent: Wednesday, 15 April 2015, 12:30
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =20

Wes and Mark (and anyone else)
Would you agree with me that, if one does use LLAs for eBGP endpoints, then=
:* One should use LLAs at both ends, =C2=A0AND* One should explicitly confi=
gure the LLAs at both ends?
- Philip
PS. Wes: Will do on your "Other comments". =C2=A0But it seems we are still =
debating your main point.



On 2015-04-13, at 9:43 , George, Wes wrote:


It's a little unclear who said what given the way text was quoted, so I'm j=
ust replying to the snippet of text I think is relevant inline below with W=
G], and then a few other LC comments follow below it.
Thanks, =C2=A0Wes =C2=A0
/ I value predictability and robustness. Having a eBGP session very specifi=
cally tied to an interface tightly couples the eBGP session and the traffic=
 for the prefixes that eBGP session is announcing. The small amount of extr=
a effort required to change a session to a different interface creates furt=
her opportunity to catch errors. In some cases, the actual error might be m=
inor, but the consequences of them can be very significant outages.
WG] That is true whether you use a LL or a GUA if you use the interface IP =
address for eBGP peering instead of loopback multi hop. What's your point i=
n favor of LLN here? Also, what errors are you talking about catching where=
more=C2=A0manual reconfiguration is the right answer?
/ LLs don't have to be tied to specific hardware addresses, they can be sta=
tically set if this is a concern, and hopefully in the future, RFC7217 will=
 be implemented for them in routers, as this is one of the specific use cas=
es for them.
WG] it's worse than that. If you don't statically set LL addresses, they do=
n't show up in the interface configuration, and because they're only locall=
y significant, you have an awful time if you want to actually find the rout=
er or interface that is associated with the next-hop (say when chasing a ne=
xt-hop rewrite problem), because you can't find it in the routing table, an=
d you can't grep through a config repository for the address, and it likely=
 won't be in DNS. The closest you might be able to get is to grep for the a=
ddress and find the router with the other side of the iBGP session, but thi=
s won't work for eBGP because there is no relationship between the neighbor=
 addresses like there is with GUA (+1 / -1).
Philip you may want to add something like this in 2.4.2 (or in 2.1.2 since =
it's not just relevant to BGP.)
Other comments:=C2=A0You may want to add a reference to RFC 7439 in 2.4.1 l=
ast bullet about MPLS and IPv62.4.2: 5925 is not MD5. It obsoleted MD5, but=
 it is properly referred to as TCP AO, so it'd be better to say "MD5 (RFC23=
85), which while still in wide use, has been obsoleted by TCP AO (RFC5925)"

=C2=A0Anything below this line has been added by my company=E2=80=99s mail =
server, I have no control over it.-----------

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.



  
------=_Part_3927357_1951370893.1429066106891
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


------=_Part_3927357_1951370893.1429066106891--


From nobody Tue Apr 14 20: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 C79801B2A24 for ; Tue, 14 Apr 2015 20:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.679
X-Spam-Level: 
X-Spam-Status: No, score=0.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] 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 QeOnks2NCu6l for ; Tue, 14 Apr 2015 20:09:19 -0700 (PDT)
Received: from tor-smtp-05.primus.ca (unknown [67.230.159.22]) by ietfa.amsl.com (Postfix) with ESMTP id A189A1B2A1D for ; Tue, 14 Apr 2015 20:09:19 -0700 (PDT)
Received: from 191-247-224-10.3g.claro.net.br ([191.247.224.10] helo=[192.168.43.85]) by tor-smtp-05.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1YiDhU-00069t-F6; Tue, 14 Apr 2015 23:09:18 -0400
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-5--211412122
From: Philip Matthews 
In-Reply-To: <322748212.3927358.1429066106904.JavaMail.yahoo@mail.yahoo.com>
Date: Tue, 14 Apr 2015 23:09:13 -0400
Message-Id: <9CC456D9-764A-4123-81D3-D297293658DC@magma.ca>
References:  <322748212.3927358.1429066106904.JavaMail.yahoo@mail.yahoo.com>
To: Mark ZZZ Smith 
X-Mailer: Apple Mail (2.1085)
X-Authenticated: philip_matthews - 191-247-224-10.3g.claro.net.br ([192.168.43.85]) [191.247.224.10]
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 03:09:22 -0000

--Apple-Mail-5--211412122
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Then perhaps one way to handle this in the draft is to rewrite the =
section to say "If you use LLAs as endpoint addresses, then here is best =
practice for how to do it; if you use GUAs as endpoint addresses, then =
here is best practice for how to do it; and here are the pros and cons =
of the two approaches".

Just trying to figure out a way forward to something everyone agrees is =
useful ...

- Philip

On 2015-04-14, at 22:48 , Mark ZZZ Smith wrote:

> Yes and Yes.
>=20
> More generally it is probably good advice that if you are using a pair =
of addresses, use addresses of the same scope or type if possible, even =
though IPv6 can cope with different ones  (e.g., LLs on both ends of an =
eBGP session, or ULAs or GUAs on both ends of a link rather than a GUA =
on one end and a ULA on the other.).
>=20
> I think this ties a bit back to something earlier I discussed about =
conceptually assigning a prefix to a "link" even though in actuality =
addresses from within a prefix are assigned to interfaces attached to =
the link, and not all interfaces need to have addresses from within the =
prefix. The common implicit assumption in this "assigning prefixes to a =
link" mental model is that all interfaces attached to the link will have =
addresses from within the prefix.
>=20
> Regards,
> Mark.
>=20
> From: Philip Matthews 
> To: Wes George ; Mark ZZZ Smith =
=20
> Cc: v6ops list =20
> Sent: Wednesday, 15 April 2015, 12:30
> Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
>=20
>=20
> Wes and Mark (and anyone else)
>=20
> Would you agree with me that, if one does use LLAs for eBGP endpoints, =
then:
> * One should use LLAs at both ends,  AND
> * One should explicitly configure the LLAs at both ends
> ?
>=20
> - Philip
>=20
> PS. Wes: Will do on your "Other comments".  But it seems we are still =
debating your main point.
>=20
>=20
>=20
>=20
> On 2015-04-13, at 9:43 , George, Wes wrote:
>=20
>=20
> It's a little unclear who said what given the way text was quoted, so =
I'm just replying to the snippet of text I think is relevant inline =
below with WG], and then a few other LC comments follow below it.
>=20
> Thanks,
> =20
> Wes
> =20
>=20
> / I value predictability and robustness. Having a eBGP session very =
specifically tied to an interface tightly couples the eBGP session and =
the traffic for the prefixes that eBGP session is announcing. The small =
amount of extra effort required to change a session to a different =
interface creates further opportunity to catch errors. In some cases, =
the actual error might be minor, but the consequences of them can be =
very significant outages.
>=20
> WG] That is true whether you use a LL or a GUA if you use the =
interface IP address for eBGP peering instead of loopback multi hop. =
What's your point in favor of LLN here? Also, what errors are you =
talking about catching where more manual reconfiguration is the right =
answer?
>=20
> / LLs don't have to be tied to specific hardware addresses, they can =
be statically set if this is a concern, and hopefully in the future, =
RFC7217 will be implemented for them in routers, as this is one of the =
specific use cases for them.
>=20
> WG] it's worse than that. If you don't statically set LL addresses, =
they don't show up in the interface configuration, and because they're =
only locally significant, you have an awful time if you want to actually =
find the router or interface that is associated with the next-hop (say =
when chasing a next-hop rewrite problem), because you can't find it in =
the routing table, and you can't grep through a config repository for =
the address, and it likely won't be in DNS. The closest you might be =
able to get is to grep for the address and find the router with the =
other side of the iBGP session, but this won't work for eBGP because =
there is no relationship between the neighbor addresses like there is =
with GUA (+1 / -1).
>=20
> Philip you may want to add something like this in 2.4.2 (or in 2.1.2 =
since it's not just relevant to BGP.)
>=20
> Other comments:=20
> You may want to add a reference to RFC 7439 in 2.4.1 last bullet about =
MPLS and IPv6
> 2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly referred =
to as TCP AO, so it'd be better to say "MD5 (RFC2385), which while still =
in wide use, has been obsoleted by TCP AO (RFC5925)"
>=20
>=20
> =20
> Anything below this line has been added by my company=92s mail server, =
I have no control over it.
> -----------
>=20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.
>=20
>=20
>=20


--Apple-Mail-5--211412122
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Then =
perhaps one way to handle this in the draft is to rewrite the section to =
say "If you use LLAs as endpoint addresses, then here is best practice =
for how to do it; if you use GUAs as endpoint addresses, then here is =
best practice for how to do it; and here are the pros and cons of the =
two approaches".

Just trying to figure out a way =
forward to something everyone agrees is useful =
...

- Philip

On =
2015-04-14, at 22:48 , Mark ZZZ Smith wrote:

Yes and =
Yes.

More generally it is probably =
good advice that if you are using a pair of addresses, use addresses of =
the same scope or type if possible, even though IPv6 can cope with =
different ones  (e.g., LLs on both ends of an eBGP session, or ULAs =
or GUAs on both ends of a link rather than a GUA on one end and a ULA on =
the other.).

I think this ties a bit back to =
something earlier I discussed about conceptually assigning a prefix to a =
"link" even though in actuality addresses from within a prefix are =
assigned to interfaces attached to the link, and not all interfaces need =
to have addresses from within the prefix. The common implicit assumption =
in this "assigning prefixes to a link" mental model is that all =
interfaces attached to the link will have addresses from within the =
prefix.

Regards,
Mark.

  
 
 =

 
 =
  =
From: Philip Matthews =
<philip_matthews@magma.ca><=
br> To: Wes George =
<wesley.george@twcable.com>=
;; Mark ZZZ Smith <markzzzsmith@yahoo.com.au>=
; 
Cc: v6ops list =
<v6ops@ietf.org> 
 =
Sent: Wednesday, 15 =
April 2015, 12:30
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices =
WGLC
  
 


Wes and Mark (and anyone =
else)

Would =
you agree with me that, if one does use LLAs for eBGP endpoints, =
then:
* One should use =
LLAs at both ends,  AND
* One should explicitly =
configure the LLAs at both ends
?

- Philip

PS. Wes: Will do on your "Other =
comments".  But it seems we are still debating your main =
point.




On 2015-04-13, at 9:43 , =
George, Wes wrote:










It's a little unclear who =
said what given the way text was quoted, so I'm just replying to the =
snippet of text I think is relevant inline below with WG], and then a =
few other LC comments follow below it.







Thanks,
 =
 
Wes
  





















/ I =
value predictability and robustness. Having a eBGP session very =
specifically
 tied to an interface tightly couples the eBGP session and the traffic =
for the prefixes that eBGP session is announcing. The small amount of =
extra effort required to change a session to a different interface =
creates further opportunity to catch errors. In some
 cases, the actual error might be minor, but the consequences of them =
can be very significant outages.
















WG] That is true whether =
you use a LL or a GUA if you use the interface IP address for eBGP =
peering instead of loopback multi hop. What's your point in favor of LLN =
here? Also, what errors are you talking about catching where
more manual =
reconfiguration is the right answer?


















/ LLs don't have to be tied to specific hardware addresses, they can be =
statically set if this is a concern, and hopefully in the future, =
RFC7217 will be implemented for them in routers, as this is one of the =
specific use cases for them.
















WG] it's worse than that. If you don't statically set LL addresses, =
they don't show up in the interface configuration, and because they're =
only locally significant, you have an awful time if you want to actually =
find the router or interface that is associated
 with the next-hop (say when chasing a next-hop rewrite problem), =
because you can't find it in the routing table, and you can't grep =
through a config repository for the address, and it likely won't be in =
DNS. The closest you might be able to get is to grep
 for the address and find the router with the other side of the iBGP =
session, but this won't work for eBGP because there is no relationship =
between the neighbor addresses like there is with GUA (+1 / -1).







Philip you may want to add something like this in 2.4.2 (or in =
2.1.2 since it's not just relevant to BGP.)







Other comments: 


You may want to add a reference to RFC 7439 in 2.4.1 last bullet =
about MPLS and IPv6


2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly =
referred to as TCP AO, so it'd be better to say "MD5 (RFC2385), which =
while still in wide use, has been obsoleted by TCP AO (RFC5925)"












 




Anything below this line has been added by my company=92s mail =
server, I have no control over it.
-----------














This E-mail and any of =
its attachments may contain Time Warner Cable proprietary information, =
which is privileged, confidential, or subject to copyright belonging to =
Time Warner Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If =
you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have =
received this E-mail in error, please notify the sender immediately and =
permanently delete the original and any copy of this E-mail and any =
printout.








 
 
  =


Yes and Yes.

More generally it is probably good advice that if you are usi=
ng a pair of addresses, use addresses of the same scope or type if possible=
, even though IPv6 can cope with different ones  (e.g., LLs on both en=
ds of an eBGP session, or ULAs or GUAs on both ends of a link rather than a=
 GUA on one end and a ULA on the other.).

I think this ties a bit back to something earlier I discussed=
 about conceptually assigning a prefix to a "link" even though in actuality=
 addresses from within a prefix are assigned to interfaces attached to the =
link, and not all interfaces need to have addresses from within the prefix.=
 The common implicit assumption in this "assigning prefixes to a link" ment=
al model is that all interfaces attached to the link will have addresses fr=
om within the prefix.

Rega=
rds,
Mark.

  
 
 
 
   From: Philip Matthews <philip_matthews@magma.ca>
 <=
span style=3D"font-weight: bold;">To: Wes George <wesley.geor=
ge@twcable.com>; Mark ZZZ Smith <markzzzsmith@yahoo.com.au> 
Cc: v6ops list <v6ops@iet=
f.org> 
 Sent: Wedne=
sday, 15 April 2015, 12:30
 Subjec=
t: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =

 


Wes and Mark (and anyone else)

<=
div id=3D"yui_3_16_0_1_1429063707432_19676">Would you agree with me that, i=
f one does use LLAs for eBGP endpoints, then:
* One should use LLAs at both ends,  AND
* One should explicitly configure=
 the LLAs at both ends
?<=
/div>

=

- Philip
<=
br clear=3D"none">
PS. We=
s: Will do on your "Other comments".  But it seems we are still debati=
ng your main point.




On 2015-04-13, at 9:43 , George, Wes wrote:
<=
br clear=3D"none" class=3D"yiv0838099447Apple-interchange-newline">








It's a little unclear who said=
 what given the way text was quoted, so I'm just replying to the snippet of=
 text I think is relevant inline below with WG], and then a few other LC co=
mments follow below it.







Tha=
nks,
  
Wes
  





















/ I val=
ue predictability and robustness. Having a eBGP session very specifically
 tied to an interface tightly couples the eBGP session and the traffic for =
the prefixes that eBGP session is announcing. The small amount of extra eff=
ort required to change a session to a different interface creates further o=
pportunity to catch errors. In some
 cases, the actual error might be minor, but the consequences of them can b=
e very significant outages.
















WG] That is true whether you u=
se a LL or a GUA if you use the interface IP address for eBGP peering inste=
ad of loopback multi hop. What's your point in favor of LLN here? Also, wha=
t errors are you talking about catching where
more manual reconfiguration i=
s the right answer?


















/ LLs don't have to be tied to specific hardware addresses, they can be sta=
tically set if this is a concern, and hopefully in the future, RFC7217 will=
 be implemented for them in routers, as this is one of the specific use cas=
es for them.
















WG] it's worse than that. If you don't statically set LL addresses, th=
ey don't show up in the interface configuration, and because they're only l=
ocally significant, you have an awful time if you want to actually find the=
 router or interface that is associated
 with the next-hop (say when chasing a next-hop rewrite problem), because y=
ou can't find it in the routing table, and you can't grep through a config =
repository for the address, and it likely won't be in DNS. The closest you =
might be able to get is to grep
 for the address and find the router with the other side of the iBGP sessio=
n, but this won't work for eBGP because there is no relationship between th=
e neighbor addresses like there is with GUA (+1 / -1).







Philip you may want to add something like this in 2.4.2 (or in 2.1.2 s=
ince it's not just relevant to BGP.)







Other comments: 


You may want to add a reference to RFC 7439 in 2.4.1 last bullet about=
 MPLS and IPv6


2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly referred =
to as TCP AO, so it'd be better to say "MD5 (RFC2385), which while still in=
 wide use, has been obsoleted by TCP AO (RFC5925)"












 




A=
nything below this line has been added by my company=E2=80=99s mail server,=
 I have no control over it.
-----------














This E-mail and any of its a=
ttachments may contain Time Warner Cable proprietary information, which is =
privileged, confidential, or subject to copyright belonging to Time Warner =
Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If you a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.








 
 
  
=

--Apple-Mail-5--211412122--


From nobody Tue Apr 14 20:49: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 C815B1B2B4B; Tue, 14 Apr 2015 20:49:25 -0700 (PDT)
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 nAoCbnyfIrNc; Tue, 14 Apr 2015 20:49:19 -0700 (PDT)
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 5C4FF1A90EE; Tue, 14 Apr 2015 20:49:19 -0700 (PDT)
Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:a91b:59a7:3bc0:aa1a]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3F3nFne098641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2015 03:49:16 GMT (envelope-from joelja@bogus.com)
To: "Fred Baker (fred)" , IPv6 Ops WG 
references: 
From: joel jaeggli 
x-enigmail-draft-status: N1110
message-id: <552DDFBA.6000104@bogus.com>
Date: Tue, 14 Apr 2015 20:49:14 -0700
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0
mime-version: 1.0
in-reply-to: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w2SXp8bSxc4DmjNn7V9i4Hi59hGXbwq3g"
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [v6ops] [sunset4] v6ops charter update discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 03:49:26 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--w2SXp8bSxc4DmjNn7V9i4Hi59hGXbwq3g
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 4/13/15 4:57 PM, Fred Baker (fred) wrote:
> Lee and I are reviewing the v6ops charter. I have attached a proposed
> charter and diffs against the current one. Joel has not commented on
> this yet, and while we have run it by the sunset4 chairs, we haven=92t
> gotten a reading from them. Sunset4 is relevant because possibly the
> ipv4-as-a-service discussion would be better handled there. In this
> email, I=92m soliciting opinions in general.

not to cast aspersions in any direction in particular, but if we seem
operators running such things and have cause to provide advice on them
then by all means I'm fine with that here.

that seems consistent with work on for example 464xlat

> The charter update started with Lee feeling that the fourth bullet of
> our current charter, which reads 4. Publish Informational or BCP RFCs
> that identify and analyze solutions for deploying IPv6 within common
> network environments, such as ISP Networks, Enterprise Networks,
> Unmanaged Networks (Home/Small Office), and Cellular Networks.=20
> (http://datatracker.ietf.org/wg/v6ops/charter/) is largely done. We
> know how to deploy IPv6.

I largely agree that some victory can be declared there.

> In addition, I think we need, collectively, to figure out how to get
> to IPv6-only. A large issue is =93so how do we connect to IPv4 content
> and services from an IPv6-only network=94, which is where
> ipv4-as-a-service comes in. I propose adding a bullet item regarding
> a road map to IPv6-only.

I think we're probably front-running the community of contributors by a
fair bit, but I think there are people and projects niddling around the
edges even as they employ some transition mechanism for backwards
compatibility.

> 4. Describe an operational roadmap to IPv6-only network deployment,=20
> with or without IPv4 delivered as an overlay or translation service.
>
> In my mind, that includes operational discussions of deployments and
> deployment issues in IPv4-as-a-service; one possible update would be
> to make that more explicit.
>=20
> In other respects, the update is mostly editorial.
>=20
> The other three tasks remain unchanged - collect operational
> experience, identify operational and security risks, and turn them
> over to other working groups - notably 6man.

yup

> Hoping for your input. Do you agree with these changes? If not, what
> changes, or further changes, would you recommend?
>=20
> As to proposed milestones, I=92d like to believe that
>=20
> these are done: draft-ietf-v6ops-6to4-to-historic=20
> draft-ietf-v6ops-cidr-prefix
>=20
> we can finalize and ship these by July:=20
> draft-ietf-v6ops-design-choices draft-ietf-v6ops-pmtud-ecmp-problem
>=20
> and these by November: draft-ietf-v6ops-siit-dc-* (would like a
> deployment report for siit-dc and siit-dc-2xlat in support) (would
> like one for 464xlat as well)
>=20
> On another point, Lee and I have been discussing the operational
> reports we had at IETF 92, and feel that was time well spent. Those
> had a common thread, which was the deployment of Softwire=92s MAP-E and=

> MAP-T technologies in their networks. We are thinking about asking
> companies deploying IPv6 in Europe, Asia, and South America to make
> reports in the coming three meetings, on their IPv6 deployments and
> the issues they face. Would that be of general interest? How would
> you propose to tune that concept?
>=20
>=20
>=20
> _______________________________________________ sunset4 mailing list=20
> sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4
>=20



--w2SXp8bSxc4DmjNn7V9i4Hi59hGXbwq3g
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

iEYEARECAAYFAlUt37oACgkQ8AA1q7Z/VrInhQCfboo/mXoShw6+jzperiy+VRB3
EwYAn3M5uqDcPxwSGtcGhClRGGLHPcup
=a+nc
-----END PGP SIGNATURE-----

--w2SXp8bSxc4DmjNn7V9i4Hi59hGXbwq3g--


From nobody Tue Apr 14 23:15: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 5FBFC1B318B for ; Tue, 14 Apr 2015 23:15:21 -0700 (PDT)
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, 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 D5N3yXh06teh for ; Tue, 14 Apr 2015 23:15:16 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA8C1B3186 for ; Tue, 14 Apr 2015 23:15:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A4BD64033C; Wed, 15 Apr 2015 08:15:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jZJELiOdQhz; Wed, 15 Apr 2015 08:15:12 +0200 (CEST)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id ECE2A4033A; Wed, 15 Apr 2015 08:15:11 +0200 (CEST)
Message-ID: <552E01EE.5060608@globis.net>
Date: Wed, 15 Apr 2015 08:15:10 +0200
From: Ray Hunter 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Philip Matthews 
References:  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060300010301060900090408"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 06:15:21 -0000

This is a multi-part message in MIME format.
--------------060300010301060900090408
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



Philip Matthews wrote:
>
> Wes and Mark (and anyone else)
>
> Would you agree with me that, if one does use LLAs for eBGP endpoints, 
> then:
> * One should use LLAs at both ends,  AND
> * One should explicitly configure the LLAs at both ends
> ?
>
> - Philip
>
> PS. Wes: Will do on your "Other comments".  But it seems we are still 
> debating your main point.
>
>
If you're going to disucss BGP security in section 2.4.2, you might want 
to add a link to http://www.rfc-editor.org/rfc/rfc7454.txt rather than 
5082 and 5925.


> On 2015-04-13, at 9:43 , George, Wes wrote:
>
>> It's a little unclear who said what given the way text was quoted, so 
>> I'm just replying to the snippet of text I think is relevant inline 
>> below with WG], and then a few other LC comments follow below it.
>>
>> Thanks,
>> Wes
>>
>> / I value predictability and robustness. Having a eBGP session very 
>> specifically tied to an interface tightly couples the eBGP session 
>> and the traffic for the prefixes that eBGP session is announcing. The 
>> small amount of extra effort required to change a session to a 
>> different interface creates further opportunity to catch errors. In 
>> some cases, the actual error might be minor, but the consequences of 
>> them can be very significant outages.
>>
>> WG] That is true whether you use a LL or a GUA if you use the 
>> interface IP address for eBGP peering instead of loopback multi hop. 
>> What's your point in favor of LLN here? Also, what errors are you 
>> talking about catching where more manual reconfiguration is the right 
>> answer?
>>
>> / LLs don't have to be tied to specific hardware addresses, they can 
>> be statically set if this is a concern, and hopefully in the future, 
>> RFC7217 will be implemented for them in routers, as this is one of 
>> the specific use cases for them.
>>
>> WG] it's worse than that. If you don't statically set LL addresses, 
>> they don't show up in the interface configuration, and because 
>> they're only locally significant, you have an awful time if you want 
>> to actually find the router or interface that is associated with the 
>> next-hop (say when chasing a next-hop rewrite problem), because you 
>> can't find it in the routing table, and you can't grep through a 
>> config repository for the address, and it likely won't be in DNS. The 
>> closest you might be able to get is to grep for the address and find 
>> the router with the other side of the iBGP session, but this won't 
>> work for eBGP because there is no relationship between the neighbor 
>> addresses like there is with GUA (+1 / -1).
>>
>> Philip you may want to add something like this in 2.4.2 (or in 2.1.2 
>> since it's not just relevant to BGP.)
>>
>> Other comments:
>> You may want to add a reference to RFC 7439 in 2.4.1 last bullet 
>> about MPLS and IPv6
>> 2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly referred 
>> to as TCP AO, so it'd be better to say "MD5 (RFC2385), which while 
>> still in wide use, has been obsoleted by TCP AO (RFC5925)"
>>
>>
>> Anything below this line has been added by my company’s mail server, 
>> I have no control over it.
>> -----------
>>
>>
>> ------------------------------------------------------------------------
>> This E-mail and any of its attachments may contain Time Warner Cable 
>> proprietary information, which is privileged, confidential, or 
>> subject to copyright belonging to Time Warner Cable. This E-mail is 
>> intended solely for the use of the individual or entity to which it 
>> is addressed. If you are not the intended recipient of this E-mail, 
>> you are hereby notified that any dissemination, distribution, 
>> copying, or action taken in relation to the contents of and 
>> attachments to this E-mail is strictly prohibited and may be 
>> unlawful. If you have received this E-mail in error, please notify 
>> the sender immediately and permanently delete the original and any 
>> copy of this E-mail and any printout.
>

--------------060300010301060900090408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit







Philip Matthews wrote:


  


  
Wes and Mark (and anyone else)

  


  
Would you agree with me that, if one does use LLAs for eBGP 
endpoints, then:

  
* One should use LLAs at both ends,  AND

  
* One should explicitly configure the LLAs at both ends

  
?

  


  
- Philip

PS. Wes: Will do on your 
"Other comments".  But it seems we are still debating your main point.





If you're going to disucss BGP security in section 2.4.2, you might want
 to add a link to http://www.rfc-editor.org/rfc/rfc7454.txt rather than 
5082 and 5925.







  

    
On 2015-04-13, at 9:43 , George, Wes wrote:










It's a little unclear who said what given the way text was quoted, 
so I'm just replying to the snippet of text I think is relevant inline 
below with WG], and then a few other LC comments follow below it.







Thanks,
 
Wes
 





















/ I value 
predictability and robustness. Having a eBGP session very specifically
 tied to an interface tightly couples the eBGP session and the traffic 
for the prefixes that eBGP session is announcing. The small amount of 
extra effort required to change a session to a different interface 
creates further opportunity to catch errors. In some
 cases, the actual error might be minor, but the consequences of them 
can be very significant outages.
















WG] That is true whether you use a LL or a GUA if you use the 
interface IP address for eBGP peering instead of loopback multi hop. 
What's your point in favor of LLN here? Also, what errors are you 
talking about catching where
more manual reconfiguration is 
the right answer?


















/ LLs don't have to be tied to specific hardware addresses, they can be 
statically set if this is a concern, and hopefully in the future, 
RFC7217 will be implemented for them in routers, as this is one of the 
specific use cases for them.
















WG] it's worse than that. If you don't statically set LL addresses,
 they don't show up in the interface configuration, and because they're 
only locally significant, you have an awful time if you want to actually
 find the router or interface that is associated
 with the next-hop (say when chasing a next-hop rewrite problem), 
because you can't find it in the routing table, and you can't grep 
through a config repository for the address, and it likely won't be in 
DNS. The closest you might be able to get is to grep
 for the address and find the router with the other side of the iBGP 
session, but this won't work for eBGP because there is no relationship 
between the neighbor addresses like there is with GUA (+1 / -1).







Philip you may want to add something like this in 2.4.2 (or in 
2.1.2 since it's not just relevant to BGP.)







Other comments: 


You may want to add a reference to RFC 7439 in 2.4.1 last bullet 
about MPLS and IPv6


2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly 
referred to as TCP AO, so it'd be better to say "MD5 (RFC2385), which 
while still in wide use, has been obsoleted by TCP AO (RFC5925)"












 




Anything below this line has been added by my 
company’s mail server, I have no control over it.
-----------














This E-mail and any of its 
attachments may contain Time Warner Cable proprietary information, which
 is privileged, confidential, or subject to copyright belonging to Time 
Warner Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If 
you are not the intended recipient of this E-mail, you are hereby 
notified that any dissemination, distribution, copying, or action taken 
in relation to the contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have 
received this E-mail in error, please notify the sender immediately and 
permanently delete the original and any copy of this E-mail and any 
printout.





  





--------------060300010301060900090408--


From nobody Wed Apr 15 00:38:41 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 094D41B3261 for ; Wed, 15 Apr 2015 00:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.001
X-Spam-Level: ***
X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, 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 Gu4du2VXvgbv for ; Wed, 15 Apr 2015 00:38:38 -0700 (PDT)
Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6FC1B3245 for ; Wed, 15 Apr 2015 00:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429083514; bh=UwfR3tA2Vcj0+qoMQKZA3TllBPuf62ZxZSJiErZ44Uc=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=VQP3vcZnmT0BhP9Wr4qVQOobY+zfYs3FkcGeHGG/5qUrwFdxb+gEw50rQxJ4I+YL5+WQXlJiwajaTa294baxu9SadaH+WzBg+zBQM5NOsXUISOPnWGQKZs6yv+vCC2roFNJhN4rAEPXoEUwdKlmtXE+2OLrz6CuMz6Z4QiH55Vq8tbMuxDPEuQdnwnl9UR7yZuVYhvsVXKVASoSqLK4taI/e+3Nu1AtbcmzZuXijN98weWwrAr/5+J8TvcCbUt/nH2WhrxBhvmBdjm00UFLyaOW8Ezn8lTY8KcykJ/6+GzoVYY+f4iSE1TyifWPgPnKWPU5xSUTDrmEHgLiLUBJP2Q==
Received: from [98.139.215.142] by nm20.bullet.mail.bf1.yahoo.com with NNFMP;  15 Apr 2015 07:38:34 -0000
Received: from [98.139.212.217] by tm13.bullet.mail.bf1.yahoo.com with NNFMP;  15 Apr 2015 07:38:34 -0000
Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 15 Apr 2015 07:38:34 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 26373.46675.bm@omp1026.mail.bf1.yahoo.com
X-YMail-OSG: dcN5y44VM1l_NtM33OzkyggUJxgY3e5xd9PWptN064DjTlv1UClDJzh7XmezRu2 WqKzlW1z2y0nPFpgGjNiNUdK3gthHz.NaCqev437rZPTJAmSt9rxmR9jYbeC1hyCuItDQd04UKqy cklO80eun2Y4bkpd0nNI9zS5G7SUj6Nk43Vh_1gY_HftwlUKkIby1ty3LLxzubUNAEI2AP3ioAwr ig0Th6vgfiJm776X9YqPEzWifChpNzVuRouCmFlY40ybY4EWATHAru8mw3V2H5B7_Iyo0QHz8T8Q lVh.7xAxTU_7peGPdhkK2A2MD3_vU1eq_9Akt3aUMUBqsaXIXALZo_FgaxmRMiJv.eprbGXkwild 2DhrIJCtWiTFjXmKWNizeTVncz87YVrn2fmbkKE4s4lo_hCDn3vmm25NTtqp_PEU2NCfwjW0I2yk gUwr1TVMzab82Y5VcAuKlmSmN.3BOTlQN3dBlRyW.Md4Iauzh0aOGYZhQGrYHw49cb5gEBnlmOq. sQy.fBsbyOeMDaj46
Received: by 66.196.81.105; Wed, 15 Apr 2015 07:38:33 +0000 
Date: Wed, 15 Apr 2015 07:38:31 +0000 (UTC)
From: Mark ZZZ Smith 
To: Philip Matthews 
Message-ID: <1998345634.4053156.1429083511676.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <9CC456D9-764A-4123-81D3-D297293658DC@magma.ca>
References: <9CC456D9-764A-4123-81D3-D297293658DC@magma.ca>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_4053155_1507760744.1429083511665"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 07:38:41 -0000

------=_Part_4053155_1507760744.1429083511665
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That sounds like you're interpreting my suggestion to be BGP specific. I wa=
s thinking it is just generally good advice. For example, if you used an LL=
 and a GUA address for something, or a ULA and a GUA, and then later wanted=
 to replace the GUA, you have more work to do. OTOH, if you'd used two LLs =
for example or two ULAs or two GUAs, you're reducing cross prefix type/scop=
e dependencies.
There are BGP specific considerations that of course should be covered too =
(as they have been.)
Regards,Mark.
      From: Philip Matthews 
 To: Mark ZZZ Smith =20
Cc: Wes George ; v6ops list =20
 Sent: Wednesday, 15 April 2015, 13:09
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =20
Then perhaps one way to handle this in the draft is to rewrite the section =
to say "If you use LLAs as endpoint addresses, then here is best practice f=
or how to do it; if you use GUAs as endpoint addresses, then here is best p=
ractice for how to do it; and here are the pros and cons of the two approac=
hes".
Just trying to figure out a way forward to something everyone agrees is use=
ful ...
- Philip


On 2015-04-14, at 22:48 , Mark ZZZ Smith wrote:

Yes and Yes.
More generally it is probably good advice that if you are using a pair of a=
ddresses, use addresses of the same scope or type if possible, even though =
IPv6 can cope with different ones =C2=A0(e.g., LLs on both ends of an eBGP =
session, or ULAs or GUAs on both ends of a link rather than a GUA on one en=
d and a ULA on the other.).
I think this ties a bit back to something earlier I discussed about concept=
ually assigning a prefix to a "link" even though in actuality addresses fro=
m within a prefix are assigned to interfaces attached to the link, and not =
all interfaces need to have addresses from within the prefix. The common im=
plicit assumption in this "assigning prefixes to a link" mental model is th=
at all interfaces attached to the link will have addresses from within the =
prefix.
Regards,Mark.
      From: Philip Matthews 
 To: Wes George ; Mark ZZZ Smith =20
Cc: v6ops list =20
 Sent: Wednesday, 15 April 2015, 12:30
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =20

Wes and Mark (and anyone else)
Would you agree with me that, if one does use LLAs for eBGP endpoints, then=
:* One should use LLAs at both ends, =C2=A0AND* One should explicitly confi=
gure the LLAs at both ends?
- Philip
PS. Wes: Will do on your "Other comments". =C2=A0But it seems we are still =
debating your main point.



On 2015-04-13, at 9:43 , George, Wes wrote:


It's a little unclear who said what given the way text was quoted, so I'm j=
ust replying to the snippet of text I think is relevant inline below with W=
G], and then a few other LC comments follow below it.
Thanks, =C2=A0Wes =C2=A0
/ I value predictability and robustness. Having a eBGP session very specifi=
cally tied to an interface tightly couples the eBGP session and the traffic=
 for the prefixes that eBGP session is announcing. The small amount of extr=
a effort required to change a session to a different interface creates furt=
her opportunity to catch errors. In some cases, the actual error might be m=
inor, but the consequences of them can be very significant outages.
WG] That is true whether you use a LL or a GUA if you use the interface IP =
address for eBGP peering instead of loopback multi hop. What's your point i=
n favor of LLN here? Also, what errors are you talking about catching where=
more=C2=A0manual reconfiguration is the right answer?
/ LLs don't have to be tied to specific hardware addresses, they can be sta=
tically set if this is a concern, and hopefully in the future, RFC7217 will=
 be implemented for them in routers, as this is one of the specific use cas=
es for them.
WG] it's worse than that. If you don't statically set LL addresses, they do=
n't show up in the interface configuration, and because they're only locall=
y significant, you have an awful time if you want to actually find the rout=
er or interface that is associated with the next-hop (say when chasing a ne=
xt-hop rewrite problem), because you can't find it in the routing table, an=
d you can't grep through a config repository for the address, and it likely=
 won't be in DNS. The closest you might be able to get is to grep for the a=
ddress and find the router with the other side of the iBGP session, but thi=
s won't work for eBGP because there is no relationship between the neighbor=
 addresses like there is with GUA (+1 / -1).
Philip you may want to add something like this in 2.4.2 (or in 2.1.2 since =
it's not just relevant to BGP.)
Other comments:=C2=A0You may want to add a reference to RFC 7439 in 2.4.1 l=
ast bullet about MPLS and IPv62.4.2: 5925 is not MD5. It obsoleted MD5, but=
 it is properly referred to as TCP AO, so it'd be better to say "MD5 (RFC23=
85), which while still in wide use, has been obsoleted by TCP AO (RFC5925)"

=C2=A0Anything below this line has been added by my company=E2=80=99s mail =
server, I have no control over it.-----------

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.



  =20



  
------=_Part_4053155_1507760744.1429083511665
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


That s=
ounds like you're interpreting my suggestion to be BGP specific. I was thin=
king it is just generally good advice. For example, if you used an LL and a=
 GUA address for something, or a ULA and a GUA, and then later wanted to re=
place the GUA, you have more work to do. OTOH, if you'd used two LLs for ex=
ample or two ULAs or two GUAs, you're reducing cross prefix type/scope depe=
ndencies.

There =
are BGP specific considerations that of course should be covered too (as th=
ey have been.)

Regards,
Mark.

  
 
 
 
   From: Philip Matthews <=
;philip_matthews@magma.ca>
 To:=
 Mark ZZZ Smith <markzzzsmith@yahoo.com.au> 
Cc: Wes George <wesley.george@twc=
able.com>; v6ops list <v6ops@ietf.org> 
 Sent: Wednesday, 15 April 2015, 13:09
 Subject: Re: [v6ops] draft-ietf-=
v6ops-design-choices WGLC
  
 

Then perhaps one way to handle this =
in the draft is to rewrite the section to say "If you use LLAs as endpoint =
addresses, then here is best practice for how to do it; if you use GUAs as =
endpoint addresses, then here is best practice for how to do it; and here a=
re the pros and cons of the two approaches".

Just trying to figure out a way forward to something everyone agrees=
 is useful ...

- Philip
<=
div class=3D"qtdSeparateBR">


On 2015-04-14, at 22:48 , Mark ZZZ S=
mith wrote:

Yes=
 and Yes.

More generally it is probably good advic=
e that if you are using a pair of addresses, use addresses of the same scop=
e or type if possible, even though IPv6 can cope with different ones  =
(e.g., LLs on both ends of an eBGP session, or ULAs or GUAs on both ends of=
 a link rather than a GUA on one end and a ULA on the other.).
=


I think this ties a bit back to something earlier I discussed a=
bout conceptually assigning a prefix to a "link" even though in actuality a=
ddresses from within a prefix are assigned to interfaces attached to the li=
nk, and not all interfaces need to have addresses from within the prefix. T=
he common implicit assumption in this "assigning prefixes to a link" mental=
 model is that all interfaces attached to the link will have addresses from=
 within the prefix.

Regards,
Mark.

  
 
 
 
 =
  From: Philip Ma=
tthews <p=
hilip_matthews@magma.ca>
 To: Wes George <wesley.george@twcable.com>; Mark ZZ=
Z Smith <markzzzsmith@yahoo.com.au> 
Cc: v6ops list <v6ops@ietf.org> 
 Sent: Wednesday, 15 April 2015, 12:30
 Subject: Re: [=
v6ops] draft-ietf-v6ops-design-choices WGLC
   


Wes and Mark (and anyone else)<=
/div>

Woul=
d you agree with me that, if one does use LLAs for eBGP endpoints, then:
* One should u=
se LLAs at both ends,  AND
* One should explicitly configure the LLAs at both ends=

?

- Philip

PS. Wes: Will do on your=
 "Other comments".  But it seems we are still debating your main point=
.




On 2015-04-13, at 9:43 , George, Wes wrote:










It's a little unc=
lear who said what given the way text was quoted, so I'm just replying to t=
he snippet of text I think is relevant inline below with WG], and then a fe=
w other LC comments follow below it.







Thanks,
  
Wes
  





















/ I val=
ue predictability and robustness. Having a eBGP session very specifically
 tied to an interface tightly couples the eBGP session and the traffic for =
the prefixes that eBGP session is announcing. The small amount of extra eff=
ort required to change a session to a different interface creates further o=
pportunity to catch errors. In some
 cases, the actual error might be minor, but the consequences of them can b=
e very significant outages.
















WG] That is true =
whether you use a LL or a GUA if you use the interface IP address for eBGP =
peering instead of loopback multi hop. What's your point in favor of LLN he=
re? Also, what errors are you talking about catching where
more manual reconfiguration i=
s the right answer?


















/ LLs don't have to be tied to specific hardware addresses, they can be sta=
tically set if this is a concern, and hopefully in the future, RFC7217 will=
 be implemented for them in routers, as this is one of the specific use cas=
es for them.
















WG] it's worse than that. If you don't statically set LL addresses, th=
ey don't show up in the interface configuration, and because they're only l=
ocally significant, you have an awful time if you want to actually find the=
 router or interface that is associated
 with the next-hop (say when chasing a next-hop rewrite problem), because y=
ou can't find it in the routing table, and you can't grep through a config =
repository for the address, and it likely won't be in DNS. The closest you =
might be able to get is to grep
 for the address and find the router with the other side of the iBGP sessio=
n, but this won't work for eBGP because there is no relationship between th=
e neighbor addresses like there is with GUA (+1 / -1).







Philip you may want to add something like this in 2.4.2 (or in 2.1.2 s=
ince it's not just relevant to BGP.)







Other comments: 


You may want to add a reference to RFC 7439 in 2.4.1 last bullet about=
 MPLS and IPv6


2.4.2: 5925 is not MD5. It obsoleted MD5, but it is properly referred =
to as TCP AO, so it'd be better to say "MD5 (RFC2385), which while still in=
 wide use, has been obsoleted by TCP AO (RFC5925)"












 




A=
nything below this line has been added by my company=E2=80=99s mail server,=
 I have no control over it.
-----------














This E-mail and any of its a=
ttachments may contain Time Warner Cable proprietary information, which is =
privileged, confidential, or subject to copyright belonging to Time Warner =
Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If you a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.








=

 
 
  



 
 
  

------=_Part_4053155_1507760744.1429083511665--


From nobody Wed Apr 15 05:47: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 3372B1B33FE for ; Wed, 15 Apr 2015 05:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.125
X-Spam-Level: **
X-Spam-Status: No, score=2.125 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 1t4lwjeu_6Ga for ; Wed, 15 Apr 2015 05:47:31 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 17CEE1AD0D3 for ; Wed, 15 Apr 2015 05:47:30 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,581,1422939600";  d="scan'208,217";a="674687261"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 15 Apr 2015 08:31:57 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 15 Apr 2015 08:47:29 -0400
From: "George, Wes" 
To: Philip Matthews 
Date: Wed, 15 Apr 2015 08:47:28 -0400
Thread-Topic: [v6ops] draft-ietf-v6ops-design-choices WGLC
Thread-Index: AdB3elUNiM9HsfVnQwOp1puLRdQ/ag==
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D153D1B24D9F6wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 12:47:33 -0000

--_000_D153D1B24D9F6wesleygeorgetwcablecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpGcm9tOiBQaGlsaXAgTWF0dGhld3MgPHBoaWxpcF9tYXR0aGV3c0BtYWdtYS5jYTxtYWlsdG86
cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPj4NCkRhdGU6IFR1ZXNkYXksIEFwcmlsIDE0LCAyMDE1
IGF0IDEwOjMwIFBNDQpUbzogIkdlb3JnZSwgV2VzIiA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNv
bTxtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT4+LCBNYXJrIFpaWiBTbWl0aCA8bWFy
a3p6enNtaXRoQHlhaG9vLmNvbS5hdTxtYWlsdG86bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4+
DQpDYzogdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4N
ClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMgV0dM
Qw0KDQoNCldlcyBhbmQgTWFyayAoYW5kIGFueW9uZSBlbHNlKQ0KDQpXb3VsZCB5b3UgYWdyZWUg
d2l0aCBtZSB0aGF0LCBpZiBvbmUgZG9lcyB1c2UgTExBcyBmb3IgZUJHUCBlbmRwb2ludHMsIHRo
ZW46DQoqIE9uZSBzaG91bGQgdXNlIExMQXMgYXQgYm90aCBlbmRzLCAgQU5EDQoNCldHXSB5ZWFo
LCBpbiB0aGVvcnksIGJ1dCB0aGlzIGFzc3VtZXMgdGhhdCB0aGUgb3RoZXIgQVNOIGluIGFuIGVC
R1AgcGVlcmluZyBpcyBhbWVuYWJsZSwgd2hpY2ggaW4gbWFueSBjYXNlcyB0aGV5IHdpbGwgbm90
IGJlIChJLmUuIEkgd291bGQgdGVsbCB5b3UgdG8gZ28gcG91bmQgc2FuZCBhbmQgaGFuZCB5b3Ug
bXkgb3duIEdVQSB0byB1c2UgaWYgeW91IHRyaWVkIHRvIGdpdmUgbWUgYSBMTEEgdG8gcGVlciB3
aXRoIHlvdSBvbiBpbiBlQkdQKSwgc28gdGhhdCByZWNvbW1lbmRhdGlvbiBtYXkgb25seSBiZSB1
c2VmdWwgZm9yIGlCR1AuIEkgZ2F2ZSBzaW1pbGFyIGNvbW1lbnRzIHRvIHRoZSBhdXRob3JzIG9m
IDc0MDQgdGhhdCB0aGV5IHdlcmUgZHJhbWF0aWNhbGx5IG92ZXJzZWxsaW5nIHRoZSBwb3B1bGFy
aXR5IG9mIHVzZSBvZiBMTEEsIGp1c3QgYXMgSSB0aGluayBNYXJrIGlzIGhlcmUsIGFuZCBJIGNh
dXRpb24geW91IHRoYXQgeW91J3JlIGRhbmNpbmcgYXJvdW5kIGEgcG90ZW50aWFsIHRoaXJkIHJh
aWwuIFRoZXJlJ3MgYSByZWFzb24gd2h5IDc0MDQgY291bGQgbm90IGFjaGlldmUgY29uc2Vuc3Vz
IHdpdGhvdXQgdGhlIGNhdmVhdCBhZGRlZCB0byB0aGUgZW5kIG9mIHRoZSBpbnRybzoNCg0KICAg
IkR1cmluZyBXRyBhbmQgSUVURiBsYXN0IGNhbGwsIHRoZSB0ZWNobmljYWwgY29ycmVjdG5lc3Mg
b2YgdGhlDQogICBkb2N1bWVudCB3YXMgcmV2aWV3ZWQ7IGhvd2V2ZXIsIGRlYmF0ZSBleGlzdHMg
YXMgdG8gd2hldGhlciB0bw0KICAgcmVjb21tZW5kIHRoaXMgdGVjaG5pcXVlLiAgVGhlIGRlcGxv
eW1lbnQgb2YgdGhpcyB0ZWNobmlxdWUgaXMNCiAgIGFwcHJvcHJpYXRlIHdoZXJlIGl0IGlzIGZv
dW5kIHRvIGJlIG5lY2Vzc2FyeS4iDQoNCg0KSW4gb3RoZXIgd29yZHMsIHRoZXJlIHdhcyBjb25j
ZXJuIHRoYXQgZGlzY3Vzc2luZyB1c2Ugb2YgTExBcyBpbiB0aGlzIG1hbm5lciBpbiBhbiBJRVRG
IGNvbnNlbnN1cyBkb2N1bWVudCwgZXZlbiBvbmUgd3JpdHRlbiBhcyBuZXV0cmFsbHkgYXMgcG9z
c2libGUgd291bGQgYmUgaW50ZXJwcmV0ZWQgYnkgdGhvc2Ugb3V0c2lkZSBvZiB0aGUgSUVURiBh
cyAidGhlIElFVEYgc2F5cyB0byBkbyB0aGlzIi4gSSB0aGluayB0aGUgc2FtZSBjb25jZXJuIGFw
cGxpZXMgaGVyZS4NCg0KKiBPbmUgc2hvdWxkIGV4cGxpY2l0bHkgY29uZmlndXJlIHRoZSBMTEFz
IGF0IGJvdGggZW5kcw0KV0ddIHllcy4gSSB0aGluayBteSBtYWluIHBvaW50IHN1cHBvcnRzIHRo
YXQgcmVjb21tZW5kYXRpb24gc28gdGhhdCBpdCBhdCBsZWFzdCBzaG93cyB1cCBpbiB0aGUgY29u
ZmlndXJhdGlvbi4NCg0KUFMuIFdlczogV2lsbCBkbyBvbiB5b3VyICJPdGhlciBjb21tZW50cyIu
ICBCdXQgaXQgc2VlbXMgd2UgYXJlIHN0aWxsIGRlYmF0aW5nIHlvdXIgbWFpbiBwb2ludC4NCg0K
V0ddIGlmIHlvdSBkbyBnbyB3aXRoIHlvdXIgc3VnZ2VzdGVkIG1vZGVsIG9mIGRpc2N1c3Npbmcg
Y29uc2lkZXJhdGlvbnMgYXJvdW5kIExMQXMsIHRoZW4gY29uc2lkZXJhdGlvbnMgb2YgR1VBcywg
dGhlbiBwcm9zIGFuZCBjb25zLCBJIHRoaW5rIGl0IGZpdHMgd2VsbC4NCg0KVGhhbmtzLA0KV2Vz
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQgYW55
IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmll
dGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBz
dWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMg
RS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv
ciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0
aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0
YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRo
aXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl
IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBh
bmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg==

--_000_D153D1B24D9F6wesleygeorgetwcablecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf
U0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFw
dDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v
bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElO
Ry1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg
c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNw
YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5QaGlsaXAgTWF0dGhld3Mg
Jmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2EiPnBoaWxpcF9tYXR0
aGV3c0BtYWdtYS5jYTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi
PkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCAxNCwgMjAxNSBhdCAxMDozMCBQTTxicj4NCjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90O0dlb3JnZSwgV2Vz
JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbSI+d2Vz
bGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTwvYT4mZ3Q7LCBNYXJrIFpaWiBTbWl0aCAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXUiPm1hcmt6enpzbWl0aEB5YWhvby5j
b20uYXU8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9z
cGFuPnY2b3BzIGxpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNA
aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq
ZWN0OiA8L3NwYW4+UmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1kZXNpZ24tY2hvaWNlcyBX
R0xDPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Indv
cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp
bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
V2VzIGFuZCBNYXJrIChhbmQgYW55b25lIGVsc2UpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PGRpdj5Xb3VsZCB5b3UgYWdyZWUgd2l0aCBtZSB0aGF0LCBpZiBvbmUgZG9lcyB1c2UgTExBcyBm
b3IgZUJHUCBlbmRwb2ludHMsIHRoZW46PC9kaXY+DQo8ZGl2PiogT25lIHNob3VsZCB1c2UgTExB
cyBhdCBib3RoIGVuZHMsICZuYnNwO0FORDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldHXSB5ZWFoLCBpbiB0aGVvcnksIGJ1dCB0aGlzIGFz
c3VtZXMgdGhhdCB0aGUgb3RoZXIgQVNOIGluIGFuIGVCR1AgcGVlcmluZyBpcyBhbWVuYWJsZSwg
d2hpY2ggaW4gbWFueSBjYXNlcyB0aGV5IHdpbGwgbm90IGJlIChJLmUuIEkgd291bGQgdGVsbCB5
b3UgdG8gZ28gcG91bmQgc2FuZCBhbmQgaGFuZCB5b3UgbXkgb3duIEdVQSB0byB1c2UgaWYgeW91
IHRyaWVkIHRvIGdpdmUgbWUgYSBMTEEgdG8gcGVlciB3aXRoIHlvdSBvbiBpbiBlQkdQKSwNCiBz
byB0aGF0IHJlY29tbWVuZGF0aW9uIG1heSBvbmx5IGJlIHVzZWZ1bCBmb3IgaUJHUC4gSSBnYXZl
IHNpbWlsYXIgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMgb2YgNzQwNCB0aGF0IHRoZXkgd2VyZSBk
cmFtYXRpY2FsbHkgb3ZlcnNlbGxpbmcgdGhlIHBvcHVsYXJpdHkgb2YgdXNlIG9mIExMQSwganVz
dCBhcyBJIHRoaW5rIE1hcmsgaXMgaGVyZSwgYW5kIEkgY2F1dGlvbiB5b3UgdGhhdCB5b3UncmUg
ZGFuY2luZyBhcm91bmQgYSBwb3RlbnRpYWwNCiB0aGlyZCByYWlsLiBUaGVyZSdzIGEgcmVhc29u
IHdoeSA3NDA0IGNvdWxkIG5vdCBhY2hpZXZlIGNvbnNlbnN1cyB3aXRob3V0IHRoZSBjYXZlYXQg
YWRkZWQgdG8gdGhlIGVuZCBvZiB0aGUgaW50cm86Jm5ic3A7PC9kaXY+DQo8ZGl2Pg0KPHByZSBj
bGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1h
cmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+
ICAgJnF1b3Q7RHVyaW5nIFdHIGFuZCBJRVRGIGxhc3QgY2FsbCwgdGhlIHRlY2huaWNhbCBjb3Jy
ZWN0bmVzcyBvZiB0aGUNCiAgIGRvY3VtZW50IHdhcyByZXZpZXdlZDsgaG93ZXZlciwgZGViYXRl
IGV4aXN0cyBhcyB0byB3aGV0aGVyIHRvDQogICByZWNvbW1lbmQgdGhpcyB0ZWNobmlxdWUuICBU
aGUgZGVwbG95bWVudCBvZiB0aGlzIHRlY2huaXF1ZSBpcw0KICAgYXBwcm9wcmlhdGUgd2hlcmUg
aXQgaXMgZm91bmQgdG8gYmUgbmVjZXNzYXJ5LiZxdW90OzwvcHJlPg0KPHByZSBjbGFzcz0ibmV3
cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0
b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+PGJyPjwvcHJl
Pg0KPC9kaXY+DQo8ZGl2PkluIG90aGVyIHdvcmRzLCB0aGVyZSB3YXMgY29uY2VybiB0aGF0IGRp
c2N1c3NpbmcgdXNlIG9mIExMQXMgaW4gdGhpcyBtYW5uZXIgaW4gYW4gSUVURiBjb25zZW5zdXMg
ZG9jdW1lbnQsIGV2ZW4gb25lIHdyaXR0ZW4gYXMgbmV1dHJhbGx5IGFzIHBvc3NpYmxlIHdvdWxk
IGJlIGludGVycHJldGVkIGJ5IHRob3NlIG91dHNpZGUgb2YgdGhlIElFVEYgYXMgJnF1b3Q7dGhl
IElFVEYgc2F5cyB0byBkbyB0aGlzJnF1b3Q7LiBJIHRoaW5rIHRoZSBzYW1lIGNvbmNlcm4NCiBh
cHBsaWVzIGhlcmUuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9M
S19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr
LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl
ci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+KiBPbmUgc2hvdWxkIGV4cGxpY2l0bHkgY29uZmlndXJl
IHRoZSBMTEFzIGF0IGJvdGggZW5kczwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxk
aXY+V0ddIHllcy4gSSB0aGluayBteSBtYWluIHBvaW50IHN1cHBvcnRzIHRoYXQgcmVjb21tZW5k
YXRpb24gc28gdGhhdCBpdCBhdCBsZWFzdCBzaG93cyB1cCBpbiB0aGUgY29uZmlndXJhdGlvbi48
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw
LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0K
PGRpdj4NCjxkaXY+UFMuIFdlczogV2lsbCBkbyBvbiB5b3VyICZxdW90O090aGVyIGNvbW1lbnRz
JnF1b3Q7LiAmbmJzcDtCdXQgaXQgc2VlbXMgd2UgYXJlIHN0aWxsIGRlYmF0aW5nIHlvdXIgbWFp
biBwb2ludC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldHXSBpZiB5b3UgZG8gZ28g
d2l0aCB5b3VyIHN1Z2dlc3RlZCBtb2RlbCBvZiBkaXNjdXNzaW5nIGNvbnNpZGVyYXRpb25zIGFy
b3VuZCBMTEFzLCB0aGVuIGNvbnNpZGVyYXRpb25zIG9mIEdVQXMsIHRoZW4gcHJvcyBhbmQgY29u
cywgSSB0aGluayBpdCBmaXRzIHdlbGwuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2Pldlczwv
ZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIx
Ij5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1l
IFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdl
ZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGlt
ZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0aGUg
dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQu
IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlv
dSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlv
biwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBv
ZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk
IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGlu
IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVu
dGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBh
bnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_D153D1B24D9F6wesleygeorgetwcablecom_--


From nobody Wed Apr 15 06:37: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 46AA01B34D2 for ; Wed, 15 Apr 2015 06:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level: 
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 PLwSO7QD-CA2 for ; Wed, 15 Apr 2015 06:37:11 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDFAB1B34CC for ; Wed, 15 Apr 2015 06:37:10 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id DFDAFA2; Wed, 15 Apr 2015 15:37:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1429105028; bh=6Djs4wiWFZ8t/nKGP+DFJhZdn8k0BFCp5J4HInMJ7rA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bTAvFBD9UnPzYvrCBN0JM7G6PZ25zvT7hlDAq+nAfH8sbhNaTnjmMsVwBEsKV6r5p ye5VFHw9aBL65NSZVoHVYfMHfmG98RfMhomrsz6iO5eZbIcSqcuezEToyu9HAntCmI FODzZiOj9OcBFZFfZIRoxTy7yDfPjXtYAo1ku0Wg=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DA4F0A1; Wed, 15 Apr 2015 15:37:08 +0200 (CEST)
Date: Wed, 15 Apr 2015 15:37:08 +0200 (CEST)
From: Mikael Abrahamsson 
To: JF Tremblay 
In-Reply-To: 
Message-ID: 
References: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com>  
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-2132257136-1429105028=:16871"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 13:37:14 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-2132257136-1429105028=:16871
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 14 Apr 2015, JF Tremblay wrote:

>> I also question how common it is to use ULAs, with current wording it 
>> seems to indicate that both are quite common, which I don't agree with.
>
> - Which part of the text indicates this? I read this again, but I must have missed it..

Last sentence of 2.1.2. "Today, most operators use interfaces with global 
or unique-local addresses (option b)."

> - Do you have actual data about ULA usage? As this is isn’t externally visible, one might be surprised at how commonly it is used.

Nope, I do not, I commonly see links numbered with interface-unique GUA, I 
have not commonly seen * * * or ULA packets in traceroute.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-2132257136-1429105028=:16871--


From nobody Wed Apr 15 06:59: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 03D031B3495; Wed, 15 Apr 2015 06:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.225
X-Spam-Level: **
X-Spam-Status: No, score=2.225 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, 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 XspgSzfigJ2K; Wed, 15 Apr 2015 06:59:50 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8C98C1A90A3; Wed, 15 Apr 2015 06:59:50 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,582,1422939600"; d="scan'208";a="854337084"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Apr 2015 09:44:55 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 15 Apr 2015 09:59:49 -0400
From: "George, Wes" 
To: "Fred Baker (fred)" , IPv6 Ops WG 
Date: Wed, 15 Apr 2015 09:59:48 -0400
Thread-Topic: [v6ops] v6ops charter update discussion
Thread-Index: AdB3hG+slPpV2G3pTNuZbTGOCfKhIA==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [v6ops] v6ops charter update discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 13:59:53 -0000

T24gNC8xMy8xNSwgNzo1NyBQTSwgIkZyZWQgQmFrZXIgKGZyZWQpIiA8ZnJlZEBjaXNjby5jb20+
IHdyb3RlOg0KDQoNCj5MZWUgYW5kIEkgYXJlIHJldmlld2luZyB0aGUgdjZvcHMgY2hhcnRlci4g
SSBoYXZlIGF0dGFjaGVkIGEgcHJvcG9zZWQNCj5jaGFydGVyIGFuZCBkaWZmcyBhZ2FpbnN0IHRo
ZSBjdXJyZW50IG9uZS4gSm9lbCBoYXMgbm90IGNvbW1lbnRlZCBvbiB0aGlzDQo+eWV0LCBhbmQg
d2hpbGUgd2UgaGF2ZSBydW4gaXQgYnkgdGhlIHN1bnNldDQgY2hhaXJzLCB3ZSBoYXZlbuKAmXQg
Z290dGVuIGENCj5yZWFkaW5nIGZyb20gdGhlbS4gU3Vuc2V0NCBpcyByZWxldmFudCBiZWNhdXNl
IHBvc3NpYmx5IHRoZQ0KPmlwdjQtYXMtYS1zZXJ2aWNlIGRpc2N1c3Npb24gd291bGQgYmUgYmV0
dGVyIGhhbmRsZWQgdGhlcmUuIEluIHRoaXMNCj5lbWFpbCwgSeKAmW0gc29saWNpdGluZyBvcGlu
aW9ucyBpbiBnZW5lcmFsDQo+VGhlIGNoYXJ0ZXIgdXBkYXRlIHN0YXJ0ZWQgd2l0aCBMZWUgZmVl
bGluZyB0aGF0IHRoZSBmb3VydGggYnVsbGV0IG9mIG91cg0KPmN1cnJlbnQgY2hhcnRlciwgd2hp
Y2ggcmVhZHMNCj4gICAgNC4gUHVibGlzaCBJbmZvcm1hdGlvbmFsIG9yIEJDUCBSRkNzIHRoYXQg
aWRlbnRpZnkgYW5kIGFuYWx5emUNCj4gICAgICAgc29sdXRpb25zIGZvciBkZXBsb3lpbmcgSVB2
NiB3aXRoaW4gY29tbW9uIG5ldHdvcmsgZW52aXJvbm1lbnRzLA0KPiAgICAgICBzdWNoIGFzIElT
UCBOZXR3b3JrcywgRW50ZXJwcmlzZSBOZXR3b3JrcywgVW5tYW5hZ2VkIE5ldHdvcmtzDQo+ICAg
ICAgIChIb21lL1NtYWxsIE9mZmljZSksIGFuZCBDZWxsdWxhciBOZXR3b3Jrcy4NCj4gICAgICAg
KGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy92Nm9wcy9jaGFydGVyLykNCj5pcyBsYXJn
ZWx5IGRvbmUuIFdlIGtub3cgaG93IHRvIGRlcGxveSBJUHY2Lg0KDQpXR10gSSBhZ3JlZS4gV2Un
cmUgdW5saWtlbHkgdG8gc3B1ciBhZGRpdGlvbmFsIGRlcGxveW1lbnQgb2YgSVB2NiBieQ0KY29u
dGludWluZyB0byB3cml0ZSB0aGUgc2FtZSBkb2N1bWVudCBhYm91dCBob3cgdG8gZGVwbG95IGl0
IGZvciBldmVyeQ0KcG9zc2libGUgcGVybXV0YXRpb24gb2YgbmV0d29yayB3ZSBjYW4gdGhpbmsg
b2YuIEFzIG90aGVycyBoYXZlIHNhaWQsIEkNCmRvbid0IHRoaW5rIHRoYXQgaXQncyBleHBsaWNp
dGx5IHByb2hpYml0ZWQgaWYgd2UgY29tZSBhY3Jvc3MgYSBzcGVjaWZpYw0KY2FzZSB3ZSB0aGlu
ayBpcyB1c2VmdWwgdG8gZG9jdW1lbnQsIGJ1dCBpdCBzdG9wcyBiZWluZyB0aGUgcHJpbWFyeSBm
b2N1cw0Kb2YgdGhlIFdHLg0KDQoNCj5JbiBhZGRpdGlvbiwgSSB0aGluayB3ZSBuZWVkLCBjb2xs
ZWN0aXZlbHksIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGdldCB0bw0KPklQdjYtb25seS4NCldHXSBZ
ZXMsIGJ1dCBTdW5zZXQ0IGlzIGNoYXJ0ZXJlZCBmb3IgdGhhdCwgd2l0aCBlbm91Z2ggZmxleGli
aWxpdHkgdG8NCmNvdmVyIGJvdGggcHJvdG9jb2wgY2hhbmdlcyBhbmQgb3BlcmF0aW9uYWwgZ3Vp
ZGFuY2UvQkNQcy4gSSB0aGluayB3aGF0IHdlDQpuZWVkIHRvIGRvIGlzIHRvIGlkZW50aWZ5IGlu
IHRoZSBzdW5zZXQ0IGNoYXJ0ZXIgd2hhdCB5b3Ugd291bGQgZWl0aGVyDQpjYXJ2ZSBvZmYgdG8g
bW92ZSB0byB2Nm9wcywgb3IgaG93IHlvdSB3b3VsZCBkaXN0aW5ndWlzaCBjbGVhcmx5IGJldHdl
ZW4NCnRoZSBncm91cHMgc28gdGhhdCB3ZSBhbGwga25vdyB3aGF0IHdvcmsgZ29lcyB3aGVyZS4g
V2hlbiBzdW5zZXQ0IHdhcw0KYmVpbmcgZm9ybWVkLCB0aGUgZGl2aXNpb24gd2FzIHRoYXQgdjZv
cHMgd2FzIGZvY3VzZWQgb24gdHJhbnNpdGlvbiB0bw0KSVB2NiBhbmQgZHVhbC1zdGFjaywgYW5k
IHN1bnNldDQgd2FzIGZvY3VzZWQgb24gSVB2Ni1vbmx5IGluY2x1ZGluZyBob3cgdG8NCmFjdHVh
bGx5IHR1cm4gb2ZmIElQdjQuIFdoYXQgeW91J3JlIHByb3Bvc2luZyBibHVycyB0aGF0IGxpbmUN
CnNpZ25pZmljYW50bHkuIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zdW5zZXQ0L2No
YXJ0ZXIvIGlzIGEgc2hvcnQNCnJlYWQsIGJ1dCBhbnlvbmUgY29tbWVudGluZyBvbiBuZXcgd29y
ayBpbiB0aGlzIGFyZWEgbmVlZHMgdG8gYmUgZmFtaWxpYXINCndpdGggd2hhdCBpdCBzYXlzLiBT
dW5zZXQ0IGhhcyBiZWVuIHNvbWV3aGF0IHN0YXJ2ZWQgZm9yIGF0dGVudGlvbiwgYW5kIEkNCnRo
aW5rIHRoZSBvdmVybGFwIGluIHRoZSBpbnRlcmVzdGVkIHBhcnRpZXMgaXMgYSBmYWN0b3IsIHNv
IEknbSBub3QgaW4NCmZhdm9yIG9mIGluY3JlYXNpbmcgdGhlIG92ZXJsYXAgYmV0d2VlbiB0aGUg
dHdvIFdHcy4gSXQgbWF5IGJlIHRoYXQNClN1bnNldDQgbmVlZHMgdG8gcmVmb2N1cyBtb3JlIGV4
Y2x1c2l2ZWx5IG9uIHRoZSBJUHY0IHNpZGUgb2YgSVB2Ni1vbmx5LA0KdGhlIHR1cm5pbmcgb2Zm
IElQdjQgcGFydCAoc2hyaW5raW5nIGl0IGRvd24gdG8gaXNsYW5kcyBvZiBldmVyLWRlY3JlYXNp
bmcNCnNpemUsIGlkZW50aWZ5aW5nIHByb3RvY29sIGNoYW5nZXMgbmVjZXNzYXJ5IHRvIGFjdHVh
bGx5IGRpc2FibGUgaXQsIGV0YykNCndoaWxlIHY2b3BzIGlkZW50aWZpZXMgZ2FwcyBuZWNlc3Nh
cnkgdG8gYWN0dWFsbHkgbWFrZSBJUHY2LW9ubHkgd29yaw0KZXZlcnl3aGVyZSwgYXMgd2VsbCBh
cyBob3cgdG8gZ2V0IHRoZXJlIChvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucyBvbiBob3cNCnRv
IHVzZSB0aGUgYXZhaWxhYmxlIHRvb2xzIHRvIG1vdmUgZnJvbSBkdWFsLXN0YWNrIHRvIElQdjYt
b25seSkuDQpJIHRoaW5rIGluIHRoYXQgbW9kZWwsIElQdjQtYXMtYS1zZXJ2aWNlIGZpdHMgaW4g
U3Vuc2V0NCBhcyBvbmUgb2YgdGhlDQp0cmFuc2l0aW9ucyB0b3dhcmQgSVB2Ni1vbmx5IGFuZCBz
aHV0dGluZyBkb3duIElQdjQsIGJ1dCBpdCBwcm9iYWJseSBjYW4NCmJlIGRlYmF0ZWQgZWl0aGVy
IHdheS4gQnV0IGFnYWluLCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IGFueSBvZiB0aGF0IHdvcmsN
CmFjdHVhbGx5IG5lZWRzIHRvIG1vdmUgdG8gdjZvcHMuDQoNCj4gQSBsYXJnZSBpc3N1ZSBpcyDi
gJxzbyBob3cgZG8gd2UgY29ubmVjdCB0byBJUHY0IGNvbnRlbnQgYW5kIHNlcnZpY2VzIGZyb20N
Cj5hbiBJUHY2LW9ubHkgbmV0d29ya+KAnSwgd2hpY2ggaXMgd2hlcmUgaXB2NC1hcy1hLXNlcnZp
Y2UgY29tZXMgaW4uIEkNCj5wcm9wb3NlIGFkZGluZyBhIGJ1bGxldCBpdGVtIHJlZ2FyZGluZyBh
IHJvYWQgbWFwIHRvIElQdjYtb25seS4NCj4NCj4gICAgNC4gRGVzY3JpYmUgYW4gb3BlcmF0aW9u
YWwgcm9hZG1hcCB0byBJUHY2LW9ubHkgbmV0d29yayBkZXBsb3ltZW50LA0KPiAgICAgICB3aXRo
IG9yIHdpdGhvdXQgSVB2NCBkZWxpdmVyZWQgYXMgYW4gb3ZlcmxheSBvciB0cmFuc2xhdGlvbg0K
PiAgICAgICBzZXJ2aWNlLg0KDQpXR10gdGhpcyBzZWVtcyBsaWtlIGEgbWlsZXN0b25lIHJhdGhl
ciB0aGFuIGEgY2hhcnRlciBpdGVtLiBpLmUuIEhlcmUgaXMgYQ0KZG9jdW1lbnQgZGlzY3Vzc2lu
ZyBpbmNyZW1lbnRhbCBtb3ZlcyB0b3dhcmQgSVB2Ni1vbmx5LCB3aGF0IHRvb2xzIGFyZQ0KYXZh
aWxhYmxlLCBjb25zaWRlcmF0aW9ucywgZXRjLg0KDQo+SW4gbXkgbWluZCwgdGhhdCBpbmNsdWRl
cyBvcGVyYXRpb25hbCBkaXNjdXNzaW9ucyBvZiBkZXBsb3ltZW50cyBhbmQNCj5kZXBsb3ltZW50
IGlzc3VlcyBpbiBJUHY0LWFzLWEtc2VydmljZTsgb25lIHBvc3NpYmxlIHVwZGF0ZSB3b3VsZCBi
ZSB0bw0KPm1ha2UgdGhhdCBtb3JlIGV4cGxpY2l0Lg0KV0ddIHllcywgdGhhdCB3b3VsZCBoZWxw
IHRvIG1ha2UgdGhpcyBtb3JlIG9mIGEgY2hhcnRlciBpdGVtIGluc3RlYWQgb2YgYQ0Kc2luZ2xl
IGRvY3VtZW50IG1pbGVzdG9uZS4gQW5vdGhlciBwb3NzaWJpbGl0eSB3b3VsZCBiZSB0byBtYWtl
IGl0IGNsZWFyZXINCnRoYXQgaXRlbSA0IGlzIGdvaW5nIHRvIGRpc2N1c3Mgc2V2ZXJhbCBhcmVh
cywgbGlrZSBtb2JpbGUsIGVudGVycHJpc2UsDQpkYXRhY2VudGVyLCBTUCwgYW5kIHRoYXQgdGhv
c2Ugd291bGQgYWxsIGJlIHNlcGFyYXRlLCBtb3JlIGluLWRlcHRoLCBtb3JlDQpzcGVjaWZpYyBk
b2N1bWVudHMgaW5zdGVhZCBvZiBvbmUgbW9yZSBnZW5lcmljIG9uZS4gQnV0IGFnYWluLCBvdGhl
ciB0aGFuDQpkb2N1bWVudGluZyBvcGVyYXRpb25hbCBsZXNzb25zIGxlYXJuZWQgZnJvbSBleGlz
dGluZyBkZXBsb3ltZW50cywgSSdtDQpzdHJ1Z2dsaW5nIHRvIGlkZW50aWZ5IHdoZXJlIHRoZSBn
YXAgaW4gc3Vuc2V0NCdzIGNoYXJ0ZXIgaXMgdGhhdCBtYWtlcw0KdGhpcyBzb21ldGhpbmcgdGhh
dCB2Nm9wcyBuZWVkcyB0byB0YWtlIG9uDQoNCj5UaGUgb3RoZXIgdGhyZWUgdGFza3MgcmVtYWlu
IHVuY2hhbmdlZCAtIGNvbGxlY3Qgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSwNCj5pZGVudGlmeSBv
cGVyYXRpb25hbCBhbmQgc2VjdXJpdHkgcmlza3MsIGFuZCB0dXJuIHRoZW0gb3ZlciB0byBvdGhl
cg0KPndvcmtpbmcgZ3JvdXBzIC0gbm90YWJseSA2bWFuLg0KDQpXR10gSSB3b3VsZCByYXRoZXIg
c2VlIGl0ZW0gMiByZW1vdmVkLCBhcyBzZWN1cml0eSBkaXNjdXNzaW9ucyBzaG91bGQNCnJlYWxs
eSBiZSBoYW5kbGVkIGluIE9wc2VjLiBUaGV5J3JlIGFscmVhZHkgZG9pbmcgYSBsb3Qgb2YgZ29v
ZCB3b3JrIG9uDQpJUHY2IFNlY3VyaXR5LCBhbmQgdGhlIGdlbmVyYWwgaWRlYSBoZXJlIGlzIHRo
YXQgSVB2NiBpcyBpbiB0aGUgZGVwbG95bWVudA0KcGhhc2Ugbm93LCBzdWNoIHRoYXQgaXQgaXMg
YW4gaW50ZWdyYWwgcGFydCBvZiBuZXR3b3JrIHNlY3VyaXR5LCBhbmQgdGh1cw0Kc2hvdWxkIG5v
dCBiZSBjb25zaWRlcmVkIHNlcGFyYXRlbHkgaW4gbW9zdCBjYXNlcy4gVGhlcmUncyBub3RoaW5n
IGluDQpPcFNlYydzIGNoYXJ0ZXIgdGhhdCBwcmV2ZW50cyB0aGVtIGZyb20gYWRkcmVzc2luZyBJ
UHY2LXNwZWNpZmljIHNlY3VyaXR5DQppc3N1ZXMgYXMgdGhleSBhcmlzZSwgc28gaXQncyBub3Qg
bGlrZSB3ZSdkIGJlIGxpbWl0aW5nIG91cnNlbHZlcyBpZiB3ZQ0KcmVtb3ZlIHRoaXMgZnJvbSB0
aGUgdjZvcHMgY2hhcnRlci4gV2UncmUgZGVhbGluZyB3aXRoIGEgZmluaXRlIHBvb2wgb2YNCmZv
bGtzIHRoYXQgZm9jdXMgb24gc2VjdXJpdHkgYW5kIHJldmlldyBzZWN1cml0eSBkb2N1bWVudHMs
IGFuZCBJJ2QgcmF0aGVyDQpub3Qgc3ByZWFkIHRoZW0gdG9vIHRoaW5seSwgc28gaGF2aW5nIHRo
YXQgd29yayBjb25zb2xpZGF0ZSBpbnRvIHRoZQ0KT3BlcmF0aW9uYWwgU2VjdXJpdHkgV0cgc2Vl
bXMgbGlrZSB0aGUgcmlnaHQgbW92ZS4NCg0KPk9uIGFub3RoZXIgcG9pbnQsIExlZSBhbmQgSSBo
YXZlIGJlZW4gZGlzY3Vzc2luZyB0aGUgb3BlcmF0aW9uYWwgcmVwb3J0cw0KPndlIGhhZCBhdCBJ
RVRGIDkyLCBhbmQgZmVlbCB0aGF0IHdhcyB0aW1lIHdlbGwgc3BlbnQuIFRob3NlIGhhZCBhIGNv
bW1vbg0KPnRocmVhZCwgd2hpY2ggd2FzIHRoZSBkZXBsb3ltZW50IG9mIFNvZnR3aXJl4oCZcyBN
QVAtRSBhbmQgTUFQLVQNCj50ZWNobm9sb2dpZXMgaW4gdGhlaXIgbmV0d29ya3MuIFdlIGFyZSB0
aGlua2luZyBhYm91dCBhc2tpbmcgY29tcGFuaWVzDQo+ZGVwbG95aW5nIElQdjYgaW4gRXVyb3Bl
LCBBc2lhLCBhbmQgU291dGggQW1lcmljYSB0byBtYWtlIHJlcG9ydHMgaW4gdGhlDQo+Y29taW5n
IHRocmVlIG1lZXRpbmdzLCBvbiB0aGVpciBJUHY2IGRlcGxveW1lbnRzIGFuZCB0aGUgaXNzdWVz
IHRoZXkNCj5mYWNlLiBXb3VsZCB0aGF0IGJlIG9mIGdlbmVyYWwgaW50ZXJlc3Q/IEhvdyB3b3Vs
ZCB5b3UgcHJvcG9zZSB0byB0dW5lDQo+dGhhdCBjb25jZXB0Pw0KDQpXR10gSSB0aGluayB0aGlz
IGlzIGEgZ29vZCBpZGVhLCBiZWNhdXNlIGl0IHB1dHMgYSBsYXJnZXIgZm9jdXMgaW4gdGhpcw0K
Km9wZXJhdGlvbnMqIFdHIG9uIG9wZXJhdGluZyBuZXR3b3JrcyBhbmQgb3BlcmF0b3IgZmVlZGJh
Y2ssIHJlYWwNCmRlcGxveW1lbnQgZXhwZXJpZW5jZXMuIEV2ZW4gaWYgd2UncmUgc2VlaW5nIGR1
cGxpY2F0aW9uLCBpdCBwcm92aWRlcyBhbg0KYXZlbnVlIHRvIGFkZHJlc3MgdGhlIGNvbmNlcm5z
IHRoYXQgSUVURiBoYXMgYWJvdXQgbm90IGJlaW5nIGFibGUgdG8NCmF0dHJhY3Qgb3BlcmF0b3Jz
IGFuZCBvcGVyYXRpb25hbCBmZWVkYmFjay4gVGhhdCBzaG91bGQgc2VydmUgYXMgb3VyDQpwcmlt
YXJ5IHdvcmsgaW5wdXQsIGJlY2F1c2Ugd2Ugd2lsbCBiZSBhYmxlIHRvIGlkZW50aWZ5IHBsYWNl
cyB3aGVyZQ0KZXhpc3Rpbmcgc29sdXRpb25zIG1heWJlIGRvbid0IGNvdmVyIHRoZSBwcm9ibGVt
IGFkZXF1YXRlbHksIG9yIHBsYWNlcw0Kd2hlcmUgaXQncyBjbGVhciB0aGF0IHRoZSBleGlzdGlu
ZyBndWlkYW5jZSBpc24ndCBiZWluZyBoZWVkZWQsIHdoZXRoZXINCmJlY2F1c2UgcGVvcGxlIGRv
bid0IGtub3cgYWJvdXQgaXQsIG9yIGl0J3MgaW1wcmFjdGljYWwsIG9yIHdoYXRldmVyLg0KDQoN
ClRoYW5rcywNCg0KV2VzIEdlb3JnZQ0KDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMg
YmVlbiBhZGRlZCBieSBteSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSQ0KaGF2ZSBubyBjb250
cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRz
IGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGlu
Zm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3Qg
dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwg
aXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0
eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55
IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGlu
IHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1h
aWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy
IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkg
Y29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K


From nobody Wed Apr 15 08:17: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 514D61AC40D for ; Wed, 15 Apr 2015 08:17:23 -0700 (PDT)
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 tVVoXBL5YliI for ; Wed, 15 Apr 2015 08:17:21 -0700 (PDT)
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 477071A0383 for ; Wed, 15 Apr 2015 08:17:21 -0700 (PDT)
Received: from mb-aye.local ([172.56.39.21]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3FFGxSi003608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2015 15:17:17 GMT (envelope-from joelja@bogus.com)
To: "George, Wes" , Philip Matthews 
references:   
From: joel jaeggli 
x-enigmail-draft-status: N1110
message-id: <552E80CF.6030106@bogus.com>
Date: Wed, 15 Apr 2015 08:16:31 -0700
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0
mime-version: 1.0
in-reply-to: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xd9RTl83qqmvUpLhQd442CQigKnCpe4Vh"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 15:17:23 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Xd9RTl83qqmvUpLhQd442CQigKnCpe4Vh
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 4/15/15 5:47 AM, George, Wes wrote:
>=20
> From: Philip Matthews  >
> Date: Tuesday, April 14, 2015 at 10:30 PM
> To: "George, Wes"  >, Mark ZZZ Smith
> >
> Cc: v6ops list >
> Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
>=20
>=20
> Wes and Mark (and anyone else)
>=20
> Would you agree with me that, if one does use LLAs for eBGP endpoints, =
then:
> * One should use LLAs at both ends,  AND
>=20
> WG] yeah, in theory, but this assumes that the other ASN in an eBGP
> peering is amenable, which in many cases they will not be (I.e. I would=

> tell you to go pound sand and hand you my own GUA to use if you tried t=
o
> give me a LLA to peer with you on in eBGP), so that recommendation may
> only be useful for iBGP. I gave similar comments to the authors of 7404=

> that they were dramatically overselling the popularity of use of LLA,
> just as I think Mark is here, and I caution you that you're dancing
> around a potential third rail. There's a reason why 7404 could not
> achieve consensus without the caveat added to the end of the intro:=20

As somebody who buys a lot of transit circuits and has built more than a
few PNIs there's really no way I'd accept a LLA numbered transit from a
provider. among other things I have measurement platforms that are going
to want to test the other end of the interface from offlink. for my own
ipam demonstrable uniqueness is good.

We haven't gotten entirely away from the case where ebgp multihop links
exist, for example when you have more than one peering session with the
same provider because the peered router doesn't have a full table. I
expect such things to be terminated on the interface ip since the
loopbacks are for example covered by a router announced over one of
those sessions.

>    "During WG and IETF last call, the technical correctness of the
>    document was reviewed; however, debate exists as to whether to
>    recommend this technique.  The deployment of this technique is
>    appropriate where it is found to be necessary."
>=20
>=20
> In other words, there was concern that discussing use of LLAs in this
> manner in an IETF consensus document, even one written as neutrally as
> possible would be interpreted by those outside of the IETF as "the IETF=

> says to do this". I think the same concern applies here.=20
>=20
> * One should explicitly configure the LLAs at both ends
> WG] yes. I think my main point supports that recommendation so that it
> at least shows up in the configuration.
>=20
> PS. Wes: Will do on your "Other comments".  But it seems we are still
> debating your main point.
>=20
> WG] if you do go with your suggested model of discussing considerations=

> around LLAs, then considerations of GUAs, then pros and cons, I think i=
t
> fits well.
>=20
> Thanks,
> Wes
>=20
> -----------------------------------------------------------------------=
-
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is addressed=
=2E
> If you are not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or action taken=

> in relation to the contents of and attachments to this E-mail is
> strictly prohibited and may be unlawful. If you have received this
> E-mail in error, please notify the sender immediately and permanently
> delete the original and any copy of this E-mail and any printout.
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20



--Xd9RTl83qqmvUpLhQd442CQigKnCpe4Vh
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

iEYEARECAAYFAlUugM8ACgkQ8AA1q7Z/VrK2XwCfQ0SOq+2zuC1Vj3hMOd0e6iYI
Px0An0qZGUverUBCSwwTXle+ABZ0kQq1
=SWgx
-----END PGP SIGNATURE-----

--Xd9RTl83qqmvUpLhQd442CQigKnCpe4Vh--


From nobody Wed Apr 15 09:50: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 AE3AD1B2DA6 for ; Wed, 15 Apr 2015 09:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 xCRkrhgp_IQ8 for ; Wed, 15 Apr 2015 09:50:49 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 24AAB1B2D94 for ; Wed, 15 Apr 2015 09:50:49 -0700 (PDT)
Received: by lbbuc2 with SMTP id uc2so38761317lbb.2 for ; Wed, 15 Apr 2015 09:50:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=J4BjnbSkng6zYfajME9O1SBXXouqEhf3zLTZTVD4Emc=; b=RlfIG3vPu47PGQceaTgVg0bHvbDM02QKwVro6fM2rLc3HuaIMAav4Qh2vRvoUSq3AN eAEqaKIAZ0FYg6ubfwAYylyZ5dElFHJjp4YNkiZ/sBvQX8xE3Cna/HaMXJMvxBLQYw2J dRR+78qWP/fTuLri4MCkQte0FPTKCk1lo49xG7BRK6A/k+Th/Uvl4EGqjW0oH5H1ekqs 41uUGeMxoc9G6Vh8ncLP2qC5WU59GEHeFssdDtYMV5tfsj/nM9CC98kpp8uFinsIYqeq IZbS+UrdQgUVDi9qcKRVTraF+GAGsymvyX87et8iJQbgerj8dl0ITLV1ZyQ8shVzSr9T 4pcg==
MIME-Version: 1.0
X-Received: by 10.112.77.103 with SMTP id r7mr14642584lbw.63.1429116647667; Wed, 15 Apr 2015 09:50:47 -0700 (PDT)
Received: by 10.112.26.111 with HTTP; Wed, 15 Apr 2015 09:50:47 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 15 Apr 2015 11:50:47 -0500
Message-ID: 
From: Alberto Leiva 
To: v6ops@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [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: Wed, 15 Apr 2015 16:50:50 -0000

Hello

I mailed the writers of RFC 6791.

The consensus is that when an SIIT receives a packet that includes an
Interface Information Object and needs to write one of its own, it
should append, not replace.
This is because, quoting Dan Wing, "there must have been a good reason
the ICMP packet arrived with an extension header."

There is momentum to raise errata to add this bit of trivia to RFC
6791, but the fact remains "appending" contradicts RFC 5837.

Four options seem to exist:

1. Define a new role. This seems cleanest to me.
2. Ignore RFC 5837 and upload errata to 6791 anyway (both roles 2 and
4 seem acceptable).
3. Upload errata to both RFCs.
4. Do nothing?

Strong opinions, anybody?

Thank you
Alberto


From nobody Wed Apr 15 12:34: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 93B081A896A for ; Wed, 15 Apr 2015 12:34:45 -0700 (PDT)
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 19sCQGWzbyNQ for ; Wed, 15 Apr 2015 12:34:43 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 776EC1A8965 for ; Wed, 15 Apr 2015 12:34:43 -0700 (PDT)
Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 52745403A8 for ; Wed, 15 Apr 2015 15:34:45 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: JF Tremblay 
In-Reply-To: 
Date: Wed, 15 Apr 2015 15:34:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com>   
To: v6ops list 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 19:34:45 -0000

> On Apr 15, 2015, at 9:37 AM, Mikael Abrahamsson  =
wrote:
>=20
> On Tue, 14 Apr 2015, JF Tremblay wrote:
>=20
>>> I also question how common it is to use ULAs, with current wording =
it seems to indicate that both are quite common, which I don't agree =
with.
>>=20
>> - Which part of the text indicates this? I read this again, but I =
must have missed it..
>=20
> Last sentence of 2.1.2. "Today, most operators use interfaces with =
global or unique-local addresses (option b).=E2=80=9D

Ah! That might be one more reason to split this one in a, b and c.=20

>> - Do you have actual data about ULA usage? As this is isn=E2=80=99t =
externally visible, one might be surprised at how commonly it is used.
>=20
> Nope, I do not, I commonly see links numbered with interface-unique =
GUA, I have not commonly seen * * * or ULA packets in trace route.

Fair enough. Might not cover cases where propagate-ttl is disabled or =
when ULA is used off-path, but it=E2=80=99s a valid observation.=20

JF


From nobody Wed Apr 15 12:56: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 3A18A1A87E8 for ; Wed, 15 Apr 2015 12:56:30 -0700 (PDT)
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 FgY4CtCNziPc for ; Wed, 15 Apr 2015 12:56:29 -0700 (PDT)
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 03DCD1A8861 for ; Wed, 15 Apr 2015 12:56:28 -0700 (PDT)
Received: from mb-aye.local ([8.18.217.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3FJuSUA005402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2015 19:56:28 GMT (envelope-from joelja@bogus.com)
To: JF Tremblay , v6ops list 
references: <201504121800.t3CI03dR022647@irp-lnx1.cisco.com>    
From: joel jaeggli 
x-enigmail-draft-status: N1110
message-id: <552EC267.9010206@bogus.com>
Date: Wed, 15 Apr 2015 12:56:23 -0700
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0
mime-version: 1.0
in-reply-to: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2J2A9fUXGCGJnECaxv68rDfB0VSRSk4CP"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 15 Apr 2015 19:56:30 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2J2A9fUXGCGJnECaxv68rDfB0VSRSk4CP
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 4/15/15 12:34 PM, JF Tremblay wrote:
>>> - Do you have actual data about ULA usage? As this is isn=E2=80=99t e=
xternally visible, one might be surprised at how commonly it is used.
>>
>> Nope, I do not, I commonly see links numbered with interface-unique GU=
A, I have not commonly seen * * * or ULA packets in trace route.
>=20
> Fair enough. Might not cover cases where propagate-ttl is disabled or w=
hen ULA is used off-path, but it=E2=80=99s a valid observation.=20

In general  I would expect responsible ISPs and end sites to filter ULA
sourced packets on ingress as they do RFC 1918 to prevent their use in
spoofing.

our recommendations with respect to accepting such prefixes as
advertisements from a peer are in

https://tools.ietf.org/html/rfc7454#section-6.1.1

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



--2J2A9fUXGCGJnECaxv68rDfB0VSRSk4CP
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

iEYEARECAAYFAlUuwmcACgkQ8AA1q7Z/VrL64gCfR2KSWvy1g9KjwIJV5up+GpwW
y94An3ITRmyYOa2gRnCqagIE44/w2atG
=QwQ3
-----END PGP SIGNATURE-----

--2J2A9fUXGCGJnECaxv68rDfB0VSRSk4CP--


From nobody Wed Apr 15 15:56: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 BCCE11A8790 for ; Wed, 15 Apr 2015 15:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.78
X-Spam-Level: 
X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, TVD_SPACE_RATIO=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 P_1hlyEwFtYm for ; Wed, 15 Apr 2015 15:56:25 -0700 (PDT)
Received: from g9t5008.houston.hp.com (g9t5008.houston.hp.com [15.240.92.66]) (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 B1CFB1AC3C6 for ; Wed, 15 Apr 2015 15:56:25 -0700 (PDT)
Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g9t5008.houston.hp.com (Postfix) with ESMTPS id 4D66D7CC for ; Wed, 15 Apr 2015 22:56:25 +0000 (UTC)
Received: from G9W3616.americas.hpqcorp.net (16.216.186.51) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 15 Apr 2015 22:53:58 +0000
Received: from G9W0721.americas.hpqcorp.net ([169.254.2.185]) by G9W3616.americas.hpqcorp.net ([16.216.186.51]) with mapi id 14.03.0169.001; Wed, 15 Apr 2015 22:53:58 +0000
From: "Cronin, Jon" 
To: "v6ops@ietf.org" 
Thread-Topic: unsubscribe
Thread-Index: AdB3zwnA8MiCkXsYTWmB+rUM3wdjJA==
Date: Wed, 15 Apr 2015 22:53:58 +0000
Message-ID: <0B874456FB46054F8B16F61EA0B8A56423A76427@G9W0721.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [16.210.48.14]
Content-Type: multipart/alternative; boundary="_000_0B874456FB46054F8B16F61EA0B8A56423A76427G9W0721americas_"
MIME-Version: 1.0
Archived-At: 
Subject: [v6ops] unsubscribe
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 15 Apr 2015 22:56:26 -0000

--_000_0B874456FB46054F8B16F61EA0B8A56423A76427G9W0721americas_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

unsubscribe


--_000_0B874456FB46054F8B16F61EA0B8A56423A76427G9W0721americas_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











unsubscribe



 






--_000_0B874456FB46054F8B16F61EA0B8A56423A76427G9W0721americas_--


From nobody Wed Apr 15 16:52: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 E3B671ACD97 for ; Wed, 15 Apr 2015 16:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 bYE_WrN6E5bX for ; Wed, 15 Apr 2015 16:52:15 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 CFCEE1ACD90 for ; Wed, 15 Apr 2015 16:52:14 -0700 (PDT)
Received: by qkx62 with SMTP id 62so109260631qkx.0 for ; Wed, 15 Apr 2015 16:52:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heyaaron.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=e9XnQribpo/rU5G9l2NDoq51weNKUYnfCOuF53yVavk=; b=BHY4ZeLB5aY/ywyI7XPMZgWWtWW+idwRDpUBMoXi812Qxan69fk9c6dz4Mo8Pjqekx vTrZ7D2zCkEcY04XD59VWJ+muRZx/Xz76PxwyAdxLkJUtmzXOFHx0qqyUtNkvLe0rvt3 Cy2knRlYqxyQbD9DJ7WRuRwggHiL8swuZIF74=
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=e9XnQribpo/rU5G9l2NDoq51weNKUYnfCOuF53yVavk=; b=QTTb2PQUclfMff7qiQO32Je5puKe7Vrjxa3caheQ2ynvR0hTStN76PRoLU6cunOJWo 33BrUYZsvHu+zHTWFTjNQOcn1zvIxv3dPSKsonsaKgR9Dx3difzJF3giQ9ZspTJR75/R 5I5P2vtnWtVOLFogEVnZ8PRdXCaOJ9CY3XyjeIQm2xgHJ27qqZXHMkJaMvfbuRRAgZ2e nOFOiFyYZZw1BI2OC38DNl4fq2FUmpUg6M/bdG0gq56mvuLbQyLGL31guhthi/uImclF l/JettcL/xYdznvTeFGyttGoJvkD1mtj5Y1zIxGl38alimIbqqPeECP/O16qNilBtORz hkww==
X-Gm-Message-State: ALoCoQkVY4nzrttUpVUqqNtADcWR8KZNmTXAMXMnLi8H2O0mgIZps8GrIddMGsnJkye8O7e5Pi/F
X-Received: by 10.229.37.200 with SMTP id y8mr36106800qcd.28.1429141925289; Wed, 15 Apr 2015 16:52:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.159.136 with HTTP; Wed, 15 Apr 2015 16:51:50 -0700 (PDT)
In-Reply-To: <0B874456FB46054F8B16F61EA0B8A56423A76427@G9W0721.americas.hpqcorp.net>
References: <0B874456FB46054F8B16F61EA0B8A56423A76427@G9W0721.americas.hpqcorp.net>
From: "Aaron C. de Bruyn" 
Date: Wed, 15 Apr 2015 16:51:50 -0700
Message-ID: 
To: "Cronin, Jon" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] unsubscribe
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 15 Apr 2015 23:52:16 -0000

Try here: https://www.ietf.org/mailman/listinfo/v6ops  (It's listed at
the bottom of every message you receive from the list.)

-A

On Wed, Apr 15, 2015 at 3:53 PM, Cronin, Jon  wrote:
> unsubscribe
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Wed Apr 15 18:19: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 2B7C51A886F for ; Wed, 15 Apr 2015 18:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level: 
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 XSy9-bpE_x5V for ; Wed, 15 Apr 2015 18:19:16 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 91ECC1A886C for ; Wed, 15 Apr 2015 18:19:16 -0700 (PDT)
Received: from [10.214.157.11] (mobile-166-171-056-126.mycingular.net [166.171.56.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 36BC2540957; Wed, 15 Apr 2015 21:16:23 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jared Mauch 
X-Mailer: iPhone Mail (12F70)
In-Reply-To: 
Date: Wed, 15 Apr 2015 21:16:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <038320EF-56EE-4E1A-A44F-3BC2DB697683@puck.nether.net>
References: <0B874456FB46054F8B16F61EA0B8A56423A76427@G9W0721.americas.hpqcorp.net> 
To: "Aaron C. de Bruyn" 
Archived-At: 
Cc: "v6ops@ietf.org" , "Cronin, Jon" 
Subject: Re: [v6ops] unsubscribe
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 Apr 2015 01:19:18 -0000

Running a list I've discovered a few things:

You get someone who has emails pointed at them from an older employee that l=
eft and they don't read the mailman notices or look at headers.

You also get people who have gone through 3 domain changes that also don't r=
ead the monthly mailman notices or headers and don't realize example.com now=
 forwards to ISO-3166-2.example.com etc.=20

Jared Mauch

> On Apr 15, 2015, at 7:51 PM, Aaron C. de Bruyn  wrote:=

>=20
> Try here: https://www.ietf.org/mailman/listinfo/v6ops (It's listed at
> the bottom of every message you receive from the list.)
>=20
> -A
>=20
>> On Wed, Apr 15, 2015 at 3:53 PM, Cronin, Jon  wrote:
>> unsubscribe
>>=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


From nobody Wed Apr 15 19:26: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 8061D1B2ADD for ; Wed, 15 Apr 2015 19:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 MFbrNS7EhLpU for ; Wed, 15 Apr 2015 19:26:04 -0700 (PDT)
Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B0E1B2ADA for ; Wed, 15 Apr 2015 19:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429151162; bh=+JLFRBufcHNYSYt1CMqqzkkL7px5fcXFeLcngi2sC8k=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=hJzH48j936nK2n3VL+hFuYnCrtKZMx79v3xzcT/RfULTtdJCkKq2u+mZ4BXiiCeUIM8ztno55wjjbbE2Bb3MvYv7IQBo45a4eAftAgRwe58wmgqyYytq/U1WuQBT4a+VzpnE9KtclGmkcwKnkJMaSZYIc0PlYIAx6O99qNo5vbQTOZhvgWbYMbMp78/4/FH0fFaMey4EtL7sSlhDrgkpayNqrOYqJVgn36BikEVq+byzP5wYMZjFKw5OU6zYj8whX2ksm2uSbUU9gMYOfStAxmhsoLMvercATzHOYFUOPLVBboqpYqgT1i7B/puj4RAyWUKVxIJ92z/YJRC7dWRC7w==
Received: from [98.139.214.32] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 16 Apr 2015 02:26:02 -0000
Received: from [98.139.212.205] by tm15.bullet.mail.bf1.yahoo.com with NNFMP;  16 Apr 2015 02:26:02 -0000
Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 16 Apr 2015 02:26:02 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 836276.9194.bm@omp1014.mail.bf1.yahoo.com
X-YMail-OSG: 0fUrkLwVM1nivEvBmNpTyzYSWPJum0pIYrxQFOpxbobKgTJTBjwjL78vMyDOZiE NIzmuGR7PgZ.UueOEBPgwUIJ8YcTkjjXZOiUaT5_3xjYdhzLYXaGGHkuxSQQ3Tm8xh2.lR7fhonf Z5a4Lq_TAUU90kgKJUTDzLmC7XcfwvYD4kbr834TsK3HeUc4k8KRy8b00S1TyEA7LWV1Vtoo2NBW FXpLgdc.41Ocu2zHaRgU238c5rYstR_RoatFCXtdeqCzsptbWeb9DI5NTlM8KGs0sbzJ5ncZHPRC ZPYi6RxQruRG_YzsUW_os_duzEo51f9Ohec8I2p.5y6XIXG45lHXhIYMs8hJOeGcWuJb8OFNvd9j a8DLzv5QymrpZ4oRbI6aEguPbMr_L9ecG_2hfWBLmhGaPt_tl9Fl3mpGQVOWoRx8c7CVYZ6pafX9 sIBvTPG1kXmRmRIA9i4LUbVP_rZOzZigYGrP3EnO765p243MKy5OZQrk06ZHBocCrZCf6qr33DFw 29cXTgtLjkz6Bb54f_4WIp0xFYfa3h1NIX5AGXWuuBU8GWqnq
Received: by 76.13.26.127; Thu, 16 Apr 2015 02:26:02 +0000 
Date: Thu, 16 Apr 2015 02:26:01 +0000 (UTC)
From: Mark ZZZ Smith 
To: "George, Wes" ,  Philip Matthews 
Message-ID: <1687633436.4938262.1429151161336.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_4938261_162788366.1429151161328"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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: Thu, 16 Apr 2015 02:26:05 -0000

------=_Part_4938261_162788366.1429151161328
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: "George, Wes" 
 To: Philip Matthews =20
Cc: v6ops list =20
 Sent: Wednesday, 15 April 2015, 22:47
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =20

From: Philip Matthews 
Date: Tuesday, April 14, 2015 at 10:30 PM
To: "George, Wes" , Mark ZZZ Smith 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC



In other words, there was concern that discussing use of LLAs in this manne=
r in an IETF consensus document, even one written as neutrally as possible =
would be interpreted by those outside of the IETF as "the IETF says to do t=
his". I think the same concern applies here.=C2=A0
/ I don't think we should really consider that concern much. There are plen=
ty of useful and informative RFCs that shouldn't have been written publishe=
d if we were to just target the audience who believe all RFCs are prescript=
ive. I don't think that "audience" is much of one at all, as their unlikely=
 to spend much if any time reading RFCs. I think the audience we should be =
targeting is the one who will spend the time reading and considering the co=
ntents of RFCs.



* One should explicitly configure the LLAs at both endsWG] yes. I think my =
main point supports that recommendation so that it at least shows up in the=
 configuration.
PS. Wes: Will do on your "Other comments". =C2=A0But it seems we are still =
debating your main point.
WG] if you do go with your suggested model of discussing considerations aro=
und LLAs, then considerations of GUAs, then pros and cons, I think it fits =
well.


Thanks,Wes
This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

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


  
------=_Part_4938261_162788366.1429151161328
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



  
 
 
    From: "George, Wes" <wesley.george@twcable=
.com>
 To:=
 Philip Matthews <philip_matthews@magma.ca> 
Cc: v6ops list <v6ops@ietf.org> 
 Sent: Wednesday, 15 April 2015, 22:47
 Subject: Re=
: [v6ops] draft-ietf-v6ops-design-choices WGLC
  <=
/div> 


















From: Philip Matthews <philip_matthews@magma.ca>

Date: Tuesday, April 14, 2015 at 10:30 PM

To: "George, Wes" <wesley.george@twcable=
.com>, Mark ZZZ Smith <markzzzsmith@yahoo.com.au>

Cc: v6ops list <v6ops@ietf.org>

Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGL=
C


















<s=
nip>







In other words, t=
here was concern that discussing use of LLAs in this manner in an IETF cons=
ensus document, even one written as neutrally as possible would be interpre=
ted by those outside of the IETF as "the IETF says to do this". I think the=
 same concern
 applies here. 





/ I don't think we should really consider that concern much. There are ple=
nty of useful and informative RFCs that shouldn't have been written publish=
ed if we were to just target the audience who believe all RFCs are prescrip=
tive. I don't think that "audience" is much of one at all, as their unlikel=
y to spend much if any time reading RFCs. I think the audience we should be=
 targeting is the one who will spend the time reading and considering the c=
ontents of RFCs.











* One should explicitly config=
ure the LLAs at both ends







WG] yes. I think my main point=
 supports that recommendation so that it at least shows up in the configura=
tion.














PS. Wes: Will do on your "Othe=
r comments".  But it seems we are still debating your main point.






WG] if you do go with your sug=
gested model of discussing considerations around LLAs, then considerations =
of GUAs, then pros and cons, I think it fits well.
















Thanks,


Wes





This E-mail and any of its a=
ttachments may contain Time Warner Cable proprietary information, which is =
privileged, confidential, or subject to copyright belonging to Time Warner =
Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If you a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.




__________________________________=
_____________
v6ops mailing list
v6ops@ietf.org
<=
a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"https://www.iet=
f.org/mailman/listinfo/v6ops">https://www.ietf.org/mailman/listinfo/v6ops
=



=

 <=
/div>
 
  

------=_Part_4938261_162788366.1429151161328--


From nobody Wed Apr 15 20:04: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 E357E1B2D18 for ; Wed, 15 Apr 2015 20:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 iLsqp39Ro4mS for ; Wed, 15 Apr 2015 20:04:13 -0700 (PDT)
Received: from nm36.bullet.mail.bf1.yahoo.com (nm36.bullet.mail.bf1.yahoo.com [72.30.239.5]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F481B2D13 for ; Wed, 15 Apr 2015 20:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429153452; bh=hEjUY3cAvH0q4VN30jMptveio7FbiVq7h/ODSlRS9SY=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=FTrAJ228bzBrCMbajbz5Kvx0oKbJ3M9KQtJTSkDUsFfXcQmODW1SSNHy8erQP2g0aY8jXhBubpw9avAx3Csd6SL4gtzwVxYwMY0vEPZM/snkzGrKaUWulNzQ+N1//XFkIAJexZY8QNDb78bJSZ5XCgJvP4WU5YlEvgucitp0vm3Y10AAWhwLs7nxvUaJQlRC9RLNUVCCB7ex3JzpPkp7WCcgz/U8PSm15KIdaCZM+jKjkQWe0gxuESlnKZtN98mmEjnx9Sxa7InxWgwyIRFUaIfHmzh7DBhvMH3gn1mM3Bp5wBrRfIIXQIqWbvZH+5yHXSnv3cuwIQ/byg2k7zMkIA==
Received: from [98.139.170.181] by nm36.bullet.mail.bf1.yahoo.com with NNFMP;  16 Apr 2015 03:04:12 -0000
Received: from [98.139.212.208] by tm24.bullet.mail.bf1.yahoo.com with NNFMP;  16 Apr 2015 03:04:12 -0000
Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 16 Apr 2015 03:04:12 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 478869.97988.bm@omp1017.mail.bf1.yahoo.com
X-YMail-OSG: 9jQ2HDgVM1mxIyeH9_3vPqFLn99USjsRRdk78L2E84yOKsp0d4nVvOdw99YA7MX wo.f9BGVtKlHs7toECvr6qH09PaEF_5AIaay0zsWSLmm_Q287I7k25ki0Vu79dXL7Vfb.7dsCoNo FqA6vVtpYpbgFbDGLesfA6p2YBqhUx08AZ4wetm.2vMuOq9pWwoJ04WGQ1Jjp7pcxg03hJ86Mfn. Ce12KhqQ6JAFUJVnCZeBLNv._SkoT2IBB9mMdaLPuaFaiRi3lleW8vGz5CWGJ6x7t0bfBvwMFJYt fzN9GM.u5IaauOK_U_SJEMoQsiZJincveZsxD9kQmpMsj9gY.CzIR8HOFTXmYIEbli56rLzQkF42 1s3PFGG1IkP84ebVeMtAmI82ZAgBNTX7g8odlC1fQ6CnYSqJkjhhSa00lZgQCuStKpHkcfZ6JCQd KwjM6a_kuZcO2MhRybFiuF5PFmQRaQauLlbhXqrJYRPINdw.mmidQpNMmzvJJshBYnSu0B1H2NwI wXs.oq85.JHV7BeC6TxjoWWqR1LB_pFVQQvz39dIZAvTmE6X3
Received: by 76.13.27.35; Thu, 16 Apr 2015 03:04:11 +0000 
Date: Thu, 16 Apr 2015 03:04:10 +0000 (UTC)
From: Mark ZZZ Smith 
To: joel jaeggli ,  "George, Wes" ,  Philip Matthews 
Message-ID: <1578440258.4923796.1429153450858.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <552E80CF.6030106@bogus.com>
References: <552E80CF.6030106@bogus.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_4923795_532600968.1429153450850"
Archived-At: 
Cc: v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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: Thu, 16 Apr 2015 03:04:16 -0000

------=_Part_4923795_532600968.1429153450850
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: joel jaeggli 
 To: "George, Wes" ; Philip Matthews =20
Cc: v6ops list =20
 Sent: Thursday, 16 April 2015, 1:16
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =20
On 4/15/15 5:47 AM, George, Wes wrote:
>=20
> From: Philip Matthews  >
> Date: Tuesday, April 14, 2015 at 10:30 PM
> To: "George, Wes"  >, Mark ZZZ Smith
> >
> Cc: v6ops list >
> Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
>=20
>=20
> Wes and Mark (and anyone else)
>=20
> Would you agree with me that, if one does use LLAs for eBGP endpoints, th=
en:
> * One should use LLAs at both ends,=C2=A0 AND
>=20
> WG] yeah, in theory, but this assumes that the other ASN in an eBGP
> peering is amenable, which in many cases they will not be (I.e. I would
> tell you to go pound sand and hand you my own GUA to use if you tried to
> give me a LLA to peer with you on in eBGP), so that recommendation may
> only be useful for iBGP. I gave similar comments to the authors of 7404
> that they were dramatically overselling the popularity of use of LLA,
> just as I think Mark is here, and I caution you that you're dancing
> around a potential third rail. There's a reason why 7404 could not
> achieve consensus without the caveat added to the end of the intro:=20

As somebody who buys a lot of transit circuits and has built more than a
few PNIs there's really no way I'd accept a LLA numbered transit from a
provider. among other things I have measurement platforms that are going
to want to test the other end of the interface from offlink. for my own
ipam demonstrable uniqueness is good.
/ I assume you're describing a link-local only transit link? I wouldn't be =
advocating that.
/ Choosing to use LLAs instead of also present GUAs for eBGP session end po=
ints is actually consistent with the IPv6 src/dest address selection princi=
ple of choosing the smallest scope when there are multiple candidate addres=
ses.
/ There are definitely trade-offs if you used LLAs instead of GUAs for eBGP=
 session end points. I like how using LLAs with next-hop self would decoupl=
e the eBGP session from the GUA prefix, such that it would be possible to r=
enumber the GUA without disrupting the eBGP session and the traffic that ma=
tches the prefixes being announced over the eBGP session, with exception to=
 the traffic matching the prefix for the renumbered GUA itself. Renumbering=
 the GUA on the link is not going to be a common task, but if it is necessa=
ry to perform, then the disruption avoided by using LLAs would be significa=
nt (e.g., no out of hours work, no significant traffic impact, one less hig=
h severity service impact notice etc.)


We haven't gotten entirely away from the case where ebgp multihop links
exist, for example when you have more than one peering session with the
same provider because the peered router doesn't have a full table. I
expect such things to be terminated on the interface ip since the
loopbacks are for example covered by a router announced over one of
those sessions.


/ Certainly you'd have to use the GUA addresses for that, as the LL scope i=
s obviously too small to work.

/ Regards,/ Mark.

>=C2=A0 =C2=A0 "During WG and IETF last call, the technical correctness of =
the
>=C2=A0 =C2=A0 document was reviewed; however, debate exists as to whether =
to
>=C2=A0 =C2=A0 recommend this technique.=C2=A0 The deployment of this techn=
ique is
>=C2=A0 =C2=A0 appropriate where it is found to be necessary."
>=20
>=20
> In other words, there was concern that discussing use of LLAs in this
> manner in an IETF consensus document, even one written as neutrally as
> possible would be interpreted by those outside of the IETF as "the IETF
> says to do this". I think the same concern applies here.=20
>=20
> * One should explicitly configure the LLAs at both ends
> WG] yes. I think my main point supports that recommendation so that it
> at least shows up in the configuration.
>=20
> PS. Wes: Will do on your "Other comments".=C2=A0 But it seems we are stil=
l
> debating your main point.
>=20
> WG] if you do go with your suggested model of discussing considerations
> around LLAs, then considerations of GUAs, then pros and cons, I think it
> fits well.
>=20
> Thanks,
> Wes
>=20
> ------------------------------------------------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is addressed.
> If you are not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or action taken
> in relation to the contents of and attachments to this E-mail is
> strictly prohibited and may be unlawful. If you have received this
> E-mail in error, please notify the sender immediately and permanently
> delete the original and any copy of this E-mail and any printout.
>=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


  
------=_Part_4923795_532600968.1429153450850
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



   
 
 
   From: joel jaeggli <joelja@bogus.com>
 To: "George, Wes" <wesl=
ey.george@twcable.com>; Philip Matthews <philip_matthews@magma.ca>=
 
Cc: v6ops list <v6=
ops@ietf.org> 
 Sent: Thursday, 16 April 2015, 1:16
 S=
ubject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  
 

On 4/15/15 5:47 AM, George, Wes wrote:
> <=
br clear=3D"none">> From: Philip Matthews <philip_matthews@magma.ca
> <mailto:philip_matthews@magma.ca>>
=
> Date: Tuesday, April 14, 2015 at 10:30 PM
> To: "=
George, Wes" <wesley.george@twcable.com
> <mailto:wesley.ge=
orge@twcable.com>>, Mark ZZZ Smith
> <markzzzsmith@yahoo.com.au <mailto:markzzzsmith@yahoo.com.au>>
> Cc: v6ops list <v6ops@ietf.org <mailto:=
v6ops@ietf.org>>
> Subject: Re: [v6ops] draf=
t-ietf-v6ops-design-choices WGLC
> 
=
> 
> Wes and Mark (and anyone else)
> 
> Would you agree with me that, if one does u=
se LLAs for eBGP endpoints, then:
> * One should use L=
LAs at both ends,  AND
> 
> =
WG] yeah, in theory, but this assumes that the other ASN in an eBGP
> peering is amenable, which in many cases they will not be (=
I.e. I would
> tell you to go pound sand and hand you =
my own GUA to use if you tried to
> give me a LLA to p=
eer with you on in eBGP), so that recommendation may
>=
 only be useful for iBGP. I gave similar comments to the authors of 7404> that they were dramatically overselling the popularity=
 of use of LLA,
> just as I think Mark is here, and I =
caution you that you're dancing
> around a potential t=
hird rail. There's a reason why 7404 could not
> achie=
ve consensus without the caveat added to the end of the intro: 

As somebody who buys a lot of transit circuits an=
d has built more than a
few PNIs there's really no way I'=
d accept a LLA numbered transit from a
provider. among ot=
her things I have measurement platforms that are going
to=
 want to test the other end of the interface from offlink. for my own
ipam demonstrable uniqueness is good.

/ I a=
ssume you're describing a link-local only transit link? I wouldn't be advoc=
ating that.

/ Choosing to use LLAs instead o=
f also present GUAs for eBGP session end points is actually consistent with=
 the IPv6 src/dest address selection principle of choosing the smallest sco=
pe when there are multiple candidate addresses.

/ There are definitely trade-offs if you used LLAs instead of GUAs for =
eBGP session end points. I like how using LLAs with next-hop self would dec=
ouple the eBGP session from the GUA prefix, such that it would be possible =
to renumber the GUA without disrupting the eBGP session and the traffic tha=
t matches the prefixes being announced over the eBGP session, with exceptio=
n to the traffic matching the prefix for the renumbered GUA itself. Renumbe=
ring the GUA on the link is not going to be a common task, but if it is nec=
essary to perform, then the disruption avoided by using LLAs would be signi=
ficant (e.g., no out of hours work, no significant traffic impact, one less=
 high severity service impact notice etc.)


We haven't gotten entirely away from the case where eb=
gp multihop links
exist, for example when you have more t=
han one peering session with the
same provider because th=
e peered router doesn't have a full table. I
expect such =
things to be terminated on the interface ip since the
loo=
pbacks are for example covered by a router announced over one of
those sessions.



/ Certainly you'd have to use the GUA addresses for t=
hat, as the LL scope is obviously too small to work.

=
/ Regards,
/ Mark.
<=
br clear=3D"none">>    "During WG and IETF last call, the tech=
nical correctness of the
>    document was r=
eviewed; however, debate exists as to whether to
>&nbs=
p;   recommend this technique.  The deployment of this technique =
is
>    appropriate where it is found to be =
necessary."
> 
> 
> In other words, there was concern that discussing use of LLAs in th=
is
> manner in an IETF consensus document, even one wr=
itten as neutrally as
> possible would be interpreted =
by those outside of the IETF as "the IETF
> says to do=
 this". I think the same concern applies here. 
> 
> * One should explicitly configure the LLAs at both ends=

> WG] yes. I think my main point supports that recomm=
endation so that it
> at least shows up in the configu=
ration.
> 
> PS. Wes: Will do on =
your "Other comments".  But it seems we are still
&g=
t; debating your main point.
> 
>=
 WG] if you do go with your suggested model of discussing considerations> around LLAs, then considerations of GUAs, then pros an=
d cons, I think it
> fits well.
>=
 
> Thanks,
> Wes
> 
> -------------------------------------------=
-----------------------------
> This E-mail and any of=
 its attachments may contain Time Warner Cable
> propr=
ietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is =
intended
> solely for the use of the individual or ent=
ity to which it is addressed.
> If you are not the int=
ended recipient of this E-mail, you are hereby
> notif=
ied that any dissemination, distribution, copying, or action taken
> in relation to the contents of and attachments to this E-mai=
l is
> strictly prohibited and may be unlawful. If you=
 have received this
> E-mail in error, please notify t=
he sender immediately and permanently
> delete the ori=
ginal and any copy of this E-mail and any printout.
> =

> 
> ___________________________=
____________________
> 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_4923795_532600968.1429153450850--


From nobody Wed Apr 15 20:11: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 C26261B2D41 for ; Wed, 15 Apr 2015 20:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 9A8n8TKHdGhp for ; Wed, 15 Apr 2015 20:11:19 -0700 (PDT)
Received: from nm32-vm6.bullet.mail.bf1.yahoo.com (nm32-vm6.bullet.mail.bf1.yahoo.com [72.30.239.142]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A401A90AC for ; Wed, 15 Apr 2015 20:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429153878; bh=4uBJ1BNsEsdcPUtviZTtWvGBUqfH8cWy3bDN6LNgHvw=;  h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject;  b=KmizPLlc8TznJdmqBzXYo6hu4FPO/IwJ3oSzO7OJjR2eP1SSRF/6XYBbA0kZ3/ldM04VqONEJoIj1SXSsUu/U+tr1bFdm78l3zY0hUeBivlC230we3+LcquPNbVyIr3GV8P/AOtVXGp94I5qrfQIdShrJLf/oPwxAwfxna7RhySKZbAkeVQ0jnRP5rLF2796L0G4g/MJ6uNvY/oSDSuvkM/uMg62fvgCgDwWhEy4oB4zHzAJKF28/L+L/I7WIQ3UnO+rr0nV+N3fbPAuKPoxAl3tx2HRsC/NLWyMrPX/ck6bIw6AH3V7Yi0t9cJ8MhiS9j0hg230qCWVyPn3Q6lFDQ==
Received: from [98.139.170.182] by nm32.bullet.mail.bf1.yahoo.com with NNFMP;  16 Apr 2015 03:11:18 -0000
Received: from [98.139.212.224] by tm25.bullet.mail.bf1.yahoo.com with NNFMP;  16 Apr 2015 03:11:18 -0000
Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 16 Apr 2015 03:11:18 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 204913.82219.bm@omp1033.mail.bf1.yahoo.com
X-YMail-OSG: oJjTXPUVM1lcWPuOSnoBJTn8dhLAN7qS1O8_Dkns1SJr9mv9Q6b_aOKdOYRltGz ozbSA47U75_kmATYJcLor4tMjZdfF4rNINw1FP5F6bC3TrG0wsO0MT9K2i0CQuoQiDYa.KwbBlwz y8HEJxctam9MCWPjE3NTvvmTV3EmZJvjB4t8Sj7pQo3wd26wrXv_NagN819T6CEvobTuxgdWRAnQ sHqn27Q9.HZ7qUgsOpBFiqrxkNqO8D1up37Bb7Echr8hkHI2WlQ8o80rcXn5.t6sJHdu06f8qgaC xc08WRFlFZ7V2qZ9bKZerV1i4kEPmTQcLmfGB4kiN1.FD31OIQK3g8P5n1Sp7ySVJeI0s7zDbrRz PiKD1OvYkjdzN5qrBU9aarDtCUX.bhKdz.PIrnBa4vYTkD5BS8PZ8HhxLowgOL7ThdClQPwomqQk .T1Gda5U.I1wZq5z4Np.LCN8Yz2Ddu7DzYZNjRAum7qhu_pZ23PFHFQbGqsSqsnfwQ5oeKWmfdTH fOOvhIg0zdMZxYLjy1ZohBC9ivC4bLgtL1lKU0YKJNS0h8RV9Hg--
Received: by 66.196.80.122; Thu, 16 Apr 2015 03:11:17 +0000 
Date: Thu, 16 Apr 2015 03:11:13 +0000 (UTC)
From: Mark ZZZ Smith 
To: JF Tremblay ,  v6ops list 
Message-ID: <948226155.4966562.1429153873833.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_4966561_1977131816.1429153873828"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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: Thu, 16 Apr 2015 03:11:20 -0000

------=_Part_4966561_1977131816.1429153873828
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: JF Tremblay 
 To: v6ops list =20
 Sent: Thursday, 16 April 2015, 5:34
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
  =20

> On Apr 15, 2015, at 9:37 AM, Mikael Abrahamsson  wrote:
>=20
> On Tue, 14 Apr 2015, JF Tremblay wrote:
>=20
>>> I also question how common it is to use ULAs, with current wording it s=
eems to indicate that both are quite common, which I don't agree with.
>>=20
>> - Which part of the text indicates this? I read this again, but I must h=
ave missed it..
>=20
> Last sentence of 2.1.2. "Today, most operators use interfaces with global=
 or unique-local addresses (option b).=E2=80=9D

Ah! That might be one more reason to split this one in a, b and c.=20

>> - Do you have actual data about ULA usage? As this is isn=E2=80=99t exte=
rnally visible, one might be surprised at how commonly it is used.
>=20
> Nope, I do not, I commonly see links numbered with interface-unique GUA, =
I have not commonly seen * * * or ULA packets in trace route.

Fair enough. Might not cover cases where propagate-ttl is disabled or when =
ULA is used off-path, but it=E2=80=99s a valid observation.=20


/ IPv6 src/dest selection rules should be hiding ULAs from you when you're =
external to networks that are using both GUAs and ULAs. i.e., if your sourc=
e address is a GUA, then the traceroute ICMP messages should be using GUA s=
ource addresses rather than ULAs if they're available. ULAs should only be =
leaking if there is no GUA to use and packets with ULA source addresses are=
n't being blocked at the ULA numbered network's boundary, contrary to good =
internal/private address practices.
/ ULAs shouldn't be very visible on the Internet because that is the point =
of them, they're meant for internal use only. So, as the saying goes, "abse=
nce of evidence is not evidence of absence."
/Regards,/Mark.


JF

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


  
------=_Part_4966561_1977131816.1429153873828
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



   
 
 
   From: JF Tremblay <jean-francois.tremblay@viagenie.ca&g=
t;
 To: v6ops list <=
v6ops@ietf.org> 
 Sent:<=
/b> Thursday, 16 April 2015, 5:34
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC
 <=
/font> 
 


> On Apr 15, 2015, at 9:37 AM, Mikael A=
brahamsson <swmike@swm.pp.se> wrote:
> 
> On Tue, 14 Apr 2015, JF Tremblay wrote:> 
>>> I also question how co=
mmon it is to use ULAs, with current wording it seems to indicate that both=
 are quite common, which I don't agree with.
>> >> - Which part of the text indicates this? I read th=
is again, but I must have missed it..
> 
> Last sentence of 2.1.2. "Today, most operators use interfaces wit=
h global or unique-local addresses (option b).=E2=80=9D
<=
br clear=3D"none">Ah! That might be one more reason to split this one in a,=
 b and c. 

>> - Do you have actu=
al data about ULA usage? As this is isn=E2=80=99t externally visible, one m=
ight be surprised at how commonly it is used.
> 
> Nope, I do not, I commonly see links numbered with interf=
ace-unique GUA, I have not commonly seen * * * or ULA packets in trace rout=
e.

Fair enough. Might not cover cases =
where propagate-ttl is disabled or when ULA is used off-path, but it=E2=80=
=99s a valid observation. 



/ I=
Pv6 src/dest selection rules should be hiding ULAs from you when you're ext=
ernal to networks that are using both GUAs and ULAs. i.e., if your source a=
ddress is a GUA, then the traceroute ICMP messages should be using GUA sour=
ce addresses rather than ULAs if they're available. ULAs should only be lea=
king if there is no GUA to use and packets with ULA source addresses aren't=
 being blocked at the ULA numbered network's boundary, contrary to good int=
ernal/private address practices.

/ ULAs shouldn't be very visible on the Internet because th=
at is the point of them, they're meant for internal use only. So, as the sa=
ying goes, "absence of evidence is not evidence of absence."

/Regards,
/Mark.


JF

__________________________________=
_____________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/m=
ailman/listinfo/v6ops


 
   

------=_Part_4966561_1977131816.1429153873828--


From nobody Thu Apr 16 06:28: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 2E10D1ACDFA for ; Thu, 16 Apr 2015 06:28:01 -0700 (PDT)
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, 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 H530lgZJEIQI for ; Thu, 16 Apr 2015 06:27:58 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id AA9801ACD6A for ; Thu, 16 Apr 2015 06:27:58 -0700 (PDT)
Received: from h229.viagenie.ca (h229.viagenie.ca [206.123.31.229]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4F6C346911 for ; Thu, 16 Apr 2015 09:28:00 -0400 (EDT)
From: JF Tremblay 
Content-Type: multipart/alternative; boundary="Apple-Mail=_2D33B8CF-0CED-4954-BA0D-1564BC031D8D"
Message-Id: <47EC4CB6-3077-4A91-8FAA-52021BFED04E@viagenie.ca>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Date: Thu, 16 Apr 2015 09:27:55 -0400
References:  <948226155.4966562.1429153873833.JavaMail.yahoo@mail.yahoo.com>
To: v6ops list 
In-Reply-To: <948226155.4966562.1429153873833.JavaMail.yahoo@mail.yahoo.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices 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, 16 Apr 2015 13:28:01 -0000

--Apple-Mail=_2D33B8CF-0CED-4954-BA0D-1564BC031D8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Apr 15, 2015, at 11:11 PM, Mark ZZZ Smith  =
wrote:
> > Nope, I do not, I commonly see links numbered with interface-unique =
GUA, I have not commonly seen * * * or ULA packets in trace route.
> Fair enough. Might not cover cases where propagate-ttl is disabled or =
when ULA is used off-path, but it=E2=80=99s a valid observation.=20
>=20
> / IPv6 src/dest selection rules should be hiding ULAs from you when =
you're external to networks that are using both GUAs and ULAs. i.e., if =
your source address is a GUA, then the traceroute ICMP messages should =
be using GUA source addresses rather than ULAs if they're available. =
ULAs should only be leaking if there is no GUA to use and packets with =
ULA source addresses aren't being blocked at the ULA numbered network's =
boundary, contrary to good internal/private address practices.

That was Mikael=E2=80=99s point. Stars (***) in a traceroute might be an =
externally-visible indication of filtered ULAs sources. But he was =
arguing he hasn=E2=80=99t seen it often, which is a valid data point.=20


> / ULAs shouldn't be very visible on the Internet because that is the =
point of them, they're meant for internal use only. So, as the saying =
goes, "absence of evidence is not evidence of absence.=E2=80=9D

My point exactly, thanks for the better wording. If, for example, P =
routers in an MPLS network are numbered in ULA (I=E2=80=99ve done this) =
and do not decrease TTL, they will not show up at all in traceroutes.=20

JF




--Apple-Mail=_2D33B8CF-0CED-4954-BA0D-1564BC031D8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Apr 15, 2015, at 11:11 PM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:
> Nope, I do not, I commonly =
see links numbered with interface-unique GUA, I have not commonly seen * =
* * or ULA packets in trace route.
Fair =
enough. Might not cover cases where propagate-ttl is disabled or when =
ULA is used off-path, but it=E2=80=99s a valid observation. 

/ IPv6 src/dest selection rules =
should be hiding ULAs from you when you're external to networks that are =
using both GUAs and ULAs. i.e., if your source address is a GUA, then =
the traceroute ICMP messages should be using GUA source addresses rather =
than ULAs if they're available. ULAs should only be leaking if there is =
no GUA to use and packets with ULA source addresses aren't being blocked =
at the ULA numbered network's boundary, contrary to good =
internal/private address practices.

That was Mikael=E2=80=99s point. Stars (***) in a =
traceroute might be an externally-visible indication of filtered ULAs =
sources. But he was arguing he hasn=E2=80=99t seen it often, which is a =
valid data point. 


/ ULAs shouldn't be very visible on the =
Internet because that is the point of them, they're meant for internal =
use only. So, as the saying goes, "absence of evidence is not evidence =
of absence.=E2=80=9D

My =
point exactly, thanks for the better wording. If, for example, P routers =
in an MPLS network are numbered in ULA (I=E2=80=99ve done this) and do =
not decrease TTL, they will not show up at all in =
traceroutes. 

JF



=

--Apple-Mail=_2D33B8CF-0CED-4954-BA0D-1564BC031D8D--


From nobody Thu Apr 16 22:46: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 BE6471ACE61 for ; Thu, 16 Apr 2015 22:46:01 -0700 (PDT)
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 j0Ltw1KLeUSs for ; Thu, 16 Apr 2015 22:46:00 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002281ACE5F for ; Thu, 16 Apr 2015 22:45:59 -0700 (PDT)
Received: from [2a02:c0:2:4:6666:17:0:1001] (port=37312 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 1Yiz6C-0008P5-Pt; Fri, 17 Apr 2015 07:45:56 +0200
Date: Fri, 17 Apr 2015 07:45:19 +0200
From: Tore Anderson 
To: Lorenzo Colitti 
Message-ID: <20150417074519.347762ae@echo.ms.redpill-linpro.com>
In-Reply-To: 
References:   <20150320134204.32af9c67@echo.ms.redpill-linpro.com> 
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Apr 2015 05:46:01 -0000

* Lorenzo Colitti 

> On Fri, Mar 20, 2015 at 7:42 AM, Tore Anderson  wrote:
> 
> > Justine Vick from Microsoft held a very interesting presentation at
> > the V6 World Congress on Wednesday about their plans to make one of
> > their buildings IPv6-only. One of the things she had identified a
> > need for was to have a CLAT in the desktop version of Windows. She
> > had already established contact with the relevant teams to try to
> > make that happen (I asked her to add the Windows Server folks to
> > her CC list). Fingers crossed!
> 
> Are the slides of that presentation available, and if not, do you
> know how we might be able to read them? (e.g., by getting in touch
> with Justine).

The slides were only available for delegates with a username/password,
so unfortunately I couldn't share them with the list. However I see now
that a recording of Justine's presentation has been made publicly
available at YouTube: https://www.youtube.com/watch?v=ev-hUpLaFbw

Tore


From nobody Fri Apr 17 00:17: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 095971AD2F6 for ; Fri, 17 Apr 2015 00:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.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] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFI0b8PefC6U for ; Fri, 17 Apr 2015 00:16:58 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29C01AD2DF for ; Fri, 17 Apr 2015 00:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2184; q=dns/txt; s=iport; t=1429255018; x=1430464618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cmlH205PTP0zWpNyB4Nigr31LtvLXxcFk1zHpO6C+uw=; b=KQd6fzllMLbtWhaRDLmW7bfUrOScm9W3dmMLllXg0lbl2+JNlAVTvsF8 NM829XLlamWPJ2Z0AHYmFADNll43iAhb1VCTZMoIfYuZL+uMUJJWhw9l1 +HSu5QzT349fd+Q/g1gSpiENYRR3d7go4K4nzKskh/n98qsh1RRkkvpCc 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BVBAAXsjBV/4ENJK1dgwyBLgWDEsJxCYdSAhyBLzgUAQEBAQEBAX2EIQEBBCMRRRACAQgODAImAgICMBUQAgQBDQWIKrI4lS4BAQEBAQEBAQEBAQEBAQEBAQEBGYEhigiEYRsHgmiBRQEEkSKKHoEdgzqMZYNOIoNvb4FEfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,592,1422921600"; d="scan'208";a="141961267"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 17 Apr 2015 07:16:57 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3H7Gvch006932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Apr 2015 07:16:58 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 17 Apr 2015 02:16:57 -0500
From: "Eric Vyncke (evyncke)" 
To: Fernando Gont , Merike Kaeo , "v6ops@ietf.org" 
Thread-Topic: draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
Thread-Index: AQHQdo71E0ZUSo/JSk2+YiQd8CcElJ1RRTKA
Date: Fri, 17 Apr 2015 07:17:31 +0000
Message-ID: 
References: <552CD2CE.3070801@si6networks.com>
In-Reply-To: <552CD2CE.3070801@si6networks.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [10.55.185.71]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Apr 2015 07:17:00 -0000

RmVybmFuZG8NCg0KWW91ciBwcm9wb3NhbCBpcyBmaW5lIGZvciBtZSwgYnV0LCBJIHdvdWxkIHN1
Z2dlc3QgYSBzbGlnaHRseSBzdHJvbmdlcg0KdGV4dDoNCiJUaGUgcmVzdWx0cyBwcmVzZW50ZWQg
aW4gdGhpcyBkb2N1bWVudCBpbmRpY2F0ZSB0aGF0IGluIHRoZSBzY2VuYXJpb3MNCndoZXJlIHRo
ZSBjb3JyZXNwb25kaW5nIG1lYXN1cmVtZW50cyB3ZXJlIHBlcmZvcm1lZCwgdGhlIHVzZSBvZiBJ
UHY2DQpleHRlbnNpb24gaGVhZGVycyBjYW4gbGVhZCB0byBwYWNrZXQgZHJvcHMuIFdlIG5vdGUg
dGhhdA0KcGFja2V0IGRyb3BzIG9jY3VycmluZyBhdCB0cmFuc2l0IG5ldHdvcmtzIGlzIHVuZGVz
aXJhYmxlDQphbmQgaXQgaXMgaG9wZWQgYW5kIGV4cGVjdGVkIHRoYXQgdGhpcyBzaXR1YXRpb24g
d2lsbCBpbXByb3ZlIG92ZXIgdGltZS4iDQoNClNob3VsZCB3ZSBzYXkgc29tZXRoaW5nIGFyb3Vu
ZCB0aGUgbGluZXMgb2YgIi4uLiBVbmRlc2lyYWJsZSBleGNlcHQgd2hlbg0KVGhvc2UgcGFja2V0
cyBjYW5ub3QgYmUgZm9yd2FyZGVkIHdpdGhvdXQgaW1wYWN0aW5nIHRoZSBwZXJmb3JtYW5jZSBh
bmQNCnRoZSBoZWFsdGggb2YgdGhlIG5ldHdvcmsgZGV2aWNlcyIgPw0KDQotw6lyaWMgDQoNCk9u
IDE0LzA0LzE1IDEwOjQxLCAiRmVybmFuZG8gR29udCIgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4g
d3JvdGU6DQoNCj5Gb2xrcywNCj4NCj5BdCB0aGUgbGFzdCB2Nm9wcyBtZWV0aW5nLCB0aGVyZSBz
ZWVtZWQgdG8gYmUgYWdyZWVtZW50IGFib3V0IGluY2x1ZGluZw0KPnNvbWUgdGV4dCBub3Rpbmcg
dGhhdCB3aGlsZSByZXN1bHRzIGluZGljYXRlIHRoYXQgdXNlIG9mIElQdjYgRUhzIGhhcw0KPmJl
ZW4gZm91bmQgdG8gcmVzdWx0IGluIHBhY2tldCBkcm9wcywgYXQgbGVhc3QgZm9yIHRyYW5zaXQg
QVNlcyBzdWNoDQo+YmVoYXZpb3IgaXMgdW5kZXNpcmFibGUuDQo+DQo+U28gdGhpcyBpcyBhICpm
aXJzdCB0cnkqIChwbGVhc2Ugc3VnZ2VzdCBlZGl0cyB0byB0aGlzIHRleHQgaWYgeW91DQo+dGhp
bmsgdGhhdCdzIG5lY2Vzc2FyeSk6DQo+DQo+IlRoZSByZXN1bHRzIHByZXNlbnRlZCBpbiB0aGlz
IGRvY3VtZW50IGluZGljYXRlIHRoYXQgaW4gdGhlIHNjZW5hcmlvcw0KPndoZXJlIHRoZSBjb3Jy
ZXNwb25kaW5nIG1lYXN1cmVtZW50cyB3ZXJlIHBlcmZvcm1lZCwgdGhlIHVzZSBvZiBJUHY2DQo+
ZXh0ZW5zaW9uIGhlYWRlcnMgY2FuIGxlYWQgdG8gcGFja2V0IGRyb3BzLiBXZSBub3RlIHRoYXQs
IGluIHBhcnRpY3VsYXIsDQo+cGFja2V0IGRyb3BzIG9jY3VycmluZyBhdCB0cmFuc2l0cyBBdXRv
bm9tb3VzIFN5c3RlbXMgaXMgdW5kZXNpcmFibGUsDQo+YW5kIGl0IGlzIGV4cGVjdGVkIHRoYXQg
dGhpcyBzaXR1YXRpb24gd2lsbCBpbXByb3ZlIG92ZXIgdGltZS4iDQo+DQo+VGhhbmtzIQ0KPg0K
PkJlc3QgcmVnYXJkcywNCj4tLSANCj5GZXJuYW5kbyBHb250DQo+U0k2IE5ldHdvcmtzDQo+ZS1t
YWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb20NCj5QR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBE
NDg0IDYzQjIgOEZCMSBFM0M0IEFFMjUgMEQ1NSAxRDRFIDc0OTINCj4NCj4NCj4NCj4NCj4NCg0K


From nobody Fri Apr 17 05:50: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 051F51B2BF7 for ; Fri, 17 Apr 2015 05:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.283
X-Spam-Level: 
X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 LawI85lFRMeF for ; Fri, 17 Apr 2015 05:50:05 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AC71B2BF1 for ; Fri, 17 Apr 2015 05:50:04 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3HCo0aw007794; Fri, 17 Apr 2015 14:50:00 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 569782044A0; Fri, 17 Apr 2015 14:51:17 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4668B2008E9; Fri, 17 Apr 2015 14:51:17 +0200 (CEST)
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 t3HCnw4U031703; Fri, 17 Apr 2015 14:49:59 +0200
Message-ID: <55310176.4080203@gmail.com>
Date: Fri, 17 Apr 2015 14:49:58 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Gert Doering 
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com> <20150407123653.GS54385@Space.Net>
In-Reply-To: <20150407123653.GS54385@Space.Net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Apr 2015 12:50:07 -0000

Le 07/04/2015 14:36, Gert Doering a écrit :
> Hi,
>
> On Tue, Apr 07, 2015 at 12:06:39PM +0200, Alexandru Petrescu wrote:
>> This begs a question about particular hardware which may not
>> distinguish types, and thus force others to drop-all RHs,
>> regardless of their type - what is that hardware?
>
> "Hardware+Software".  My current beef is Cisco IOS XR on ASR9001,
> which has hardware capable of doing about anything, and software
> that missed that particular call...
>
> (Of course there's 6500/Sup720, which has hardware not capable of
> doing any EH header filtering, but that is *old* stuff and not
> particularily relevant here)

I agree with that point.

There are 2 problems here: either the operator consciously filters EHs
of a certain kind, or the software on the router is not yet aware of
some recently defined EHs.

One can distinguish betwween the two by checking whether an ICMPv6
parameter problem is issued or not.

In a particular network I am connecting to, an intervening router sends
back an ICMPv6 Parameter Problem with a Pointer field pointing to the
type Home Address of a Destination Options extension header (EH) of a
Binding Update of protocol Mobile IPv6.

Intuitively, that suggests that the router complaining of that EH may be
old, not updated to understand Mobile IPv6 (although the MIP spec is
there for many years and many commercial and oss implementations are out
there since long).

This EH is absolutely necessary to exist in real world to offer the
mobility part of IPv6.  Filtering it consciously does not avoid security
risks (there aren't for MIP non-RO).   It must be allowed.

Alex
>
> Gert Doering -- NetMaster
>



From nobody Fri Apr 17 11:51: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 EB4A51B2F68 for ; Fri, 17 Apr 2015 11:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT2J_BL1ud4a for ; Fri, 17 Apr 2015 11:51:21 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578FD1B2F4B for ; Fri, 17 Apr 2015 11:51:21 -0700 (PDT)
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.85) (envelope-from ) id 1YjBM9-0002hA-5N; Fri, 17 Apr 2015 20:51:13 +0200
Message-ID: <55315619.3030802@si6networks.com>
Date: Fri, 17 Apr 2015 15:51:05 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Eric Vyncke (evyncke)" ,  Merike Kaeo , "v6ops@ietf.org" 
References: <552CD2CE.3070801@si6networks.com> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Apr 2015 18:51:23 -0000

Hi, Eric,

On 04/17/2015 04:17 AM, Eric Vyncke (evyncke) wrote:
> Fernando
> 
> Your proposal is fine for me, but, I would suggest a slightly stronger
> text:
> "The results presented in this document indicate that in the scenarios
> where the corresponding measurements were performed, the use of IPv6
> extension headers can lead to packet drops. We note that
> packet drops occurring at transit networks is undesirable
> and it is hoped and expected that this situation will improve over time."
> 
> Should we say something around the lines of "... Undesirable except when
> Those packets cannot be forwarded without impacting the performance and
> the health of the network devices" ?

I'm fine with the text you suggest.

The only comment/question is that there are two conflicting povs: frm
the use pov, he'd probably like his packets to go through transparently,
and hence the packet drops are undesirable (no matter what). But from
the network operator pov, the packet drops aren't undesireable (ot one
culd say that they really are.. in the sense that the network operator
would be glad to not need to drop these packets).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Fri Apr 17 18:46:52 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 1DE061A1AA8 for ; Fri, 17 Apr 2015 18:46:51 -0700 (PDT)
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 H9-lZ9tol3sK for ; Fri, 17 Apr 2015 18:46:49 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838E51A1AA0 for ; Fri, 17 Apr 2015 18:46:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2425; q=dns/txt; s=iport; t=1429321609; x=1430531209; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HPxkdgX7LkN1szc1cGsPZVbg46cqqeXjMKXHfmrBz0o=; b=EORl83d2TZq+NjRSVsEyeoiXj9Ipwpm8dqDXJ59VG0UVlphf0YBCvAmZ ey/h7qc4ZGpb3FmAsbjPTHb6GnB9ZhXAsmabk8PL5FJvEcQ6vRcN9sF+e dICs1q79XqKSQMFZvj+LfTM3gPHNSwuGzHpSetl4M+Wqv9SzfBvF3Pz0i I=;
X-Files: signature.asc : 487
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AsBQCMtjFV/4MNJK1dgwyBIgwFgxLKcwKBO0wBAQEBAQF+hCABAQEDASNCFAULAgEIGCoCAjIlAgQOBQ6IFQiyf5UhAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sphHwHgmgvgRYFkSKBcIE0hnqBHZAfg04iggUdgVFvgUSBAAEBAQ
X-IronPort-AV: E=Sophos;i="5.11,598,1422921600";  d="asc'?scan'208";a="412809580"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 18 Apr 2015 01:46:48 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3I1kmcf011496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Apr 2015 01:46:48 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.151]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 17 Apr 2015 20:46:48 -0500
From: "Fred Baker (fred)" 
To: "Eric Vyncke (evyncke)" 
Thread-Topic: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
Thread-Index: AQHQeXmH6a8kE3wgqEqbL9cOqvPdJw==
Date: Sat, 18 Apr 2015 01:46:47 +0000
Message-ID: <41AF40EF-C4CB-41F7-8BC4-567A02A49FF4@cisco.com>
References: <552CD2CE.3070801@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.75.234.85]
Content-Type: multipart/signed; boundary="Apple-Mail=_E58F5FA8-1689-47C1-830E-EA25851B2374"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: 
Cc: Fernando Gont , "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Apr 2015 01:46:51 -0000

--Apple-Mail=_E58F5FA8-1689-47C1-830E-EA25851B2374
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Apr 17, 2015, at 3:17 PM, Eric Vyncke (evyncke)  =
wrote:
>=20
> Your proposal is fine for me, but, I would suggest a slightly stronger
> text:
> "The results presented in this document indicate that in the scenarios
> where the corresponding measurements were performed, the use of IPv6
> extension headers can lead to packet drops. We note that
> packet drops occurring at transit networks is undesirable
> and it is hoped and expected that this situation will improve over =
time."
>=20
> Should we say something around the lines of "... Undesirable except =
when
> Those packets cannot be forwarded without impacting the performance =
and
> the health of the network devices" ?

Well, question for you. If we follow RFC 2460, the router in the middle =
doesn=E2=80=99t know whether the header is there or not. The only =
systems that should have a performance impact are systems that parse to =
them or interpret them. I personally would like to believe that we =
aren=E2=80=99t making *other* systems more complex to save them. If this =
is being done in a firewall or load balancer, the limitations of the =
device aren=E2=80=99t primary, the correct operation of the protocol is. =
Would we be saying that it=E2=80=99s OK for a firewall to drop a packet =
because it doesn=E2=80=99t feel like dealing with it that day?

What specific devices did you have in mind? What would the argument be?

--Apple-Mail=_E58F5FA8-1689-47C1-830E-EA25851B2374
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

iQEVAwUBVTG3gp9ieig10VPpAQJXPgf/Sn60adJUQYVOqAPlmOcGxaCdiQDhFwDo
eRA+inSgbTfSEWwAzFOOr7iCiwivK4SXdC8plKZvLEWqW8BeZURUNuUNDS4UmiGm
VIuheBvF9F35XYx46lI5urmiPg1X9SjENEZoiWd0ZnbFZktjY5jcxNmxzDpgGNsE
D/iEPF1+QpL6I2lcM6+6OYtZB+jsJT4nbualS5FYTMt+ZdU2MqRAn/SmOqSdyaS5
/W9dzpdgX4yOImWOx+GnkvsGobQoQILHt3L4bmxl0lZd5KjrBmTpY92gugf8XLVQ
KU6dIZpmdCVvUrNivcCEaRcSKckzjQP8qjURttc+wlMqf0y6VpACgg==
=W13o
-----END PGP SIGNATURE-----

--Apple-Mail=_E58F5FA8-1689-47C1-830E-EA25851B2374--


From nobody Fri Apr 17 22:57:45 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 BB7601AC408 for ; Fri, 17 Apr 2015 22:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.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] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZrnW6u5yuZl for ; Fri, 17 Apr 2015 22:57:42 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073BD1AC409 for ; Fri, 17 Apr 2015 22:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3018; q=dns/txt; s=iport; t=1429336662; x=1430546262; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zCCaVUiJeVDpGbZ9Q3bXZNsgDGHsm600gmDoGCeQ3eI=; b=AVYTYYOIj8u6g3fNy20bfg+2zIhwWExHhx5bmMkVwmxUC9LqS5znFjUD BDoe+IAsiSM62DvbQhxkBfqRkX9akGMM2ubhQymgm5HSxI+LYY53Joy8u 17+13S9avecQg9F7HDxf8f2y8LGT7Nzp4i8VW3Cq+J8nyrW/S/nGlVCJU 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BfBAD/8TFV/4wNJK1dgwyBIgwFgxLDFwmHUh6BHzgUAQEBAQEBAX2EIQEBAwEjETEUEgEIGgImAgQwFRIEDgWIIwiyYZRgAQEBAQEBAQEBAQEBAQEBARyBIYoIhEkYG4JvgUUFkSOKIIEekCGDTiKCBR2BUW+BRIEAAQEB
X-IronPort-AV: E=Sophos;i="5.11,598,1422921600"; d="scan'208";a="142367964"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 18 Apr 2015 05:57:19 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t3I5vIl7029050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Apr 2015 05:57:19 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sat, 18 Apr 2015 00:57:18 -0500
From: "Eric Vyncke (evyncke)" 
To: "Fred Baker (fred)" 
Thread-Topic: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
Thread-Index: AQHQeZyH8RTkhzTRMEKrqyhyQ/fbUw==
Date: Sat, 18 Apr 2015 05:58:22 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [10.55.185.71]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8FB234FAFCB9D64D8CF01DCB695AB993@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Fernando Gont , "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Apr 2015 05:57:43 -0000

RnJlZCwNCg0KVGhlIHBlcmZvcm1hbmNlIGltcGFjdC9uZXR3b3JrIGhlYWx0aCBpc3N1ZXMgYXJl
IG1haW5seSByZWxhdGVkIHRvDQpob3AtYnktaG9wIHdoaWNoIGlzIHBlciBSRkMgMjQ2MCBpbnNw
ZWN0ZWQgYnkgZXZlcnkgcm91dGVyIG9uIHRoZSBwYXRoLg0KVGhpcyBFSCBzaG91bGQgYmUgaWdu
b3JlIElNSE8gYnkgYWxsIHJvdXRlcnMgb3ZlciB0aGUgSW50ZXJuZXQgKHByaXZhdGUNCm5ldHdv
cmtzIG1heSBzdGlsbCBpbnNwZWN0L2FjdCBvbiBpdCBmb3IgUlNWUCBmb3IgZXhhbWluZSkuDQoN
CklmIGZvciBzb21lIHJlYXNvbnMsIGEgcm91dGVyIGluIHRoZSBtaWRkbGUgbmVlZHMgYWNjZXNz
IHRvIGxheWVyLTQNCmluZm9ybWF0aW9uIChJUEZJWD8gRERvUyBtaXRpZ2F0aW9uPyAuLi4gPyks
IHRoZW4gdGhlIEVIIGNoYWluIG11c3QgYmUNCnBhcnNlZCB3aGljaCBjYW4gY2F1c2UgYSBwZXJm
b3JtYW5jZSBpbXBhY3QuDQoNCkRvIG5vdCB0YWtlIG1lIHdyb25nOiBiZXNpZGUgaWdub3Jpbmcg
SGJILCBJIHJlYWxseSBob3BlIHRoYXQgcm91dGVycyBvbg0KdGhlIHBhdGhzIHNpbXBseSBsb29r
IGF0IGxheWVyLTMgaGVhZGVyIGFuZCBkbyBub3RoaW5nIGVsc2UuIEJ1dCwgZm9yIHRoaXMNCkkt
RCwgSSB3YW50IHRvIGJlIHN1cmUgdG8gY292ZXIgYWxsIGFzcGVjdHMsIGhlbmNlIHRoZSBtb2Rp
ZmllZCBzZW50ZW5jZQ0KDQotw6lyaWMNCg0KT24gMTgvMDQvMTUgMDM6NDYsICJGcmVkIEJha2Vy
IChmcmVkKSIgPGZyZWRAY2lzY28uY29tPiB3cm90ZToNCg0KPg0KPj4gT24gQXByIDE3LCAyMDE1
LCBhdCAzOjE3IFBNLCBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgPGV2eW5ja2VAY2lzY28uY29tPg0K
Pj53cm90ZToNCj4+IA0KPj4gWW91ciBwcm9wb3NhbCBpcyBmaW5lIGZvciBtZSwgYnV0LCBJIHdv
dWxkIHN1Z2dlc3QgYSBzbGlnaHRseSBzdHJvbmdlcg0KPj4gdGV4dDoNCj4+ICJUaGUgcmVzdWx0
cyBwcmVzZW50ZWQgaW4gdGhpcyBkb2N1bWVudCBpbmRpY2F0ZSB0aGF0IGluIHRoZSBzY2VuYXJp
b3MNCj4+IHdoZXJlIHRoZSBjb3JyZXNwb25kaW5nIG1lYXN1cmVtZW50cyB3ZXJlIHBlcmZvcm1l
ZCwgdGhlIHVzZSBvZiBJUHY2DQo+PiBleHRlbnNpb24gaGVhZGVycyBjYW4gbGVhZCB0byBwYWNr
ZXQgZHJvcHMuIFdlIG5vdGUgdGhhdA0KPj4gcGFja2V0IGRyb3BzIG9jY3VycmluZyBhdCB0cmFu
c2l0IG5ldHdvcmtzIGlzIHVuZGVzaXJhYmxlDQo+PiBhbmQgaXQgaXMgaG9wZWQgYW5kIGV4cGVj
dGVkIHRoYXQgdGhpcyBzaXR1YXRpb24gd2lsbCBpbXByb3ZlIG92ZXINCj4+dGltZS4iDQo+PiAN
Cj4+IFNob3VsZCB3ZSBzYXkgc29tZXRoaW5nIGFyb3VuZCB0aGUgbGluZXMgb2YgIi4uLiBVbmRl
c2lyYWJsZSBleGNlcHQgd2hlbg0KPj4gVGhvc2UgcGFja2V0cyBjYW5ub3QgYmUgZm9yd2FyZGVk
IHdpdGhvdXQgaW1wYWN0aW5nIHRoZSBwZXJmb3JtYW5jZSBhbmQNCj4+IHRoZSBoZWFsdGggb2Yg
dGhlIG5ldHdvcmsgZGV2aWNlcyIgPw0KPg0KPldlbGwsIHF1ZXN0aW9uIGZvciB5b3UuIElmIHdl
IGZvbGxvdyBSRkMgMjQ2MCwgdGhlIHJvdXRlciBpbiB0aGUgbWlkZGxlDQo+ZG9lc27igJl0IGtu
b3cgd2hldGhlciB0aGUgaGVhZGVyIGlzIHRoZXJlIG9yIG5vdC4gVGhlIG9ubHkgc3lzdGVtcyB0
aGF0DQo+c2hvdWxkIGhhdmUgYSBwZXJmb3JtYW5jZSBpbXBhY3QgYXJlIHN5c3RlbXMgdGhhdCBw
YXJzZSB0byB0aGVtIG9yDQo+aW50ZXJwcmV0IHRoZW0uIEkgcGVyc29uYWxseSB3b3VsZCBsaWtl
IHRvIGJlbGlldmUgdGhhdCB3ZSBhcmVu4oCZdCBtYWtpbmcNCj4qb3RoZXIqIHN5c3RlbXMgbW9y
ZSBjb21wbGV4IHRvIHNhdmUgdGhlbS4gSWYgdGhpcyBpcyBiZWluZyBkb25lIGluIGENCj5maXJl
d2FsbCBvciBsb2FkIGJhbGFuY2VyLCB0aGUgbGltaXRhdGlvbnMgb2YgdGhlIGRldmljZSBhcmVu
4oCZdCBwcmltYXJ5LA0KPnRoZSBjb3JyZWN0IG9wZXJhdGlvbiBvZiB0aGUgcHJvdG9jb2wgaXMu
IFdvdWxkIHdlIGJlIHNheWluZyB0aGF0IGl04oCZcyBPSw0KPmZvciBhIGZpcmV3YWxsIHRvIGRy
b3AgYSBwYWNrZXQgYmVjYXVzZSBpdCBkb2VzbuKAmXQgZmVlbCBsaWtlIGRlYWxpbmcgd2l0aA0K
Pml0IHRoYXQgZGF5Pw0KPg0KPldoYXQgc3BlY2lmaWMgZGV2aWNlcyBkaWQgeW91IGhhdmUgaW4g
bWluZD8gV2hhdCB3b3VsZCB0aGUgYXJndW1lbnQgYmU/DQoNCg==


From nobody Sat Apr 18 04:23: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 D51281A6F29 for ; Sat, 18 Apr 2015 04:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gi3B52GuWeku for ; Sat, 18 Apr 2015 04:23:20 -0700 (PDT)
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 B95E31A6F17 for ; Sat, 18 Apr 2015 04:23:19 -0700 (PDT)
X-Envelope-To: 
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:0:0:0:110]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t3IBNGsE078125 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Apr 2015 12:23:17 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:110] claimed to be cupcake.foobar.org
Message-ID: <55323EA4.3090107@foobar.org>
Date: Sat, 18 Apr 2015 12:23:16 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: v6ops@ietf.org
References: <552CD2CE.3070801@si6networks.com>  <41AF40EF-C4CB-41F7-8BC4-567A02A49FF4@cisco.com>
In-Reply-To: <41AF40EF-C4CB-41F7-8BC4-567A02A49FF4@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Apr 2015 11:23:22 -0000

On 18/04/2015 02:46, Fred Baker (fred) wrote:
> Well, question for you. If we follow RFC 2460, the router in the middle
> doesn’t know whether the header is there or not. The only systems that
> should have a performance impact are systems that parse to them or
> interpret them. 

layer 4 information is routinely parsed to extract n-tuples in order to
create lag / ecmp hashes for load balancing.  I.e. we have a requirement
for routers to interpret ipv6 packet headers on a per-hop basis, and make
consistent routing decisions based on this analysis.

Nick


From nobody Sat Apr 18 13:20: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 5E8331A8ABA for ; Sat, 18 Apr 2015 13:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIqPGvqCw31w for ; Sat, 18 Apr 2015 13:20:52 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 EF4B51A8AB2 for ; Sat, 18 Apr 2015 13:20:51 -0700 (PDT)
Received: by pacyx8 with SMTP id yx8so162409556pac.1 for ; Sat, 18 Apr 2015 13:20:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/U/DBvXt8npA9PYS7W2cjUXFgbZssaOK/cdDr9kahOM=; b=FhYuisvRSY4pPTuU6VGoHTzmLEJ6qR5WLkmGNmq8uiSSzDX+OIjgJw3unD6sk1gqjo VuiO57wC8EqHLBDgL3Df/Tn2S5EBxQ+QOWsaB4U2zAtFCqM7mYAx400ls78k0kyZvmOh hvK9Qn8WMPfTQqK3TL1TgvAmgrzvQB/Fez1OxhHQqgzBY3MOoyuhDvMA09q5OvcfnllO GX+fwPTfdFgZGTYLSXu3VcL+ew3c+lPAfJVzhD038CYMWOs6+W3tRmLbV9Cw/q/8lOZo YSXzrSHD0t6yDSEyP9ZKIkbHWfsxyDWm3H2/4sK5QbTAPdNekP+v+LdyiTaZnzZO8zur lV1Q==
X-Received: by 10.66.65.130 with SMTP id x2mr15344828pas.152.1429388451676; Sat, 18 Apr 2015 13:20:51 -0700 (PDT)
Received: from ?IPv6:2406:e007:7f27:1:28cc:dc4c:9703:6781? ([2406:e007:7f27:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id sl9sm13778444pac.41.2015.04.18.13.20.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Apr 2015 13:20:50 -0700 (PDT)
Message-ID: <5532BC9C.20600@gmail.com>
Date: Sun, 19 Apr 2015 08:20:44 +1200
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.6.0
MIME-Version: 1.0
To: "Eric Vyncke (evyncke)" ,  "Fred Baker (fred)" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Fernando Gont , "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Apr 2015 20:20:54 -0000

On 18/04/2015 17:58, Eric Vyncke (evyncke) wrote:
> Fred,
>=20
> The performance impact/network health issues are mainly related to
> hop-by-hop which is per RFC 2460 inspected by every router on the path.=

> This EH should be ignore IMHO by all routers over the Internet (private=

> networks may still inspect/act on it for RSVP for examine).

With a slight sigh:

We explicitly covered this in RFC 7045, which updated RFC 2460 in 2013.
http://tools.ietf.org/html/rfc7045#section-2.2

IMHO we should not be messing with that (or other) standards track
statements in this Informational document.

On 18/04/2015 23:23, Nick Hilliard wrote:

> On 18/04/2015 02:46, Fred Baker (fred) wrote:
>> Well, question for you. If we follow RFC 2460, the router in the middl=
e
>> doesn=E2=80=99t know whether the header is there or not. The only syst=
ems that
>> should have a performance impact are systems that parse to them or
>> interpret them.=20
>=20
> layer 4 information is routinely parsed to extract n-tuples in order to=

> create lag / ecmp hashes for load balancing.  I.e. we have a requiremen=
t
> for routers to interpret ipv6 packet headers on a per-hop basis, and ma=
ke
> consistent routing decisions based on this analysis.

Again, we have hashed over this (pun intended) in the past and the conclu=
sions
are in RFC 7045, RFC 6564 and for that matter in RFC 6438 and RFC 7098.

Badsically the design of the extension header mechanism is unfriendly to
middleboxes, which is one reason that I have been trying to make the flow=

label useful.

    Brian


From nobody Sat Apr 18 18:15:37 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 15C6E1ACDB9 for ; Sat, 18 Apr 2015 18:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level: 
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8CEYSkaF6ju for ; Sat, 18 Apr 2015 18:15:35 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535301ACDB8 for ; Sat, 18 Apr 2015 18:15:35 -0700 (PDT)
Received: (qmail 1090 invoked from network); 18 Apr 2015 18:03:44 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2015 18:03:44 -0700
Date: Sat, 18 Apr 2015 18:03:44 -0700 (PDT)
From: "C. M. Heard" 
X-X-Sender: heard@shell4.bayarea.net
To: Alexandru Petrescu 
In-Reply-To: <55310176.4080203@gmail.com>
Message-ID: 
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com> <20150407123653.GS54385@Space.Net> <55310176.4080203@gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Apr 2015 01:15:36 -0000

On Fri, 17 Apr 2015, Alexandru Petrescu wrote:
> In a particular network I am connecting to, an intervening router sends
> back an ICMPv6 Parameter Problem with a Pointer field pointing to the
> type Home Address of a Destination Options extension header (EH) of a
> Binding Update of protocol Mobile IPv6.
> 
> Intuitively, that suggests that the router complaining of that EH may be
> old, not updated to understand Mobile IPv6 (although the MIP spec is
> there for many years and many commercial and oss implementations are out
> there since long).
> 
> This EH is absolutely necessary to exist in real world to offer the
> mobility part of IPv6.  Filtering it consciously does not avoid security
> risks (there aren't for MIP non-RO).   It must be allowed.

The obvious question to ask is why in the world an intervening 
router is inspecting stuff inside the Destination Options header in 
the first place (clearly, it has to inspecting the options in order 
to generate an ICMPv6 Parameter Problem with a Pointer field 
pointing to a specific option).  It is hard to see how Destination 
Options (of any kind) would affect the security of the router or of 
the transit network.  If the router imply ignored the header, as 
it's supposed to do (per RFC 7045), then it would not need to be 
updated to recognize new DOs.

//cmh


From nobody Sat Apr 18 18:19: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 B21641ACDC0 for ; Sat, 18 Apr 2015 18:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jPUYI3cC3G5 for ; Sat, 18 Apr 2015 18:19:34 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F771ACDBF for ; Sat, 18 Apr 2015 18:19:34 -0700 (PDT)
Received: (qmail 2117 invoked from network); 18 Apr 2015 18:07:43 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2015 18:07:42 -0700
Date: Sat, 18 Apr 2015 18:07:42 -0700 (PDT)
From: "C. M. Heard" 
X-X-Sender: heard@shell4.bayarea.net
To: v6ops 
In-Reply-To:  <5532BC9C.20600@gmail.com>
Message-ID: 
References: <552CD2CE.3070801@si6networks.com>  <41AF40EF-C4CB-41F7-8BC4-567A02A49FF4@cisco.com>  <5532BC9C.20600@gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: 
Cc: Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 Apr 2015 01:19:34 -0000

On Fri, 17 Apr 2015, Eric Vyncke (evyncke) wrote:
> I would suggest a slightly stronger text:
> "The results presented in this document indicate that in the scenarios
> where the corresponding measurements were performed, the use of IPv6
> extension headers can lead to packet drops. We note that
> packet drops occurring at transit networks [are] undesirable
> and it is hoped and expected that this situation will improve over time."

I concur with this proposal (modulo correction in square brackets).  
It is consistent with RFC 7045, which reaffirms that intermediate 
nodes SHOULD process extension headers as described in RFC 2460 
(i.e., act upon the options in a Hop-by-Hop Options extension header 
and ignore all other extension headers).

> Should we say something around the lines of "... Undesirable except when
> Those packets cannot be forwarded without impacting the performance and
> the health of the network devices" ?

No.  From the standpoint of the user of the general internet, such 
drops by transit providers are never desirable.  They may in some 
cases be a practical necessity (e.g., due to inability to process 
Hop-by-Hop Options at wire speed), but they are still undesirable.

On Sun, 19 Apr 2015, Brian E Carpenter wrote:
> IMHO we should not be messing with that (or other) standards track
> statements in this Informational document.

Exactly.

//cmh


From nobody Sat Apr 18 20:50: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 3BCCA1ACEF3 for ; Sat, 18 Apr 2015 20:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.102
X-Spam-Level: *
X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, 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 AVhwm628vXVi for ; Sat, 18 Apr 2015 20:50:33 -0700 (PDT)
Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3D61ACEF2 for ; Sat, 18 Apr 2015 20:50:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429415432; bh=anL0estBkuF1LQr1JjgGgvtJQSl9oqymY37XYj+yX6A=;  h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject;  b=j7GprcNedbjuH+Sc9PEK0M+8eI68ZsE2cHSS6er+azLwsX5tOvnE+d5DAWe4Eu5iinhfDCHrEuyTiR+LBXwf+/6W0dgYfOBrpyLAuyHfWJuIyaTM301BjAsOdOFXrQAwz7QY3oMHlGRA+e62JV15S1Wtl0/nV4afiRo24jsES7TR7XLM0m4zWVgrCxva6vCv/ssGgaYErw8kk/tkd5FiPfBRnjWXSQmBJ+WqrpDOAsdpxv9HXpraoH4UvTZuoTFBIhF2L1rjc1cHrnqkhqDFxM89qAjh7fmeh3PCG0vCvbmicapysOzAT06o8eLNVkI4+v3OMHijp/i4Ey4OY0dPVQ==
Received: from [98.139.170.178] by nm34.bullet.mail.bf1.yahoo.com with NNFMP;  19 Apr 2015 03:50:32 -0000
Received: from [98.139.212.247] by tm21.bullet.mail.bf1.yahoo.com with NNFMP;  19 Apr 2015 03:50:32 -0000
Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 19 Apr 2015 03:50:32 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 881193.60252.bm@omp1056.mail.bf1.yahoo.com
X-YMail-OSG: h5tI8Q4VM1lf9NGoMkQfMxIgItH6h3by2QQFMBqaddTgT61aeAutjjZLScpJnVa v.vHWafHWbD4oBBQYFZu42La_8te837uwP7w.ZwSVBoHAkUsDC.gu9Is6_xl7GOg5QKdDkedw6xk e.6eDj7guUmH64RST24NJg0VHHv736EbFS3d_.iYcU20H9LEDvn4gRg14bM1f.jIiiabkcY3UqNS u_h14YUt2OXj_q52KXcnnfZAbDc1No78a4dteU3RSzwAwyjhvu7_0qhNf7tK5tEn8VfeypJKWrbS DI8RiAy7T5HEq6EDU7PZphbguCkGsXGhhryL5W1kuEQDDGmxK9eaZGUN9RDmek09Nu9f6Bf56zy6 clGB4M84l7FJL0pqwdOPZSqmnbucFGKXik5IipqFsPgBLlDwYrk4gD5N6GvHrsWDTeSZ3RNtIsb3 SyF.Nkx3EwMb9VwicTBd1fg7XXevliLrjix.Mv8Ka43UbPhChNbRiXfYXf8BCX.2EZHLDaF7nzhr FjlnPnQzvbflb6WmYBvfxNDlSvJlINJj911to3kOF6e5c2UEieg--
Received: by 76.13.26.107; Sun, 19 Apr 2015 03:50:32 +0000 
Date: Sun, 19 Apr 2015 03:50:26 +0000 (UTC)
From: Mark ZZZ Smith 
To: Nick Hilliard , "v6ops@ietf.org" 
Message-ID: <655424915.7147538.1429415426039.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <55323EA4.3090107@foobar.org>
References: <55323EA4.3090107@foobar.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_7147536_986443055.1429415426035"
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
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, 19 Apr 2015 03:50:35 -0000

------=_Part_7147536_986443055.1429415426035
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: Nick Hilliard 
 To: v6ops@ietf.org=20
 Sent: Saturday, 18 April 2015, 21:23
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarificatio=
n text
  =20
On 18/04/2015 02:46, Fred Baker (fred) wrote:
> Well, question for you. If we follow RFC 2460, the router in the middle
> doesn=E2=80=99t know whether the header is there or not. The only systems=
 that
> should have a performance impact are systems that parse to them or
> interpret them.=20

layer 4 information is routinely parsed to extract n-tuples in order to
create lag / ecmp hashes for load balancing.=C2=A0 I.e. we have a requireme=
nt
for routers to interpret ipv6 packet headers on a per-hop basis, and make
consistent routing decisions based on this analysis.

/ That is what the flow label is for, and we should be encouraging vendors =
of both host OSes and devices which perform LAG/ECMP to be setting/using it=
 for that purpose. Support for the use of it this way is in the current IPv=
6 node requirements RFC from 2011 (RFC6424).
/ Although it is disabled by default, the Linux kernel has supported automa=
tic generation of flow label values since around August 2014 (sysctl net.ip=
v6.auto_flowlabels=3D1 to enable).
/ Regards,mark.

Nick



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

  
------=_Part_7147536_986443055.1429415426035
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



   
 
 
   From: Nick Hilliard <nick@foobar.org>
 To: v6ops@ietf.org 
 Sent: Saturday, 18 April 2015, 21=
:23
 Subject: Re: [v6op=
s] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
  =

 

On 18/04/2015 02:46, Fred Baker (fred) wrote:
> Well, question for you. If we follow RFC 2460, the router in=
 the middle
> doesn=E2=80=99t know whether the header =
is there or not. The only systems that
> should have a=
 performance impact are systems that parse to them or
>=
; interpret them. 

layer 4 information=
 is routinely parsed to extract n-tuples in order to
crea=
te lag / ecmp hashes for load balancing.  I.e. we have a requirementfor routers to interpret ipv6 packet headers on a per-hop =
basis, and make
consistent routing decisions based on thi=
s analysis.

/ That is what the flow label is for, and=
 we should be encouraging vendors of both host OSes and devices which perfo=
rm LAG/ECMP to be setting/using it for that purpose. Support for the use of=
 it this way is in the current IPv6 node requirements RFC from 2011 (RFC642=
4).

/ Although it is disabled by default, th=
e Linux kernel has supported automatic generation of flow label values sinc=
e around August 2014 (sysctl net.ipv6.auto_flowlabels=3D1 to enable).
=


/ Regards,
mark.

<=
/div>

Nick




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

 
 
  

------=_Part_7147536_986443055.1429415426035--


From nobody Sun Apr 19 04:16:59 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 40B721AC3C0 for ; Sun, 19 Apr 2015 04:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXYugwWTAdVK for ; Sun, 19 Apr 2015 04:16:47 -0700 (PDT)
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 17FB51A1BF5 for ; Sun, 19 Apr 2015 04:16:46 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:0:0:0:110]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t3JBGhsv007206 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Apr 2015 12:16:44 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:110] claimed to be cupcake.foobar.org
Message-ID: <55338E9B.1080606@foobar.org>
Date: Sun, 19 Apr 2015 12:16:43 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Mark ZZZ Smith , "v6ops@ietf.org" 
References: <55323EA4.3090107@foobar.org> <655424915.7147538.1429415426039.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <655424915.7147538.1429415426039.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 Apr 2015 11:16:58 -0000

On 19/04/2015 04:50, Mark ZZZ Smith wrote:
> / That is what the flow label is for, and we should be encouraging vendors
> of both host OSes and devices which perform LAG/ECMP to be setting/using it
> for that purpose. Support for the use of it this way is in the current IPv6
> node requirements RFC from 2011 (RFC6424).
> 
> / Although it is disabled by default, the Linux kernel has supported
> automatic generation of flow label values since around August 2014 (sysctl
> net.ipv6.auto_flowlabels=1 to enable).

yes, the flow label will help as one entry in the hash n-tuple but it would
be unwise to depend on this as the only hash entropy source.  L3+L4 header
information is still a better determinant.  It always surprised me that the
flow label has been part of the ipv6 spec since the very earliest
discussions in 1993, but that it wasn't present in the linux kernel until
very recently and even then, only as a non-default option.

Nick



From nobody Sun Apr 19 14:17: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 EAF361A875B for ; Sun, 19 Apr 2015 14:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.283
X-Spam-Level: 
X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 cbPjsxE-t-Lq for ; Sun, 19 Apr 2015 14:17:27 -0700 (PDT)
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 0FF661A8748 for ; Sun, 19 Apr 2015 14:17:26 -0700 (PDT)
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 t3JLHOFY009816; Sun, 19 Apr 2015 23:17:24 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D5D59201B1C; Sun, 19 Apr 2015 23:18:44 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C855D200C04; Sun, 19 Apr 2015 23:18:44 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.84.76]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t3JLHHf3024439; Sun, 19 Apr 2015 23:17:23 +0200
Message-ID: <55341B5D.4020408@gmail.com>
Date: Sun, 19 Apr 2015 23:17:17 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "C. M. Heard" 
References: <52C91C37-7214-4EFD-A0DD-F0842CB45D2E@merike.com>  <1E9D679E-2EF3-47FC-941A-EBA13162E2FA@merike.com>  <5515628D.7020306@gmail.com> <237B7808-F457-42FE-9298-53E9181358E8@cisco.com> <55161E85.8020806@gmail.com> <5523A0D7.2010509@gmail.com> <20150407093213.GJ54385@Space.Net> <5523AC2F.6070802@gmail.com> <20150407123653.GS54385@Space.Net> <55310176.4080203@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] why IPv6 EHs in the Real World
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Apr 2015 21:17:29 -0000

Le 19/04/2015 03:03, C. M. Heard a écrit :
> On Fri, 17 Apr 2015, Alexandru Petrescu wrote:
>> In a particular network I am connecting to, an intervening router
>> sends back an ICMPv6 Parameter Problem with a Pointer field
>> pointing to the type Home Address of a Destination Options
>> extension header (EH) of a Binding Update of protocol Mobile IPv6.
>>
>> Intuitively, that suggests that the router complaining of that EH
>> may be old, not updated to understand Mobile IPv6 (although the
>> MIP spec is there for many years and many commercial and oss
>> implementations are out there since long).
>>
>> This EH is absolutely necessary to exist in real world to offer the
>> mobility part of IPv6.  Filtering it consciously does not avoid
>> security risks (there aren't for MIP non-RO).   It must be
>> allowed.
>
> The obvious question to ask is why in the world an intervening
> router is inspecting stuff inside the Destination Options header in
> the first place (clearly, it has to inspecting the options in order
> to generate an ICMPv6 Parameter Problem with a Pointer field pointing
> to a specific option).  It is hard to see how Destination Options
> (of any kind) would affect the security of the router or of the
> transit network.  If the router imply ignored the header, as it's
> supposed to do (per RFC 7045), then it would not need to be updated
> to recognize new DOs.

I agree with you.

It is not normal for an intermediate router to look at anything else
than the Base Header and at the Routing Header.  It should not look at
the Destinations Options header - that is for the destination only (the
computer owning the dst address).

I can guess why it looks at it.   It is because in IPv4 there is no such
distinction between headers and extension headers.  An IPv4 router would
look at everything preceding the payload, and thus an IPv6 port would do
the same.  It's just a guess, I may be wrong.

Alex

>
> //cmh
>



From nobody Mon Apr 20 04:52: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 63E501B2B14 for ; Mon, 20 Apr 2015 04:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.502
X-Spam-Level: 
X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 F-xFHL-9WTtN for ; Mon, 20 Apr 2015 04:52:11 -0700 (PDT)
Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD271B2B10 for ; Mon, 20 Apr 2015 04:52:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429530730; bh=WDTfhGGTaINkuM5aqHxckPUlJdUGYFOeT4YdW0LnZNc=;  h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject;  b=dEd36lzzAkz251dxw8n4szpUFtdQkKLGaxJaVQpvFzqSQzQSSVDV+Pa3AueP7wtfic01uY7eE2iEaHkYwljPubc6jdR9QZMLNp4B6sKHenO5pXIycrlpWtqRv6cXtIlX+Qv+8winopcRFvl9Q1TuT8o8v8zhRBUMXsiRrfEvcdTr1Xxk0rOdzIDgNDK/VRlbTyhcP9cBZrddy9h4Um42KTnOdXDsriA43m6/2LKPhwyBRBRf0sIbAM5NutJLTa1wO6/JX2j+w5jJszveyOFEaFjeZ94+H7SNpluccJJshaQJuw6vtnytwQoZU/FWSTEOJ73GTO/gmDPo6X6yhEzOuw==
Received: from [98.139.215.142] by nm28.bullet.mail.bf1.yahoo.com with NNFMP;  20 Apr 2015 11:52:10 -0000
Received: from [98.139.212.194] by tm13.bullet.mail.bf1.yahoo.com with NNFMP;  20 Apr 2015 11:52:10 -0000
Received: from [127.0.0.1] by omp1003.mail.bf1.yahoo.com with NNFMP; 20 Apr 2015 11:52:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 387818.99607.bm@omp1003.mail.bf1.yahoo.com
X-YMail-OSG: 6VO4vMgVM1nf5zfCMHgH11MuF1NvsyV_CstyqB3SihIloafUESaoGCgOtvMhXa5 NCTD21YL05B0pZzjXVzUNyaWMGGTwlZj.ClFAUul2TCInjnLPjVRxDDdYsKx_dCa2bcUJLyO4Xiq pSR5LDWGLZoLWFBjFXxdfwgkHxTqw2JH5T.nd81MDzt3y3ZPWaD1zr7oepopS4OaqOq8VQ_hOBUT qv2vUO2DdQPfU23KD__enHm6eZ0TknBOYttiK6PboDxQPh81S1RpwQ.nI.sVZggo1A_Mfjsy7vSN fBKpSUrbOhISeAubOMAOF_BocUtpA7nNkrmEM_yScRt0UZiqVjFcRM0MBiVKx2k5diMipTRIOAgE Te70qBVVABPzA2vOBA4qHRmsltUnQz9z6EnQfOGe0WHY04oWO_M4mmeFgqvdm0vjMF8i_fUR60Ec UTlaJQdgeNJXTYjMOPIhFFkjPJ3AMtlD0_tS5PcyUpNQY6GRwdBEynIN9SXUvFor8_5BAIIDN3Il DiEkOk7jjsCV1lbTid6YGv1R5o6H3ksbld5kyH18ZWnnd3rGQ
Received: by 76.13.27.69; Mon, 20 Apr 2015 11:52:09 +0000 
Date: Mon, 20 Apr 2015 11:52:09 +0000 (UTC)
From: Mark ZZZ Smith 
To: Nick Hilliard , "v6ops@ietf.org" 
Message-ID: <627100572.313590.1429530729338.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <55338E9B.1080606@foobar.org>
References: <55338E9B.1080606@foobar.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_313589_213492397.1429530729333"
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
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, 20 Apr 2015 11:52:12 -0000

------=_Part_313589_213492397.1429530729333
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: Nick Hilliard 
 To: Mark ZZZ Smith ; "v6ops@ietf.org" =20
 Sent: Sunday, 19 April 2015, 21:16
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarificatio=
n text
  =20
On 19/04/2015 04:50, Mark ZZZ Smith wrote:
> / That is what the flow label is for, and we should be encouraging vendor=
s
> of both host OSes and devices which perform LAG/ECMP to be setting/using =
it
> for that purpose. Support for the use of it this way is in the current IP=
v6
> node requirements RFC from 2011 (RFC6424).
>=20
> / Although it is disabled by default, the Linux kernel has supported
> automatic generation of flow label values since around August 2014 (sysct=
l
> net.ipv6.auto_flowlabels=3D1 to enable).

yes, the flow label will help as one entry in the hash n-tuple=C2=A0but it =
would
be unwise to depend on this as the only hash entropy source.
/ The RFC updating the flow label specification says that at a minimum it s=
hould be a 3 tuple of SA, DA and uniformly distributed flow label value.

=C2=A0 L3+L4 header
information is still a better determinant.
/ Layer 4 headers aren't good because they may not be directly behind the I=
Pv6 header (as they might have been in IPv4 too because of options) and TCP=
 and UDP aren't the only protocols you might want load distributed.
=C2=A0 It always surprised me that the
flow label has been part of the ipv6 spec since the very earliest
discussions in 1993, but that it wasn't present in the linux kernel until
very recently and even then, only as a non-default option.


/ I think applications being able to set the flow label value if they choos=
e to has been available for a very long time, the thing that is much more r=
ecent is automatic label generation.

Nick




  
------=_Part_313589_213492397.1429530729333
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



   
 
 
   From: Nick Hilliard <nick@foobar.org>
 To: Mark ZZZ Smith <markzzzsmith@=
yahoo.com.au>; "v6ops@ietf.org" <v6ops@ietf.org> 
 Sent: Sunday, 19 April 2015, 21:16
=
 Subject: Re: [v6ops] draf=
t-gont-v6ops-ipv6-ehs-in-real-world: clarification text
  
 =


=
On 19/04/2015 04:50, Mark ZZZ Smith wrote:
> / That is=
 what the flow label is for, and we should be encouraging vendors
> of both host OSes and devices which perform LAG/ECMP to be s=
etting/using it
> for that purpose. Support for the us=
e of it this way is in the current IPv6
> node require=
ments RFC from 2011 (RFC6424).
> 
&g=
t; / Although it is disabled by default, the Linux kernel has supported
> automatic generation of flow label values since around =
August 2014 (sysctl
> net.ipv6.auto_flowlabels=3D1 to =
enable).

yes, the flow label will help=
 as one entry in the hash n-tuple
 but it would
be unwise to d=
epend on this as the only hash entropy source.

/ The RFC updating th=
e flow label specification says that at a minimum it should be a 3 tuple of=
 SA, DA and uniformly distributed flow label value.

  L3+L4=
 header
information is still a better determinant.
<=
div class=3D"y_msg_container" id=3D"yui_3_16_0_1_1429529605475_12197">
<=
/div>
/ Layer 4 headers aren't good because they may not be directly=
 behind the IPv6 header (as they might have been in IPv4 too because of opt=
ions) and TCP and UDP aren't the only protocols you might want load distrib=
uted.

  It always surprised me that the
flow =
label has been part of the ipv6 spec since the very earliest
discussions in 1993, but that it wasn't present in the linux kernel unt=
il
very recently and even then, only as a non-default opt=
ion.



/ I think applications being able to set the flow label value =
if they choose to has been available for a very long time, the thing that i=
s much more recent is automatic label generation.

Nick



 
 
  
------=_Part_313589_213492397.1429530729333--


From nobody Mon Apr 20 08:40: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 508611B2F12 for ; Mon, 20 Apr 2015 08:40:29 -0700 (PDT)
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 pbdy2mTa9HeH for ; Mon, 20 Apr 2015 08:40:28 -0700 (PDT)
Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D99F1B2F0E for ; Mon, 20 Apr 2015 08:40:27 -0700 (PDT)
Received: from [192.168.1.3] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3KFdtwC023733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 08:40:10 -0700 (PDT)
Message-ID: <55351DCB.7080706@isi.edu>
Date: Mon, 20 Apr 2015 08:39:55 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Eric Vyncke (evyncke)" , Fernando Gont , Merike Kaeo , "v6ops@ietf.org" 
References: <552CD2CE.3070801@si6networks.com> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 20 Apr 2015 15:40:29 -0000

On 4/17/2015 12:17 AM, Eric Vyncke (evyncke) wrote:
...
> Should we say something around the lines of "... Undesirable except when
> Those packets cannot be forwarded without impacting the performance and
> the health of the network devices" ?



Absolutely - it's entirely unreasonable to expect vendors to support the
protocols they claim, when to do so would impact their profits.



Joe


From nobody Mon Apr 20 08:44: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 1D2581B2F1D for ; Mon, 20 Apr 2015 08:44:26 -0700 (PDT)
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 UpJ4Agssa8s8 for ; Mon, 20 Apr 2015 08:44:25 -0700 (PDT)
Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2A61B2F1F for ; Mon, 20 Apr 2015 08:44:25 -0700 (PDT)
Received: from [192.168.1.3] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3KFhS0J025112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 08:43:37 -0700 (PDT)
Message-ID: <55351EA0.2010700@isi.edu>
Date: Mon, 20 Apr 2015 08:43:28 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Eric Vyncke (evyncke)" , "Fred Baker (fred)" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: Fernando Gont , "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 20 Apr 2015 15:44:26 -0000

On 4/17/2015 10:58 PM, Eric Vyncke (evyncke) wrote:
> If for some reasons, a router in the middle needs access to layer-4
                                              ^^^^^
> information (IPFIX? DDoS mitigation? ... ?), then the EH chain must be
> parsed which can cause a performance impact.

Let's be clear - "wants" access.

If that's what you want, then that's what you have to pay for (for the
vendor, in complexity to parse the packet to find the L4 header; for the
customer, in price).

But two things ought to be made clear:

	1) this is the router vendor's decision, not a requirement
	of Internet routers

	2) this might not even be worthwhile as we move to more
	secure protocols

Joe


From nobody Mon Apr 20 14:21: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 993701B3211 for ; Mon, 20 Apr 2015 14:21:30 -0700 (PDT)
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 rhz_wqEN3DMd for ; Mon, 20 Apr 2015 14:21:28 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74651A1B22 for ; Mon, 20 Apr 2015 14:21:28 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 554CD62917 for ; Mon, 20 Apr 2015 23:21:26 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 09DEE60934 for ; Mon, 20 Apr 2015 23:21:26 +0200 (CEST)
Received: (qmail 31380 invoked by uid 1007); 20 Apr 2015 23:21:25 +0200
Date: Mon, 20 Apr 2015 23:21:25 +0200
From: Gert Doering 
To: Joe Touch 
Message-ID: <20150420212125.GE54385@Space.Net>
References:  <55351EA0.2010700@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55351EA0.2010700@isi.edu>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 20 Apr 2015 21:21:30 -0000

Hi,

On Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
> > If for some reasons, a router in the middle needs access to layer-4
>                                               ^^^^^
> > information (IPFIX? DDoS mitigation? ... ?), then the EH chain must be
> > parsed which can cause a performance impact.
[..]
> 	1) this is the router vendor's decision, not a requirement
> 	of Internet routers

So, please tell me how you build an Internet router that is able to
defend itself against control plane abuse and does not need to look into
L4 to do so?

Building a router that doesn't do ACLs and control-plane rate limiting
is easy, but totally useless in today's Internet...

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 Mon Apr 20 14:28:52 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 9FAFC1B323B for ; Mon, 20 Apr 2015 14:28:49 -0700 (PDT)
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 BjGYYN_S7acT for ; Mon, 20 Apr 2015 14:28:48 -0700 (PDT)
Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974661B3239 for ; Mon, 20 Apr 2015 14:28:48 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3KLS99X006334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 14:28:11 -0700 (PDT)
Message-ID: <55356F68.1020605@isi.edu>
Date: Mon, 20 Apr 2015 14:28:08 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Gert Doering 
References:  <55351EA0.2010700@isi.edu> <20150420212125.GE54385@Space.Net>
In-Reply-To: <20150420212125.GE54385@Space.Net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 20 Apr 2015 21:28:49 -0000

On 4/20/2015 2:21 PM, Gert Doering wrote:
> Hi,
> 
> On Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
>>> If for some reasons, a router in the middle needs access to layer-4
>>                                               ^^^^^
>>> information (IPFIX? DDoS mitigation? ... ?), then the EH chain must be
>>> parsed which can cause a performance impact.
> [..]
>> 	1) this is the router vendor's decision, not a requirement
>> 	of Internet routers
> 
> So, please tell me how you build an Internet router that is able to
> defend itself against control plane abuse and does not need to look into
> L4 to do so?

A router can protect its own control plane by looking at the packet
contents, but then it is acting as a host at that point and should be
looking there only for packets addressed to interfaces of that router.
That's not a forwarding function and thus doesn't limit the forwarding
plane.

It is not a requirement that one router protect the control planes of
other routers from abuse. That is a feature - and if you want to sell
that as a feature, your device should support doing so at rate.

Joe



From nobody Mon Apr 20 18:22: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 4FFFC1A01AA for ; Mon, 20 Apr 2015 18:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.502
X-Spam-Level: 
X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 BnEOy7SbNxhZ for ; Mon, 20 Apr 2015 18:22:49 -0700 (PDT)
Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C8E1A01A8 for ; Mon, 20 Apr 2015 18:22:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429579367; bh=7eXkdmRnyzjxM1ZSmg9hiXUJPGwvFR9xdRq86Zr9CqY=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=dnJPpi2aZvnRADi3R0047ORqFsVeJ8nuPcEWjFnRHt/j2F3OfeAduuY/OIUxGp0r38kyJ05qcetcBUotgJCTI0v1j/m5ovsw3Ft2/GVYdL9wrukLUIIgc5/vqMQm8/IDz0e9YJN/2hKr6ua/EBzhq26pWqDk+uFO7BZRwABKHRbyzTGXhQ+QCO8gLTK39V5ZWDXpfDaPNNyXR7uR3IYmswJn2/YVNqlSkqTPioKn/SIELayfPb7R48F59lPDxhOpK9EYVK2qlV4gIRycnbEcjk5SVqtvDrF7ePwesYOa7iC4RLxN1ijaCLYU1HHIdPzZa66GlKDgWiVDgqxUzKw0ww==
Received: from [98.139.170.178] by nm24.bullet.mail.bf1.yahoo.com with NNFMP;  21 Apr 2015 01:22:47 -0000
Received: from [98.139.212.243] by tm21.bullet.mail.bf1.yahoo.com with NNFMP;  21 Apr 2015 01:22:47 -0000
Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 21 Apr 2015 01:22:47 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 940060.75473.bm@omp1052.mail.bf1.yahoo.com
X-YMail-OSG: _LVKo_AVM1md7pTmVqfPA7VRF0tAHyARfLxQTg3ltaHaut95h4PiRe7yVLb3f41 mG80mOZkpDwBBuRFNwlDcpOIsF0LErZUN09TihXxedWpJyNKkTf_8RC1EYfsx124qpvKeEzORF.s yDYaBVruPuqHT5cL2un8.3UJVXZb0LmwY1f1758h3bqccgdEHKr_hLDPpGu5O6IVuuijBcsckmiB yEe6mbY93ZGbIu_x.xNeOVd3.KFp0xB_cyWiZVrc8VsG3ru8MCMfbNM2fbTgf2Nks8yFJqY52Tr8 .IhK7nChsPN8mDsj.ULn7tClcInpleFQE6uk1DHJzBj98e4F8kOLry7HxiI0xIfhAwjlrWTave2F B0XzxkxcaBm_VgJecWpZ7wMvfluDq4yGYN51YPfbpqHs0k0I8sRJgr08k5ntm0cPIXiMRxihjVC_ 04nEQeotppRL79n2WZ8qruq1_Ta1PRm5GlhRGJVi7B8y6IK.xAePOITrYZHKsy.Q3V7i0gC7Sb4h eHEXYq9_YdI45huGFEfhwOD4ZIg6z7sHvds81uV9Z8A--
Received: by 66.196.81.119; Tue, 21 Apr 2015 01:22:47 +0000 
Date: Tue, 21 Apr 2015 01:22:46 +0000 (UTC)
From: Mark ZZZ Smith 
To: Joe Touch , Gert Doering 
Message-ID: <1916486469.1036672.1429579366689.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <55356F68.1020605@isi.edu>
References: <55356F68.1020605@isi.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1036671_185083561.1429579366684"
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" , Merike Kaeo , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Apr 2015 01:22:50 -0000

------=_Part_1036671_185083561.1429579366684
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: Joe Touch 
 To: Gert Doering =20
Cc: "v6ops@ietf.org" ; Merike Kaeo ; "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; Fernando Gont =20
 Sent: Tuesday, 21 April 2015, 7:28
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarificatio=
n text
  =20


On 4/20/2015 2:21 PM, Gert Doering wrote:
> Hi,
>=20
> On Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
>>> If for some reasons, a router in the middle needs access to layer-4
>>=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 ^^^^^
>>> information (IPFIX? DDoS mitigation? ... ?), then the EH chain must be
>>> parsed which can cause a performance impact.
> [..]
>> =C2=A0=C2=A0=C2=A0 1) this is the router vendor's decision, not a requir=
ement
>> =C2=A0=C2=A0=C2=A0 of Internet routers
>=20
> So, please tell me how you build an Internet router that is able to
> defend itself against control plane abuse and does not need to look into
> L4 to do so?

A router can protect its own control plane by looking at the packet
contents, but then it is acting as a host at that point and should be
looking there only for packets addressed to interfaces of that router.
That's not a forwarding function and thus doesn't limit the forwarding
plane.

/ I agree with this. It is easy to forget that a "router" is in actually a =
packet router at the forwarding plane and a host at the control plane.

It is not a requirement that one router protect the control planes of
other routers from abuse. That is a feature - and if you want to sell
that as a feature, your device should support doing so at rate.


=C2=A0

Joe


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


  
------=_Part_1036671_185083561.1429579366684
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



   
 
 
   From: Joe Touch <touch@isi.edu>
 To: Gert Doering <gert@space.net&g=
t; 
Cc: "v6ops@ietf.org=
" <v6ops@ietf.org>; Merike Kaeo <merike@doubleshotsecurity.com>=
; "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <draft-gont-v=
6ops-ipv6-ehs-in-real-world@tools.ietf.org>; Fernando Gont <fgont@si6=
networks.com> 
 Sent: Tuesday, 21 April 2015, 7:28
 Su=
bject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clar=
ification text
  
 



On =
4/20/2015 2:21 PM, Gert Doering wrote:
> Hi,
> 
> On Mon, Apr 20, 2015 at 08:43:28AM -=
0700, Joe Touch wrote:
>>> If for some reasons, =
a router in the middle needs access to layer-4
>>&n=
bsp;                     =
                     =
;    ^^^^^
>>> information (IPFIX? DDoS mit=
igation? ... ?), then the EH chain must be
>>> p=
arsed which can cause a performance impact.
> [..]
>>     1) this is the router vendor's d=
ecision, not a requirement
>>     of=
 Internet routers
> 
> So, please=
 tell me how you build an Internet router that is able to
> defend itself against control plane abuse and does not need to look i=
nto
> L4 to do so?

A router can protect its own control plane by looking at the packet
contents, but then it is acting as a host at that point and sh=
ould be
looking there only for packets addressed to inter=
faces of that router.
That's not a forwarding function an=
d thus doesn't limit the forwarding
plane.

/ I agree with this. It is easy to forget that a "router" is in act=
ually a packet router at the forwarding plane and a host at the control pla=
ne.


It is not a requirement that one r=
outer protect the control planes of
other routers from ab=
use. That is a feature - and if you want to sell
that as =
a feature, your device should support doing so at rate.



<=
/div>
 

Joe


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


 
 =

  

------=_Part_1036671_185083561.1429579366684--


From nobody Mon Apr 20 22:25: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 910721B2DCF; Mon, 20 Apr 2015 22:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPiYeOXwvZx6; Mon, 20 Apr 2015 22:25:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 361B31B2DD5; Mon, 20 Apr 2015 22:25:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150421052519.18577.59023.idtracker@ietfa.amsl.com>
Date: Mon, 20 Apr 2015 22:25:19 -0700
Archived-At: 
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-cidr-prefix-02.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Apr 2015 05:25:37 -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-02.txt
	Pages           : 5
	Date            : 2015-04-20

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
   implementations of routing and forwarding 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-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-cidr-prefix-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Apr 20 22:29: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 B1C061B2DDF; Mon, 20 Apr 2015 22:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EFOKrOfgIUzB; Mon, 20 Apr 2015 22:29:00 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3401B2EA3; Mon, 20 Apr 2015 22:28:56 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0E5FB3B42AD; Tue, 21 Apr 2015 07:28:55 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DD56835C078; Tue, 21 Apr 2015 07:28:54 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0224.002; Tue, 21 Apr 2015 07:28:54 +0200
From: 
To: "Black, David" 
Thread-Topic: Gen-ART review of draft-ietf-v6ops-cidr-prefix-01
Thread-Index: AdB7xV84EgWdL+8PRg+ua70vblqnKgALmPoQ
Date: Tue, 21 Apr 2015 05:28:53 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933005300FF5@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: 
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.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.20.231524
Archived-At: 
Cc: "General Area Review Team \(gen-art@ietf.org\)" , "v6ops@ietf.org" , "alexandre.petrescu@cea.fr" , "ietf@ietf.org" 
Subject: Re: [v6ops] Gen-ART review of draft-ietf-v6ops-cidr-prefix-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 05:29:02 -0000

Hi David,

Thank you for the review.=20

A new version is available online:

http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix-02=20

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-cidr-prefix-02=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: Black, David [mailto:david.black@emc.com]
> Envoy=E9=A0: mardi 21 avril 2015 01:55
> =C0=A0: BOUCADAIR Mohamed IMT/OLN; alexandre.petrescu@cea.fr; fred@cisco.=
com;
> General Area Review Team (gen-art@ietf.org)
> Cc=A0: ietf@ietf.org; v6ops@ietf.org; Black, David
> Objet=A0: Gen-ART review of draft-ietf-v6ops-cidr-prefix-01
>=20
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>=20
> .
>=20
> Please resolve these comments along with any other Last Call comments
> you may receive.
>=20
> Document: draft-ietf-v6ops-cidr-prefix-01
> Reviewer: David Black
> Review Date: April 20, 2015
> IETF LC End Date: April 20, 2015
>=20
> Summary: This draft is basically ready for publication, but has nits that
> 	should be fixed before publication.
>=20
> This is a short crisp draft on behavior of CIDR prefixes in IPv6
> forwarding
> with respect to the /64 boundary in IPv6 addresses.  It's clear, well
> explained
> easy to understand, plus refreshingly short.  Nicely done!
>=20
> Major issues: (none)
>=20
> Minor issues: (none)
>=20
> Nits/editorial comments: Ok, I found a nit ... and so did idnits ;-).
>=20
> -- Abstract
>=20
>    Hardware and software
>    algorithms should therefore impose no rules on prefix length, but
>    implement longest-match-first on prefixes of any valid length.
>=20
> "algorithms" isn't the right word.
> I suggest "implementations of routing and forwarding"
>=20
> idnits pointed out that: A later version (-06) exists of
>      draft-ietf-opsec-v6-05
>=20
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
> +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7=
786
> david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>=20


From nobody Mon Apr 20 23:48: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 936E91B3660 for ; Mon, 20 Apr 2015 23:48:16 -0700 (PDT)
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 KZYoca_bO8Qt for ; Mon, 20 Apr 2015 23:48:14 -0700 (PDT)
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 7F23D1B365F for ; Mon, 20 Apr 2015 23:48:14 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4A62162BE8 for ; Tue, 21 Apr 2015 08:48:12 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id EB2D860788 for ; Tue, 21 Apr 2015 08:48:11 +0200 (CEST)
Received: (qmail 58204 invoked by uid 1007); 21 Apr 2015 08:48:11 +0200
Date: Tue, 21 Apr 2015 08:48:11 +0200
From: Gert Doering 
To: Joe Touch 
Message-ID: <20150421064811.GG54385@Space.Net>
References:  <55351EA0.2010700@isi.edu> <20150420212125.GE54385@Space.Net> <55356F68.1020605@isi.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EAlATg9TatN2jXJk"
Content-Disposition: inline
In-Reply-To: <55356F68.1020605@isi.edu>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 06:48:16 -0000

--EAlATg9TatN2jXJk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Apr 20, 2015 at 02:28:08PM -0700, Joe Touch wrote:
> On 4/20/2015 2:21 PM, Gert Doering wrote:
> > On Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
> >>> If for some reasons, a router in the middle needs access to layer-4
> >>                                               ^^^^^
> >>> information (IPFIX? DDoS mitigation? ... ?), then the EH chain must be
> >>> parsed which can cause a performance impact.
> > [..]
> >> 	1) this is the router vendor's decision, not a requirement
> >> 	of Internet routers
> >=20
> > So, please tell me how you build an Internet router that is able to
> > defend itself against control plane abuse and does not need to look into
> > L4 to do so?
>=20
> A router can protect its own control plane by looking at the packet
> contents, but then it is acting as a host at that point and should be
> looking there only for packets addressed to interfaces of that router.
> That's not a forwarding function and thus doesn't limit the forwarding
> plane.

Of course, but real world requires that this filter function needs to be
implemented in the forwarding plane, because otherwise packets would just
saturate the link between forwarding and control plane if you would only=20
filter on "the other side".

=46rom a purely academic point of view, I totally agree with you. =20

Unfortunately, the Internet is not.

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

--EAlATg9TatN2jXJk
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVTXyq99WwGXkzn/FAQLPJg//Xcar1YWdL1rSiWRwh+3rNdgYZiZLMKxz
86CkAGmuMtBorkWfJli2xEchw3KAcF8ihlL90dBsqFQlgu94dYaNl1vwyzcfcF1i
hK+u6pjGZNboxPt7rBjWuVNng6hyI7FP0IVLNldMUfpE2fTl5qF9ojc7ikA9Uw2k
iIdOcwIwalHzY0KC2rl7xTMjRHeyFgrfV3UqgC5Echlq1KxjaSrO9PJxva1fyeTd
vN1MiIlpIrM9arX8Lomig74GU/CmbDfHC4wO6RJH097WCSmw1iBYJt16iYy9v228
U9cj/CU4O9Hd51JuRbTEmYIqF444xTPlUikj9BQ7Uu5ZsDTdaIcsbiSSbJoA+DLl
711mJBBxndp5jqMQkIVnZuXhOKfbVKU8wikPr8ADUKz+AtHYns88fiu7HYR07+7r
SQDCr/eRuzHt0yXrf9ZLUoFqYpPBXcEz8eLDasHQQLFtB03qV0fLu8g7rCuEccLi
DDFHsyMs3PRgryJN1nbfIQKJcPRBSP2p7ceGFQGTeH5Q2ty6K30QrqwRId/YS1tH
eubEt/bn0i0NwUj2NHlOQgBZWBNVcq9yyzZGBamICBCXALW3pFbyxO0oTECM4j0/
DQOjW0Y1wmr+WzkjqXxLhv/OMKx3Z6ae0tVDjC/UOK88JdKiSCnqVbZj0bnK4tyD
axnIRuKtunI=
=ukXS
-----END PGP SIGNATURE-----

--EAlATg9TatN2jXJk--


From nobody Tue Apr 21 01:06: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 01DB71B372C for ; Tue, 21 Apr 2015 01:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.502
X-Spam-Level: 
X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 K9HLjlJV0kJP for ; Tue, 21 Apr 2015 01:06:44 -0700 (PDT)
Received: from nm32-vm0.bullet.mail.bf1.yahoo.com (nm32-vm0.bullet.mail.bf1.yahoo.com [72.30.239.136]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7DE1B372B for ; Tue, 21 Apr 2015 01:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429603603; bh=G/VDR7vzLpmcwLAKrcD/02vMBJ5WZUT2GRVl5iLNdMA=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=FBLg0IG+mHBO2yn3wOnNmUqtwf5H8DLWcbp3Yitcc597zxgoR2fhVurTxHv9BG9SUQHuV6tcpIrucMH0utI4WgbU1zsNkITieXdhQRuHBWXStQQIR1BPw4TeYtlrGV65BgH1t+st5tTNw1W+JrrN77htwqEtd13KE9Jbh/sRboaxJeO/8flPeLQNoF10ER3TpyKVbUc+ldR87Kbk0vopdL+PHgLQFFyEuIAnydlCvoZS4qGojeaxRJina1/yTE4aLrUhu2GVIIroP7bXduNoXkNfMoQeilUck1g+ZS8d4+a0sngA+j9rGxNNv4NWlpPlgc5Uf5lgL3ocJ2/s2EwG6g==
Received: from [66.196.81.171] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 21 Apr 2015 08:06:43 -0000
Received: from [98.139.212.195] by tm17.bullet.mail.bf1.yahoo.com with NNFMP;  21 Apr 2015 08:06:42 -0000
Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 21 Apr 2015 08:06:42 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 929426.13252.bm@omp1004.mail.bf1.yahoo.com
X-YMail-OSG: b0.OnA8VM1ncZ8gUSiPRGb19GuASqoTZQvG0VmKrwFaIXz.MRc_YMMBdjubi8d_ Mj0npG7kco_yJ374FhLqZmXf4I6MPsz1D_9bZKrLOaKLOAXvOmLDBcfv4XU34atK_UTevjEkZWX6 OiGTxizgbAjOP3hnj5CY0Onz5lImLv11X.IsnysFD9UFLjSDJ3dzS3OtcFC6Y9.K_oBG9zANMyBu TnC4PJy7m7vUkJEK6tFjfjtSUhtPQ7IhKKI1TWngT9KoQCOrdP7b5emAfWYQlwXu6PJq0IAjRFPA fZdODWArNFM0VV96fmFH0k4qnA1WcfFF_GVRKm9A7tWKFcklZCNVfJ7sVnkbYFWaij1P0ZdXnOB7 .LLooBy93118wurqhNpq8D_ML4d2889UhyulXxmQufppBulYuMZOuo9Xi4mBU6UI_RffWcsjG0V3 _HexWrOvvw21SEPorgl3vLLtaJ7bFw1JYKCgFZ1iF.GLgvA96sEeVbLTx4zycdjT8Slw5VTIujfY rZrnwJGMPM5y.q6UC7lMf9j93tiAIphWk0mOmsxCTKg--
Received: by 66.196.80.115; Tue, 21 Apr 2015 08:06:42 +0000 
Date: Tue, 21 Apr 2015 08:06:41 +0000 (UTC)
From: Mark ZZZ Smith 
To: Gert Doering , Joe Touch 
Message-ID: <226821730.1251109.1429603601339.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <20150421064811.GG54385@Space.Net>
References: <20150421064811.GG54385@Space.Net>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1251108_1511727950.1429603601331"
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" , Merike Kaeo , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Apr 2015 08:06:46 -0000

------=_Part_1251108_1511727950.1429603601331
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: Gert Doering 
 To: Joe Touch =20
Cc: "v6ops@ietf.org" ; Merike Kaeo ; "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; Fernando Gont =20
 Sent: Tuesday, 21 April 2015, 16:48
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarificatio=
n text
  =20
Hi,

On Mon, Apr 20, 2015 at 02:28:08PM -0700, Joe Touch wrote:
> On 4/20/2015 2:21 PM, Gert Doering wrote:
> > On Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
> >>> If for some reasons, a router in the middle needs access to layer-4
> >>=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ^^^^^
> >>> information (IPFIX? DDoS mitigation? ... ?), then the EH chain must b=
e
> >>> parsed which can cause a performance impact.
> > [..]
> >> =C2=A0=C2=A0=C2=A0 1) this is the router vendor's decision, not a requ=
irement
> >> =C2=A0=C2=A0=C2=A0 of Internet routers
> >=20
> > So, please tell me how you build an Internet router that is able to
> > defend itself against control plane abuse and does not need to look int=
o
> > L4 to do so?
>=20
> A router can protect its own control plane by looking at the packet
> contents, but then it is acting as a host at that point and should be
> looking there only for packets addressed to interfaces of that router.
> That's not a forwarding function and thus doesn't limit the forwarding
> plane.

Of course, but real world requires that this filter function needs to be
implemented in the forwarding plane, because otherwise packets would just
saturate the link between forwarding and control plane if you would only=20
filter on "the other side".
/ So it should be easily possible to identify trusted IPv6 source and/or de=
stination addresses for control plane processes/protocols, and drop packets=
 that don't match them those on ingress to that control plane link, filteri=
ng them at egress of the forwarding plane. Host firewalling at the ingress =
of the control plane would then be able to perform further level of filteri=
ng if necessary. With the processing power of control plane CPUs these days=
, they shouldn't have trouble doing that.
/Furthermore, network cards these days perform large receive offload (conca=
tenation of multiple UDP or TCP packets to be able to form a single large o=
ne to hand up to the operating system.) Because of their level of UDP or TC=
P understanding, It may be possible to push TCP or UDP port level filtering=
 down into one of those if the control plane link is actually an ethernet l=
ink (or you could put one at the forwarding plane egress of the link to the=
 control plane, and perform TCP/UDP port level filtering there.)
/ Regards,
Mark.



>From a purely academic point of view, I totally agree with you.=C2=A0=20

Unfortunately, the Internet is not.



Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo=
rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 USt-IdNr.: DE813=
185279
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


  
------=_Part_1251108_1511727950.1429603601331
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



   
 
 
   From: Gert Doering <gert@space.net>
 To: Joe Touch <touch@isi.edu> Cc: "v6ops@ietf.org" <=
;v6ops@ietf.org>; Merike Kaeo <merike@doubleshotsecurity.com>; "dr=
aft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <draft-gont-v6ops-=
ipv6-ehs-in-real-world@tools.ietf.org>; Fernando Gont <fgont@si6netwo=
rks.com> 
 Sent: Tue=
sday, 21 April 2015, 16:48
 Subjec=
t: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarific=
ation text
  
 

Hi,

On M=
on, Apr 20, 2015 at 02:28:08PM -0700, Joe Touch wrote:
&g=
t; On 4/20/2015 2:21 PM, Gert Doering wrote:
> > On=
 Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
=
> >>> If for some reasons, a router in the middle needs access =
to layer-4
> >>         =
;                     &nb=
sp;                ^^^^^
> >>> information (IPFIX? DDoS mitigation? ... ?), then the =
EH chain must be
> >>> parsed which can cause=
 a performance impact.
> > [..]
&=
gt; >>     1) this is the router vendor's decision, no=
t a requirement
> >>     of Inter=
net routers
> > 
> > So, pl=
ease tell me how you build an Internet router that is able to
> > defend itself against control plane abuse and does not need =
to look into
> > L4 to do so?
>=
; 
> A router can protect its own control plane by loo=
king at the packet
> contents, but then it is acting a=
s a host at that point and should be
> looking there o=
nly for packets addressed to interfaces of that router.
&=
gt; That's not a forwarding function and thus doesn't limit the forwarding<=
br clear=3D"none">> plane.

Of cours=
e, but real world requires that this filter function needs to be
implemented in the forwarding plane, because otherwise packets wo=
uld just
saturate the link between forwarding and control=
 plane if you would only 
filter on "the other side".
/ So it should be easily possible to identify trusted IPv6 =
source and/or destination addresses for control plane processes/protocols, =
and drop packets that don't match them those on ingress to that control pla=
ne link, filtering them at egress of the forwarding plane. Host firewalling=
 at the ingress of the control plane would then be able to perform further =
level of filtering if necessary. With the processing power of control plane=
 CPUs these days, they shouldn't have trouble doing that.
/Furthermore, network cards these days perform large receiv=
e offload (concatenation of multiple UDP or TCP packets to be able to form =
a single large one to hand up to the operating system.) Because of their le=
vel of UDP or TCP understanding, It may be possible to push TCP or UDP port=
 level filtering down into one of those if the control plane link is actual=
ly an ethernet link (or you could put one at the forwarding plane egress of=
 the link to the control plane, and perform TCP/UDP port level filtering th=
ere.)

/ Regards,
Mark.




From=
 a purely academic point of view, I totally agree with you.  

Unfortunately, the Internet is not.




Gert Doering

        -- NetMaster
-- 
have you enabled IPv6 on something today...?
<=
br clear=3D"none">SpaceNet AG            &nbs=
p;           Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Auf=
sichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen&nb=
sp;                  HRB: 136055 (A=
G Muenchen)
Tel: +49 (0)89/32356-444      =
     USt-IdNr.: DE813185279
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


 
 
  

------=_Part_1251108_1511727950.1429603601331--


From nobody Tue Apr 21 08:46: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 323621ACEA9 for ; Tue, 21 Apr 2015 08:46:40 -0700 (PDT)
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 54-0QPwPnPki for ; Tue, 21 Apr 2015 08:46:38 -0700 (PDT)
Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B231ACE7E for ; Tue, 21 Apr 2015 08:46:38 -0700 (PDT)
Received: from [192.168.1.3] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3LFjWLP026245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Apr 2015 08:45:41 -0700 (PDT)
Message-ID: <5536709B.1050001@isi.edu>
Date: Tue, 21 Apr 2015 08:45:31 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Gert Doering 
References:  <55351EA0.2010700@isi.edu> <20150420212125.GE54385@Space.Net> <55356F68.1020605@isi.edu> <20150421064811.GG54385@Space.Net>
In-Reply-To: <20150421064811.GG54385@Space.Net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 15:46:40 -0000

On 4/20/2015 11:48 PM, Gert Doering wrote:
> Hi,
> 
> On Mon, Apr 20, 2015 at 02:28:08PM -0700, Joe Touch wrote:
>> On 4/20/2015 2:21 PM, Gert Doering wrote:
>>> On Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
>>>>> If for some reasons, a router in the middle needs access to layer-4
>>>>                                               ^^^^^
>>>>> information (IPFIX? DDoS mitigation? ... ?), then the EH chain must be
>>>>> parsed which can cause a performance impact.
>>> [..]
>>>> 	1) this is the router vendor's decision, not a requirement
>>>> 	of Internet routers
>>>
>>> So, please tell me how you build an Internet router that is able to
>>> defend itself against control plane abuse and does not need to look into
>>> L4 to do so?
>>
>> A router can protect its own control plane by looking at the packet
>> contents, but then it is acting as a host at that point and should be
>> looking there only for packets addressed to interfaces of that router.
>> That's not a forwarding function and thus doesn't limit the forwarding
>> plane.
> 
> Of course, but real world requires that this filter function needs to be
> implemented in the forwarding plane, because otherwise packets would just
> saturate the link between forwarding and control plane if you would only 
> filter on "the other side".

DDOS filtering is a feature, not a requirement.

If you want to offer that as a feature, please stop complaining that
customers should expect that it runs at rate with packets that conform
to existing standards.

> From a purely academic point of view, I totally agree with you.  
> 
> Unfortunately, the Internet is not.

The Internet is also not designed to optimize your profit margins either.

Joe


From nobody Tue Apr 21 08:51: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 A345B1ACEE9 for ; Tue, 21 Apr 2015 08:51:07 -0700 (PDT)
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 IksDeg32Avhf for ; Tue, 21 Apr 2015 08:51:05 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978111A1A17 for ; Tue, 21 Apr 2015 08:51:05 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id ECF9E62BE8 for ; Tue, 21 Apr 2015 17:51:03 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A19DE60B6B for ; Tue, 21 Apr 2015 17:51:03 +0200 (CEST)
Received: (qmail 6708 invoked by uid 1007); 21 Apr 2015 17:51:03 +0200
Date: Tue, 21 Apr 2015 17:51:03 +0200
From: Gert Doering 
To: Joe Touch 
Message-ID: <20150421155103.GZ54385@Space.Net>
References:  <55351EA0.2010700@isi.edu> <20150420212125.GE54385@Space.Net> <55356F68.1020605@isi.edu> <20150421064811.GG54385@Space.Net> <5536709B.1050001@isi.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUC51av+Yd1SYAb9"
Content-Disposition: inline
In-Reply-To: <5536709B.1050001@isi.edu>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" , Merike Kaeo , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 15:51:07 -0000

--fUC51av+Yd1SYAb9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Apr 21, 2015 at 08:45:31AM -0700, Joe Touch wrote:
> DDOS filtering is a feature, not a requirement.

I'm fully at a loss to express my amazement in polite words, so I'm just
*out* of this discussion now.

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

--fUC51av+Yd1SYAb9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVTZx599WwGXkzn/FAQJ9fg//Qr5tfRoyiJQJE3weDtHfitqlnXdUC+q8
sueou6CV34i4x9ppuPqmsc/4GzKtycFeFqvYrHvUb5AHgvQqxW4FLcoIF6wCvVav
q983ap5ZjQ+pwr/mthkqrstodwRDXTMl0ChQ2OvvEmmtJ9ze9Y8crwHTCyrK8u+/
ITH3+7Sd3VM849heNZV7DOX8QxiKGlzyqWnQUwQ1QjEtCIjcq8TVCDEYrRGK6O0U
H6fNBFuZ1xoooR4OLh+FMPj9nB2I6GmbhyCY0ZXUHAixP16N2gKY52kpD33qf/gs
1A7g4i31eZ5aaZeXH0ivTYefikcA0mPJn0Pd7/dkbKjSCLxtYVU1GXb35KYZVPh+
ksuxoyzUMVIwAno2U7kkNJUv1eSSPNtLEEle8cvZXG8gvxzQWO554OpziyJZK1eR
0pjHRfisvgrpDHd6df/CF5jdjxGKCdJAjLhGlsksSslBVLkQJbP+HxIzgyVmLISK
kuelmyL4N8K5VXqpft07P4Rg9PvVSKEmc3GyJIVzkUX0OZjtrMKhs0VOc1iFQAoV
11d43xyDk7VnpplesusnnpKofLEEh0RDjyiJRzqfqWTAnHCy6WWj+PZqu8EGiew3
Px1GXHh8UpDPGNogBL/j8QJzLgr7Ps6jyhJSqeNX3En7RLr3xHR+/KPpSm8cGJIU
MM9xnBJScGI=
=gI+J
-----END PGP SIGNATURE-----

--fUC51av+Yd1SYAb9--


From nobody Tue Apr 21 09:56:52 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 B8E701AD2A4 for ; Tue, 21 Apr 2015 09:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1PA1MWYWIH0 for ; Tue, 21 Apr 2015 09:56:49 -0700 (PDT)
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 CA3201AD244 for ; Tue, 21 Apr 2015 09:56:48 -0700 (PDT)
X-Envelope-To: 
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:0:0:0:110]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t3LGujLG069704 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Apr 2015 17:56:46 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:110] claimed to be cupcake.foobar.org
Message-ID: <5536814D.7030708@foobar.org>
Date: Tue, 21 Apr 2015 17:56:45 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: v6ops@ietf.org
References:  <55351EA0.2010700@isi.edu> <20150420212125.GE54385@Space.Net> <55356F68.1020605@isi.edu> <20150421064811.GG54385@Space.Net> <5536709B.1050001@isi.edu> <20150421155103.GZ54385@Space.Net>
In-Reply-To: <20150421155103.GZ54385@Space.Net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 16:56:50 -0000

On 21/04/2015 16:51, Gert Doering wrote:
> I'm fully at a loss to express my amazement in polite words, so I'm just
> *out* of this discussion now.

Fully agreed on this + that this thread needs to end.  The lack of
operational reality being displayed is pretty severe.

Nick


From nobody Tue Apr 21 10:16: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 83D161A1A33 for ; Tue, 21 Apr 2015 10:16:18 -0700 (PDT)
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 a9AJhT3H1tB4 for ; Tue, 21 Apr 2015 10:16:17 -0700 (PDT)
Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970A81A001B for ; Tue, 21 Apr 2015 10:16:17 -0700 (PDT)
Received: from [192.168.1.3] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3LHFWTH013351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Apr 2015 10:15:44 -0700 (PDT)
Message-ID: <553685B3.90805@isi.edu>
Date: Tue, 21 Apr 2015 10:15:31 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Nick Hilliard , v6ops@ietf.org
References:  <55351EA0.2010700@isi.edu> <20150420212125.GE54385@Space.Net> <55356F68.1020605@isi.edu> <20150421064811.GG54385@Space.Net> <5536709B.1050001@isi.edu> <20150421155103.GZ54385@Space.Net> <5536814D.7030708@foobar.org>
In-Reply-To: <5536814D.7030708@foobar.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 17:16:18 -0000

On 4/21/2015 9:56 AM, Nick Hilliard wrote:
> On 21/04/2015 16:51, Gert Doering wrote:
>> I'm fully at a loss to express my amazement in polite words, so I'm just
>> *out* of this discussion now.
> 
> Fully agreed on this + that this thread needs to end.  The lack of
> operational reality being displayed is pretty severe.

The Internet is not designed to optimize convenience or profit. The
functions in IPv6 are there for a reason; turning them off to simplify
life for vendors isn't useful to customers.

If you want something that is trivial to parse in hardware, you might
consider offering ATM equipment instead.

Joe


From nobody Tue Apr 21 10:38: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 98C971B29F7 for ; Tue, 21 Apr 2015 10:38:06 -0700 (PDT)
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 xEpSL0pwpykN for ; Tue, 21 Apr 2015 10:38:05 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 0BEC51A877B for ; Tue, 21 Apr 2015 10:38:02 -0700 (PDT)
Received: (qmail 71487 invoked from network); 21 Apr 2015 17:38:00 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Apr 2015 17:38:00 -0000
Date: Tue, 21 Apr 2015 19:38:00 +0200 (CEST)
Message-Id: <20150421.193800.74688189.sthaug@nethelp.no>
To: nick@foobar.org
From: sthaug@nethelp.no
In-Reply-To: <5536814D.7030708@foobar.org>
References: <5536709B.1050001@isi.edu> <20150421155103.GZ54385@Space.Net> <5536814D.7030708@foobar.org>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 17:38:06 -0000

> On 21/04/2015 16:51, Gert Doering wrote:
> > I'm fully at a loss to express my amazement in polite words, so I'm just
> > *out* of this discussion now.
> 
> Fully agreed on this + that this thread needs to end.  The lack of
> operational reality being displayed is pretty severe.

+1.

Steinar Haug, AS 2116


From nobody Tue Apr 21 11:24: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 1FABD1A897D for ; Tue, 21 Apr 2015 11:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 yh67JFXi6xNI for ; Tue, 21 Apr 2015 11:24:51 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 ADF4A1A8991 for ; Tue, 21 Apr 2015 11:23:57 -0700 (PDT)
Received: by widdi4 with SMTP id di4so31483140wid.0 for ; Tue, 21 Apr 2015 11:23:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JPb0vQgbBUSkRkWE3FRyaKgmChDaUFVU4D6yjRxsHwA=; b=AqWvnPs5CDMfmogXCvWg5j/dI6jgwky13hIAd/IGe/mTa9x/R9QoTO6/8LzRe0nrFq 3ZrE+/4QAionstxtppCPKRIpW+TAKZ2hV6Rjx9YFtg0gOAZI2VhrcdINR9sDk2P0GTzt 9GSSDO5HxKlWWluueoTMAZ1Mm5yWLzqeoKQFrlU3WmGGqI0vy4uk3syDjQwj+ymH0oJQ d9W9mq+8DhacmTtMk+WofUWY4O0jjEoKT+hbSg1lCvgZ8rej9Or7m728gBmOIq2bXe6I b4CnCfRA9UHmdbIG7NMZ+An6LtwNGgIDCyOVJD9rqGHMj/0r6JjkLUZLjsCCncTMdE+z vlhg==
X-Gm-Message-State: ALoCoQnDHesxIeWvs6Rz5iHIaXjFtr9M8RtPTFGwWj6h4eunslBrTaZK307LeVH0JEf3ct8CU0j1
MIME-Version: 1.0
X-Received: by 10.180.77.83 with SMTP id q19mr36753104wiw.89.1429640636500; Tue, 21 Apr 2015 11:23:56 -0700 (PDT)
Received: by 10.194.47.36 with HTTP; Tue, 21 Apr 2015 11:23:56 -0700 (PDT)
In-Reply-To: <5536709B.1050001@isi.edu>
References:  <55351EA0.2010700@isi.edu> <20150420212125.GE54385@Space.Net> <55356F68.1020605@isi.edu> <20150421064811.GG54385@Space.Net> <5536709B.1050001@isi.edu>
Date: Tue, 21 Apr 2015 14:23:56 -0400
Message-ID: 
From: Warren Kumari 
To: Joe Touch 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" , Merike Kaeo , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 18:24:53 -0000

On Tue, Apr 21, 2015 at 11:45 AM, Joe Touch  wrote:
>
>
> On 4/20/2015 11:48 PM, Gert Doering wrote:
>> Hi,
>>
>> On Mon, Apr 20, 2015 at 02:28:08PM -0700, Joe Touch wrote:
>>> On 4/20/2015 2:21 PM, Gert Doering wrote:
>>>> On Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
>>>>>> If for some reasons, a router in the middle needs access to layer-4
>>>>>                                               ^^^^^
>>>>>> information (IPFIX? DDoS mitigation? ... ?), then the EH chain must be
>>>>>> parsed which can cause a performance impact.
>>>> [..]
>>>>>    1) this is the router vendor's decision, not a requirement
>>>>>    of Internet routers
>>>>
>>>> So, please tell me how you build an Internet router that is able to
>>>> defend itself against control plane abuse and does not need to look into
>>>> L4 to do so?
>>>
>>> A router can protect its own control plane by looking at the packet
>>> contents, but then it is acting as a host at that point and should be
>>> looking there only for packets addressed to interfaces of that router.
>>> That's not a forwarding function and thus doesn't limit the forwarding
>>> plane.
>>
>> Of course, but real world requires that this filter function needs to be
>> implemented in the forwarding plane, because otherwise packets would just
>> saturate the link between forwarding and control plane if you would only
>> filter on "the other side".
>
> DDOS filtering is a feature, not a requirement.
>


Sorry, no....

Now I remember why I got fed up with the previous EH discussions
(draft-taylor-v6ops-fragdrop, draft-bonica-6man-frag-deprecate,
draft-wkumari-6man-long-headers, etc) and stopped following v6ops and
6man.
'parently not much has changed....

W

> If you want to offer that as a feature, please stop complaining that
> customers should expect that it runs at rate with packets that conform
> to existing standards.
>
>> From a purely academic point of view, I totally agree with you.
>>
>> Unfortunately, the Internet is not.
>
> The Internet is also not designed to optimize your profit margins either.
>
> Joe
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf


From nobody Tue Apr 21 11:29:52 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 60DD31A8856 for ; Tue, 21 Apr 2015 11:29:51 -0700 (PDT)
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 B0hLYmOuUKkj for ; Tue, 21 Apr 2015 11:29:50 -0700 (PDT)
Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B011A8838 for ; Tue, 21 Apr 2015 11:29:50 -0700 (PDT)
Received: from [192.168.1.3] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3LIT1LN005289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Apr 2015 11:29:11 -0700 (PDT)
Message-ID: <553696EC.4060207@isi.edu>
Date: Tue, 21 Apr 2015 11:29:00 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Warren Kumari 
References: 	<55351EA0.2010700@isi.edu>	<20150420212125.GE54385@Space.Net>	<55356F68.1020605@isi.edu>	<20150421064811.GG54385@Space.Net>	<5536709B.1050001@isi.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" , Merike Kaeo , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 18:29:51 -0000

On 4/21/2015 11:23 AM, Warren Kumari wrote:
> On Tue, Apr 21, 2015 at 11:45 AM, Joe Touch  wrote:
...
>> DDOS filtering is a feature, not a requirement.
> 
> 
> Sorry, no....

Then please point us all to the requirements-track RFC that establishes
this as a *requirement* for Internet routers.

Joe


From nobody Tue Apr 21 11:36: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 AC3BE1A87EB for ; Tue, 21 Apr 2015 11:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 AeJy0JIVjpzi for ; Tue, 21 Apr 2015 11:35:59 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D831A8920 for ; Tue, 21 Apr 2015 11:35:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 09DAF24066C; Tue, 21 Apr 2015 11:35:41 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 5AA652402BC; Tue, 21 Apr 2015 11:35:40 -0700 (PDT)
Message-ID: <55369855.1040101@joelhalpern.com>
Date: Tue, 21 Apr 2015 14:35:01 -0400
From: "Joel M. Halpern" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Joe Touch 
References: 	<55351EA0.2010700@isi.edu>	<20150420212125.GE54385@Space.Net>	<55356F68.1020605@isi.edu>	<20150421064811.GG54385@Space.Net>	<5536709B.1050001@isi.edu>  <553696EC.4060207@isi.edu>
In-Reply-To: <553696EC.4060207@isi.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" , Merike Kaeo , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 18:36:00 -0000

The need to protect the control plane components (routers, controllers, 
whatever you want to call them) from overload is a well-established 
practice in the industry.  It is expected by operators when they buy, 
and delivered by all major vendors in the devices they build.

Given that until recently it has been a behavior inside a device, no, it 
is not documented inan RFC.  That does not mean it is untrue or unrealistic.

Yours,
Joel

On 4/21/15 2:29 PM, Joe Touch wrote:
>
>
> On 4/21/2015 11:23 AM, Warren Kumari wrote:
>> On Tue, Apr 21, 2015 at 11:45 AM, Joe Touch  wrote:
> ...
>>> DDOS filtering is a feature, not a requirement.
>>
>> 
>> Sorry, no....
>
> Then please point us all to the requirements-track RFC that establishes
> this as a *requirement* for Internet routers.
>
> Joe
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


From nobody Tue Apr 21 11:47: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 C007D1A897B for ; Tue, 21 Apr 2015 11:47:56 -0700 (PDT)
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 WyF8DTY5Ey2C for ; Tue, 21 Apr 2015 11:47:55 -0700 (PDT)
Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944CE1A8973 for ; Tue, 21 Apr 2015 11:47:55 -0700 (PDT)
Received: from [192.168.1.3] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3LIlAeq009946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Apr 2015 11:47:20 -0700 (PDT)
Message-ID: <55369B2D.80906@isi.edu>
Date: Tue, 21 Apr 2015 11:47:09 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Joel M. Halpern" 
References: 	<55351EA0.2010700@isi.edu>	<20150420212125.GE54385@Space.Net>	<55356F68.1020605@isi.edu>	<20150421064811.GG54385@Space.Net>	<5536709B.1050001@isi.edu>  <553696EC.4060207@isi.edu> <55369855.1040101@joelhalpern.com>
In-Reply-To: <55369855.1040101@joelhalpern.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" , Merike Kaeo , Fernando Gont 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 18:47:56 -0000

On 4/21/2015 11:35 AM, Joel M. Halpern wrote:
> The need to protect the control plane components (routers, controllers,
> whatever you want to call them) from overload is a well-established
> practice in the industry.  It is expected by operators when they buy,
> and delivered by all major vendors in the devices they build.
> 
> Given that until recently it has been a behavior inside a device, no, it
> is not documented inan RFC.  That does not mean it is untrue or
> unrealistic.

I don't disagree. But it is an E-ticket ride - it is inherently expensive.

I don't object to ops docs that say "this is hard", but I do think it's
not productive to say "and we should make the protocol easier by gutting
the hard parts" unless there is a rationale - one that presumably
doesn't rely only on "because it's hard".

Because that just translates to "because I'm greedy".

Here's an analogy:

	Cars advertise seating capacity.

	It's unrealistic to expect every 4-person car to
	fit four 600-pound people.

	It's equally unrealistic to redefine "person" to
	mean "110-pound model".

There needs to be a balance between what's expensive and inconvenient
vs. neutering a protocol to make it easy to implement.

Protecting the control plane can be done by the receiving host
(destination router). Protecting the network from sending traffic that
is dumped at the destination is certainly a useful capability, but not
to protect the destination router. It protects the network as a whole.

Protecting the network as a whole is useful, and may involve some level
of DPI - or may not. If the traffic is encrypted, then only the
destination router can protect itself anyway. But dropping the packets
because of EH use just makes the filtering router an attacker to the E2E
communication between the routers.

Joe




From nobody Tue Apr 21 12:02: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 919471A8A56 for ; Tue, 21 Apr 2015 12:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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] 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 X3fSClIEiDTx for ; Tue, 21 Apr 2015 12:02:32 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 4208F1A8A59 for ; Tue, 21 Apr 2015 12:02:10 -0700 (PDT)
Received: by widdi4 with SMTP id di4so150881668wid.0 for ; Tue, 21 Apr 2015 12:02:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/8vbU6Az2VsMxNdImxM1AzRp6g/tYszZ/14Dr/BBLEc=; b=YIY9jXWofvOgQEO3SM7o4rGEqMLCR+JedfnbQpP9Ok1TjBArteem4THNxdqJa4fl6Y N+BjCS6vocuH2wBg9JQHBIFXH5jKsCJxYf1dH+kpC0OJ55HftTZi7o0ZPfDNTHmndt2V JHgMz/AibkmaHf7H7IOQmHFiqpBD9jsjmqfvY=
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=/8vbU6Az2VsMxNdImxM1AzRp6g/tYszZ/14Dr/BBLEc=; b=ZLSbpqg86Zjw0/RnY/foaiIIUgADJc0TJORqFR7UdxbkYNxY8+Kf7ZF5UZAH04dvdI zaqFYYtJ6BbEV4AcXNJAUIxL1ptenqDz0hadRMOyeQrloHoRtzk03W48tAMq0TTKpOm7 Vu8pC12B7NN4S/CHsZR25ljsg36E8+ACvYS1e8wKL+aPtqXl6itRNUVJwirrqAokALlr XJ0RuaPwc+ygCWGEemqTB0ykGeBYR/DWc5IURQHBf44LdD76RSu6P/vX6dp8EP0+aFwn c8OSs8BHFLhLk8wsbR9cKHJ5MUHQgD+/SNmutADYtfthlt4MwMLHD1vjmO8sdTrjdHON ATWw==
X-Gm-Message-State: ALoCoQnP226RIvdxeG27J0qmiQRJxP19oE0cFvPjyKED9N0z1vFwQoRWHH0gMom/pKXdl+hQHkUy
MIME-Version: 1.0
X-Received: by 10.180.96.65 with SMTP id dq1mr37551811wib.46.1429642929030; Tue, 21 Apr 2015 12:02:09 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Tue, 21 Apr 2015 12:02:08 -0700 (PDT)
In-Reply-To: <5536776A.9060204@cernet.edu.cn>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <5536776A.9060204@cernet.edu.cn>
Date: Tue, 21 Apr 2015 12:02:08 -0700
Message-ID: 
From: James Woodyatt 
To: Xing Li 
Content-Type: multipart/alternative; boundary=f46d04343dd0f0debb051440aedf
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Apr 2015 19:02:33 -0000

--f46d04343dd0f0debb051440aedf
Content-Type: text/plain; charset=UTF-8

On Tue, Apr 21, 2015 at 9:14 AM, Xing Li  wrote:
>
>
> (1) If the host system can not do RFC6145, the additional CPE is
> required to do so, and that also keeps the IPv4 literals on the Internet
> forever.
>

I wouldn't characterize it like that. I think what you mean to say is this:
because support for IPv4 literals can never be removed from the Internet,
hosts must either be provided with IPv4 service forever or all the hosts on
the Internet must be upgraded to support the CLAT function in 464XLAT. My
point is that you can't require all the hosts to be upgraded with CLAT
functions any more than your require all the applications to stop using
IPv4 literals everywhere. You are left with exactly one alternative: you
must support IPv4 forever, and this is not because hosts don't have CLAT
functions, but entirely because you cannot abide breaking any of the
applications today that use IPv4 literals.

Shorter james: your problem is the IPv4 literals. If you can't ignore them,
and you can't do anything else about them, then you can't deploy IPv6-only.
It's really that simple.

(2) No ISP will deploy the IPv6-only network, if the end users cannot
> access the websites with IPv4 literals.
>

I don't have a problem with that. I've been saying all along that ISPs
should not be in any hurry to turn off IPv4 service to CPE devices
completely.

-- 
james woodyatt 
Nest Labs, Communications Engineering

--f46d04343dd0f0debb051440aedf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Apr 21, 2015 at 9:14 AM, Xing Li <xing@cernet.edu.cn> w=
rote:



(1) If the host system can not do RFC6145, the additional CPE is

required to do so, and that also keeps the IPv4 literals on the Internet
forever.

I wouldn't characterize it=
 like that. I think what you mean to say is this: because support for IPv4 =
literals can never be removed from the Internet, hosts must either be provi=
ded with IPv4 service forever or all the hosts on the Internet must be upgr=
aded to support the CLAT function in 464XLAT. My point is that you can'=
t require all the hosts to be upgraded with CLAT functions any more than yo=
ur require all the applications to stop using IPv4 literals everywhere. You=
 are left with exactly one alternative: you must support IPv4 forever, and =
this is not because hosts don't have CLAT functions, but entirely becau=
se you cannot abide breaking any of the applications today that use IPv4 li=
terals.

Shorter james: your problem is the IPv4 li=
terals. If you can't ignore them, and you can't do anything else ab=
out them, then you can't deploy IPv6-only. It's really that simple.=



(2) No ISP will deploy the IPv6-only network, if the end users cannot

access the websites with IPv4 literals.

I don't have a problem with that. I've been=
 saying all along that ISPs should not be in any hurry to turn off IPv4 ser=
vice to CPE devices completely.

-- 
james woodyatt <jhw@nestlabs.com>
Nest=
 Labs, Communications Engineering




--f46d04343dd0f0debb051440aedf--


From nobody Tue Apr 21 23:20:37 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 68CFB1B2D91 for ; Tue, 21 Apr 2015 23:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.202
X-Spam-Level: ***
X-Spam-Status: No, score=3.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, HK_RANDOM_REPLYTO=0.999, 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 e7FeScpby_Sy for ; Tue, 21 Apr 2015 23:20:29 -0700 (PDT)
Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6126F1B2D8A for ; Tue, 21 Apr 2015 23:20:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429683617; bh=2teCtnTSDYhIkC6cBZMGwalmIi7wR6P/kme23X6bylE=;  h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject;  b=HGAFpuKO0tVXRqghEUqWiGvsM54DxFzhPD4xggtojnSnqd0sGibQcEP1ZvnIcVUlJCHFRDhG6ICOIU1Yh/5hgSh0JrSQKuPpdWvxbQ4xG8A8qznyh6yrHOAo+UvaJBdHMISfDoN0Tr96pot7WpXJywgrNu8HYgTxEDYw3bDEHS1tU1/PiuuoFs9p29bJtAZNAN7nCx8RbtA+DivnFgVIm9cgWQUNxx18ZuioUMUMyZHhhUdSGTPwQDsTlMvH0hgFby2tC7iERtodAW+VgUmvyzuKUCxQJ8xbGLwIVcVGtxAXVjQ+vCcLUCagA8oJyRdkKqzvD/jodW9+U1G2iwyQog==
Received: from [98.139.170.178] by nm14.bullet.mail.bf1.yahoo.com with NNFMP;  22 Apr 2015 06:20:17 -0000
Received: from [98.139.212.222] by tm21.bullet.mail.bf1.yahoo.com with NNFMP;  22 Apr 2015 06:20:17 -0000
Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 22 Apr 2015 06:20:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 420566.15624.bm@omp1031.mail.bf1.yahoo.com
X-YMail-OSG: _DdGPecVM1m3Gsp2XikwQVQHoXlqjnCKLWz_bzJ_1j.BGKEGeLO26ZA3IxP2aiW IYHZPMM5i9O6nhw3fvmMwTUcwjO8SZd17C4Hv4BoZ5vhf5TyaZYumDDP.7q1w21a1TfRNMBlKe9b gmo3_2J_mNRGrnB4iSgn1g_sFWKC86o1Owl6XsSGXWZpI_8MyrMsPAu_1yjthaPhEa_rAnK9u1TH cxb4_xXcDUXdLwQzio5CFvuiCyYRqrobB8bJfVqDXQ1ox3CBxt.oLeAjgnpbfLfQvOVO2_SpVoKp MFf_GHMt8v8iTgmdytqPRQ.dwaTHacWaF54qaZmpEKknOO14OGN6.L2y.O4PnZSNpUSTJL1DizCu sgpCoO6nBAZ5ncFBR2ZJEfYGY7bW4yVfxBf4QTeaXCftqkOSiVjQgZ7q0JT2KJTt9xUCvcQOZHeh F3oIWI4hNdT9DoG_K.MP.kq0h3HinTcZEgCEssxruxL2vtMGY6BtCbrUB6KWUj.MUxoZZ_cDZxI0 Nw2YD0rPQdZjYiR1ecw--
Received: by 66.196.80.117; Wed, 22 Apr 2015 06:20:16 +0000 
Date: Wed, 22 Apr 2015 06:20:00 +0000 (UTC)
From: Mark ZZZ Smith 
To: Nick Hilliard , "v6ops@ietf.org" 
Message-ID: <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <5536814D.7030708@foobar.org>
References: <5536814D.7030708@foobar.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_2158101_1019434309.1429683600979"
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
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, 22 Apr 2015 06:20:32 -0000

------=_Part_2158101_1019434309.1429683600979
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So I'm going to call the emperor naked.
What I think you and Gert actually want is for EHs to be completely depreca=
ted, so that the TCP and UDP headers are always in the same place in the pa=
cket, so that hardware can look at them for the purposes of dropping them i=
n hardware or as inputs into LB. Is that the case?
What I'm curious about then is how do you handle DDoSes that are using IP f=
ragments, where there are no TCP or UDP headers ports to look at?
I'm also curious about how you LB packets (either at layer 2 or layer 3) th=
at don't have TCP or UDP headers, or aren't IP. I've seen LB become complet=
ely ineffective at layer 2 because a customer was using MPLS between two ro=
uters, so no MAC address variation, and no IP addresses and no TCP or UDP p=
orts to look at.
In fact, given the trouble LAG has caused me in the past 2 years (LAG membe=
r links that are not current members are supposed to be considered by the b=
ridge as normal bridge ports, so if you want to avoid loops across the link=
s that are candidate members of the LAG, the IEEE expect you to be running =
STP of some form across them...), I'm a big fan of the quote on the last sl=
ide of this presentation:
"IEEE 802.3ad Link Aggregation(LAG)what it is, and what it is not"
http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf


"LAG is good, but it=E2=80=99s not as good as a fatter pipe."


      From: Nick Hilliard 
 To: v6ops@ietf.org=20
 Sent: Wednesday, 22 April 2015, 2:56
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarificatio=
n text
  =20
On 21/04/2015 16:51, Gert Doering wrote:
> I'm fully at a loss to express my amazement in polite words, so I'm just
> *out* of this discussion now.

Fully agreed on this + that this thread needs to end.=C2=A0 The lack of
operational reality being displayed is pretty severe.

Nick



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


  
------=_Part_2158101_1019434309.1429683600979
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


So I=
'm going to call the emperor naked.

What I think you and Gert actually want is for EHs to be completely d=
eprecated, so that the TCP and UDP headers are always in the same place in =
the packet, so that hardware can look at them for the purposes of dropping =
them in hardware or as inputs into LB. Is that the case?

<=
div id=3D"yui_3_16_0_1_1429660521800_58043" dir=3D"ltr">What I'm curious about then is how do you handle=
 DDoSes that are using IP fragments, where there are no TCP or UDP headers =
ports to look at?

I'm also cur=
ious about how you LB packets (either at layer 2 or layer 3) that don't hav=
e TCP or UDP headers, or aren't IP. I've seen LB become completely ineffect=
ive at layer 2 because a customer was using MPLS between two routers, so no=
 MAC address variation, and no IP addresses and no TCP or UDP ports to look=
 at.
<=
span>
In fact, given the troubl=
e LAG has caused me in the past 2 years (LAG member links that are not curr=
ent members are supposed to be considered by the bridge as normal bridge po=
rts, so if you want to avoid loops across the links that are candidate memb=
ers of the LAG, the IEEE expect you to be running STP of some form across t=
hem...), I'm a big fan of the quote on the last slide of this presentation:=


=
"IEEE 802.3ad Link Aggregation
(LAG)
what it is, and what it is not"


"LAG is good, but it=E2=80=99s not as good as a fatter=
 pipe."
<=
span>

  
 
 
 
   From: Nick Hilliard <=
;nick@foobar.org>
 To: v6ops@ietf.org 
 Sent: Wednesday, 22 April 2015, 2:56
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-wor=
ld: clarification text
  
 

On 21/04/2015 16:51, Gert Doering=
 wrote:
> I'm fully at a loss to express my amazement =
in polite words, so I'm just
> *out* of this discussio=
n now.

Fully agreed on this + that thi=
s thread needs to end.  The lack of
operational real=
ity being displayed is pretty severe.

=
Nick




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


<=
/div> 
 
  

------=_Part_2158101_1019434309.1429683600979--


From nobody Tue Apr 21 23:34: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 A51841B31A1 for ; Tue, 21 Apr 2015 23:34:22 -0700 (PDT)
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 no1lZSrmQ7et for ; Tue, 21 Apr 2015 23:34:21 -0700 (PDT)
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 D91FD1B2D92 for ; Tue, 21 Apr 2015 23:33:02 -0700 (PDT)
Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:6127:947a:22bf:5c78]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3M6Wq0c041964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2015 06:32:52 GMT (envelope-from joelja@bogus.com)
To: Mark ZZZ Smith , Nick Hilliard , "v6ops@ietf.org" 
references: <5536814D.7030708@foobar.org> <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
From: joel jaeggli 
x-enigmail-draft-status: N1110
message-id: <55374092.9000406@bogus.com>
Date: Tue, 21 Apr 2015 23:32:50 -0700
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0
mime-version: 1.0
in-reply-to: <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rQqIIsgoBXuuU4I2m2pgxcHXve4vu2AJD"
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 06:34:22 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--rQqIIsgoBXuuU4I2m2pgxcHXve4vu2AJD
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 4/21/15 11:20 PM, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.

not a transit provider so I'm sitting in the edge that said I have some
exposure to this problem space.

hence

https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/

> What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always in the same plac=
e
> in the packet, so that hardware can look at them for the purposes of
> dropping them in hardware or as inputs into LB. Is that the case?
>=20
> What I'm curious about then is how do you handle DDoSes that are using
> IP fragments, where there are no TCP or UDP headers ports to look at?

https://datatracker.ietf.org/doc/draft-taylor-v6ops-fragdrop/

> I'm also curious about how you LB packets (either at layer 2 or layer 3=
)
> that don't have TCP or UDP headers, or aren't IP. I've seen LB become
> completely ineffective at layer 2 because a customer was using MPLS
> between two routers, so no MAC address variation, and no IP addresses
> and no TCP or UDP ports to look at.

as someone who does stateless l3+l4 loadbalancing to servers, if I can't
find the l4 header in an asic based forwarding engine even if a server
can I have problem.

> In fact, given the trouble LAG has caused me in the past 2 years (LAG
> member links that are not current members are supposed to be considered=

> by the bridge as normal bridge ports, so if you want to avoid loops
> across the links that are candidate members of the LAG, the IEEE expect=

> you to be running STP of some form across them...), I'm a big fan of th=
e
> quote on the last slide of this presentation:
>=20
> "IEEE 802.3ad Link Aggregation (LAG) what it is, and what it is not"
> http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf
>=20
>=20
> "LAG is good, but it=92s not as good as a fatter pipe."
>=20
>=20
> -----------------------------------------------------------------------=
-
> *From:* Nick Hilliard 
> *To:* v6ops@ietf.org
> *Sent:* Wednesday, 22 April 2015, 2:56
> *Subject:* Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world:
> clarification text
>=20
> On 21/04/2015 16:51, Gert Doering wrote:
>> I'm fully at a loss to express my amazement in polite words, so I'm ju=
st
>> *out* of this discussion now.
>=20
> Fully agreed on this + that this thread needs to end.  The lack of
> operational reality being displayed is pretty severe.
>=20
> Nick
>=20
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org 
> https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20



--rQqIIsgoBXuuU4I2m2pgxcHXve4vu2AJD
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

iEYEARECAAYFAlU3QJMACgkQ8AA1q7Z/VrJn+wCfc9AywYiQex5T9AYq7EBhc8MH
5X4AniqmwrbfHBYsilJiQnKQLPrS2QsE
=UvPy
-----END PGP SIGNATURE-----

--rQqIIsgoBXuuU4I2m2pgxcHXve4vu2AJD--


From nobody Tue Apr 21 23:41: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 48FAF1B31AF for ; Tue, 21 Apr 2015 23:41:02 -0700 (PDT)
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 2Jlj1YJWPO4P for ; Tue, 21 Apr 2015 23:41:00 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 8C5C21B31CF for ; Tue, 21 Apr 2015 23:40:58 -0700 (PDT)
Received: (qmail 82241 invoked from network); 22 Apr 2015 06:40:56 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Apr 2015 06:40:56 -0000
Date: Wed, 22 Apr 2015 08:40:56 +0200 (CEST)
Message-Id: <20150422.084056.74672865.sthaug@nethelp.no>
To: touch@isi.edu
From: sthaug@nethelp.no
In-Reply-To: <55369B2D.80906@isi.edu>
References: <553696EC.4060207@isi.edu> <55369855.1040101@joelhalpern.com> <55369B2D.80906@isi.edu>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, merike@doubleshotsecurity.com, fgont@si6networks.com
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 06:41:02 -0000



> There needs to be a balance between what's expensive and inconvenient
> vs. neutering a protocol to make it easy to implement.

Here we actually agree on the basic principle - but probably not on
where that balance point is.

> Protecting the control plane can be done by the receiving host
> (destination router).

This is a fundamental disagreement. Protecting the control plane needs
to be done by *all* intermediate routers in today's somewhat hostile
Internet environment. That also includes some traffic not explicitly
addressed to the routers themselves (for instance traceroute to a
destination reached *through* the routers). Only looking at traffic
addressed to the routers themselves is not sufficient.

> Protecting the network as a whole is useful, and may involve some level
> of DPI - or may not. If the traffic is encrypted, then only the
> destination router can protect itself anyway. But dropping the packets
> because of EH use just makes the filtering router an attacker to the E2E
> communication between the routers.

We have some services that are available within our AS, and should not
be available outside the AS. One such example is DNS resolvers (there
are others). We have chosen to block such services at the border - by
having the border routers explicitly blocking UDP/TCP port 53 to the
resolver addresses. This obviously means the border routers must be
able to *find* the UDP/TCP header in that part of the IPv6 packet they
are able to inspect at line rate. This is not "DPI" in any sense of
the word - it is very basic filtering.

And here, I assume, is the next disagreement. If the UDP/TCP headers
cannot be found because IPv6 EHs have pushed them beyond what the
routers can inspect at line rate - the packet will be dropped.

If we can get improved filtering capabilities in our routers as part
of regular equipment upgrade cycles - great, everybody is happy. But
we are not likely to buy significantly more expensive routers *just*
to be able to peek further into the packets (number of customers
needing this are *many* orders of magnitude too low - if they exist
at all).

Steinar Haug, AS 2116


From nobody Tue Apr 21 23:43: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 C898E1B31DF for ; Tue, 21 Apr 2015 23:43:02 -0700 (PDT)
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 X-tsXLUhmN3g for ; Tue, 21 Apr 2015 23:43:00 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 652C41B31E4 for ; Tue, 21 Apr 2015 23:42:59 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 3F0EF3D0B3; Wed, 22 Apr 2015 08:42:57 +0200 (CEST)
Date: Wed, 22 Apr 2015 08:42:56 +0200 (CEST)
Message-Id: <20150422.084256.499078269.he@uninett.no>
To: touch@isi.edu
From: Havard Eidnes 
In-Reply-To: <5536709B.1050001@isi.edu>
References: <55356F68.1020605@isi.edu> <20150421064811.GG54385@Space.Net> <5536709B.1050001@isi.edu>
X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, merike@doubleshotsecurity.com, fgont@si6networks.com
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 06:43:02 -0000

> DDOS filtering is a feature, not a requirement.

Reality dictates otherwise.

- H=E5vard


From nobody Tue Apr 21 23:46: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 85D841B31F2 for ; Tue, 21 Apr 2015 23:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.502
X-Spam-Level: 
X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 CxauOL8Ijt3m for ; Tue, 21 Apr 2015 23:46:10 -0700 (PDT)
Received: from nm39-vm5.bullet.mail.bf1.yahoo.com (nm39-vm5.bullet.mail.bf1.yahoo.com [72.30.239.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1A21B31C6 for ; Tue, 21 Apr 2015 23:46:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429685169; bh=58b0SnxOuq7gxlfJ5TsEvOrLcj3qh21MENkd0MKe408=;  h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject;  b=rmge1q8rgwlub2939TTe3NjHfFOYgFxaD9etCgzVIz0/1a+GH0IyrbOy+c3TtOlSPgp/qoOKv5Ey4lY5bWNstyup877MQT9NPC+1bG+mvMoAQqJxorUVmwmhYB+VNXp52hV+oIJZ6kT1lmjhWfFgXme5m8xNe7cRV7cXBKiswUQiksUvK7dYDWHy5UZh9Y3/RrIWsePjSn1VKmvSv7HAv9PxrsUQQe6h9WtihaBf0meIZ+6RR5JLrFBelqEFIkhoyoy5xOSpKEffcE61NYOa/VYodgjb/TdLuNtMPamQKC5xMfAcQpgFAByc5PPjksIbXxWiFrASAnp7ek/61dLujA==
Received: from [98.139.170.181] by nm39.bullet.mail.bf1.yahoo.com with NNFMP;  22 Apr 2015 06:46:09 -0000
Received: from [98.139.212.200] by tm24.bullet.mail.bf1.yahoo.com with NNFMP;  22 Apr 2015 06:46:09 -0000
Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 22 Apr 2015 06:46:09 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 599523.29243.bm@omp1009.mail.bf1.yahoo.com
X-YMail-OSG: B.3zZF0VM1lHQXoe.dGnW7V7dZ7UQ0JV_Ersce39KGo7l6_VssO0lyXx3PRVRZv HwG5YRs3L2x5M37atR6DxbBQuUGaipw6AL5ghWwpaJUx0HZRfuIabDtur_dFlLvA_xZnrFTtI0Ri ghyK7suQ0UtEwJwdpl01v_e5bjXg4I97y.tiVuC6AmmISolwL7KYYMicO_MH5Dp9XWFgmz_8Ma0d 10E1DT.kSZEGIeaUFCqxaok79eyOCcpyRtg04sJlns0tk06QoWTrkbntk.TUxd3vBVB93STYAe3p RntEJ8BCMTOOLAMYs5H1Wt6aGNASVndTdvGq.0iT57vnaMLa8OulcznrN0cWPZCyEbJQYsw1Lgwl 3yyi1vky1Ddq2V6UTG9sQ8NydxsIziMIDjtKalPIwpmhgZYZcWhL4WR8snUHy_MOiOIpLaEIqhXR d38SfySZ8E.Mr_5C6PABH4I4OoxEEAY5ucogETNHhSDfuOkdIOBwNReAgHLnQ3C0qTnzsQ5Erz1W tmwLgxKfncf8wqedGYhDhRW8cVImQgdvE8TL4QDVDu_I6jD0C
Received: by 66.196.80.122; Wed, 22 Apr 2015 06:46:09 +0000 
Date: Wed, 22 Apr 2015 06:46:08 +0000 (UTC)
From: Mark ZZZ Smith 
To: joel jaeggli , Nick Hilliard ,  "v6ops@ietf.org" 
Message-ID: <1358113193.2147388.1429685168609.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <55374092.9000406@bogus.com>
References: <55374092.9000406@bogus.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_2147387_539950581.1429685168603"
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
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, 22 Apr 2015 06:46:12 -0000

------=_Part_2147387_539950581.1429685168603
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So I wasn't naively asking those questions, I know what the answers were li=
kely to be.
What I'd really like is for people to actually say what they want, which I =
think is an Internet with packets that look like
[IPv6 Fixed Hdr][TCP Hdr], total size <=3D 1280[IPv6 Fixed Hdr][UDP Hdr], t=
otal size <=3D 1280
and that is it.
The consequence would be to deprecate many existing protocols and making th=
em work over fragment unnecessary TCP or UDP.
I'd think OSPF is probably the most important one to start with.


      From: joel jaeggli 
 To: Mark ZZZ Smith ; Nick Hilliard ; "v6ops@ietf.org" =20
 Sent: Wednesday, 22 April 2015, 16:32
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarificatio=
n text
  =20
On 4/21/15 11:20 PM, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.

not a transit provider so I'm sitting in the edge that said I have some
exposure to this problem space.

hence

https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/

> What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always in the same place
> in the packet, so that hardware can look at them for the purposes of
> dropping them in hardware or as inputs into LB. Is that the case?
>=20
> What I'm curious about then is how do you handle DDoSes that are using
> IP fragments, where there are no TCP or UDP headers ports to look at?

https://datatracker.ietf.org/doc/draft-taylor-v6ops-fragdrop/

> I'm also curious about how you LB packets (either at layer 2 or layer 3)
> that don't have TCP or UDP headers, or aren't IP. I've seen LB become
> completely ineffective at layer 2 because a customer was using MPLS
> between two routers, so no MAC address variation, and no IP addresses
> and no TCP or UDP ports to look at.

as someone who does stateless l3+l4 loadbalancing to servers, if I can't
find the l4 header in an asic based forwarding engine even if a server
can I have problem.

> In fact, given the trouble LAG has caused me in the past 2 years (LAG
> member links that are not current members are supposed to be considered
> by the bridge as normal bridge ports, so if you want to avoid loops
> across the links that are candidate members of the LAG, the IEEE expect
> you to be running STP of some form across them...), I'm a big fan of the
> quote on the last slide of this presentation:
>=20
> "IEEE 802.3ad Link Aggregation (LAG) what it is, and what it is not"
> http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf
>=20
>=20
> "LAG is good, but it=E2=80=99s not as good as a fatter pipe."
>=20
>=20
> ------------------------------------------------------------------------
> *From:* Nick Hilliard 
> *To:* v6ops@ietf.org
> *Sent:* Wednesday, 22 April 2015, 2:56
> *Subject:* Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world:
> clarification text
>=20
> On 21/04/2015 16:51, Gert Doering wrote:
>> I'm fully at a loss to express my amazement in polite words, so I'm just
>> *out* of this discussion now.
>=20
> Fully agreed on this + that this thread needs to end.=C2=A0 The lack of
> operational reality being displayed is pretty severe.
>=20
> Nick
>=20
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org 
> https://www.ietf.org/mailman/listinfo/v6ops


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



  
------=_Part_2147387_539950581.1429685168603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


So I wasn't naively asking those questions, I know=
 what the answers were likely to be.

What I'd really like is for people to actually say what the=
y want, which I think is an Internet with packets that look like

[IPv6 Fixed Hdr][TCP Hdr], tota=
l size <=3D 1280
[IPv6 Fixed Hdr][UDP Hdr], total size <=3D 1280

and that is it.

The consequence would be to deprecate man=
y existing protocols and making them work over fragment unnecessary TCP or =
UDP.

I'd think OSPF i=
s probably the most important one to start with.



  
 
 
 
   From: joel jaeggli <joelja@bogus.com&g=
t;
 To: Mark ZZZ Smith =
<markzzzsmith@yahoo.com.au>; Nick Hilliard <nick@foobar.org>; "=
v6ops@ietf.org" <v6ops@ietf.org> 
 Sent: Wednesday, 22 April 2015, 16:32
 Subject:  Re: [v6ops] draft-gont-v6ops-i=
pv6-ehs-in-real-world: clarification text
  
 

On 4/21/15 11:=
20 PM, Mark ZZZ Smith wrote:
> So I'm going to call th=
e emperor naked.

not a transit provide=
r so I'm sitting in the edge that said I have some
exposu=
re to this problem space.

hence

https://datatracker.ietf.org/doc/draf=
t-ietf-v6ops-pmtud-ecmp-problem/

&=
gt; What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always =
in the same place
> in the packet, so that hardware ca=
n look at them for the purposes of
> dropping them in =
hardware or as inputs into LB. Is that the case?
> > What I'm curious about then is how do you handle DDoSe=
s that are using
> IP fragments, where there are no TC=
P or UDP headers ports to look at?

https://datatracker.ietf.org/doc/draft-taylor-=
v6ops-fragdrop/

> I'm also curi=
ous about how you LB packets (either at layer 2 or layer 3)
> that don't have TCP or UDP headers, or aren't IP. I've seen LB beco=
me
> completely ineffective at layer 2 because a custo=
mer was using MPLS
> between two routers, so no MAC ad=
dress variation, and no IP addresses
> and no TCP or U=
DP ports to look at.

as someone who do=
es stateless l3+l4 loadbalancing to servers, if I can't
f=
ind the l4 header in an asic based forwarding engine even if a server
can I have problem.

> =
In fact, given the trouble LAG has caused me in the past 2 years (LAG
> member links that are not current members are supposed to=
 be considered
> by the bridge as normal bridge ports,=
 so if you want to avoid loops
> across the links that=
 are candidate members of the LAG, the IEEE expect
> y=
ou to be running STP of some form across them...), I'm a big fan of the
> quote on the last slide of this presentation:
> 
> "IEEE 802.3ad Link Aggregation (LAG)=
 what it is, and what it is not"
> http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pd=
f
> 
> 
>=
; "LAG is good, but it=E2=80=99s not as good as a fatter pipe."
> 
> 
> ---------------=
---------------------------------------------------------
> *From:* Nick Hilliard <nick@foobar.org>
> *To:* v6ops@ietf.org
> *Sen=
t:* Wednesday, 22 April 2015, 2:56
> *Subject:* Re: [v=
6ops] draft-gont-v6ops-ipv6-ehs-in-real-world:
> clari=
fication text
> 
> On 21/04/2015 =
16:51, Gert Doering wrote:
>> I'm fully at a loss t=
o express my amazement in polite words, so I'm just
>&=
gt; *out* of this discussion now.
> 
> Fully agreed on this + that this thread needs to end.  The lack =
of
> operational reality being displayed is pretty sev=
ere.
> 
> Nick
=
> 
> 
> 
>=
; 
> _______________________________________________> v6ops mailing list
> v6o=
ps@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops



> 
> 
&=
gt; 
> 
> _______________________=
________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=
; 



 
 
 =
 

------=_Part_2147387_539950581.1429685168603--


From nobody Wed Apr 22 00:12: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 3259D1B3279 for ; Wed, 22 Apr 2015 00:12:33 -0700 (PDT)
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 hSLCnse2uQZH for ; Wed, 22 Apr 2015 00:12:31 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 560E01B326E for ; Wed, 22 Apr 2015 00:12:28 -0700 (PDT)
Received: (qmail 83612 invoked from network); 22 Apr 2015 07:12:27 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Apr 2015 07:12:27 -0000
Date: Wed, 22 Apr 2015 09:12:27 +0200 (CEST)
Message-Id: <20150422.091227.74668510.sthaug@nethelp.no>
To: markzzzsmith@yahoo.com.au
From: sthaug@nethelp.no
In-Reply-To: <1358113193.2147388.1429685168609.JavaMail.yahoo@mail.yahoo.com>
References: <55374092.9000406@bogus.com> <1358113193.2147388.1429685168609.JavaMail.yahoo@mail.yahoo.com>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 07:12:33 -0000

> So I wasn't naively asking those questions, I know what the answers were likely to be.
> What I'd really like is for people to actually say what they want, which I think is an Internet with packets that look like
> [IPv6 Fixed Hdr][TCP Hdr], total size <= 1280[IPv6 Fixed Hdr][UDP Hdr], total size <= 1280
> and that is it.
> The consequence would be to deprecate many existing protocols and making them work over fragment unnecessary TCP or UDP.

I see no reason to deprecate IPv6 EHs. But I need 

 [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit

in order for the router hardware to be able to filter based on TCP/UDP
headers at line rate. With current equipment, I would expect hardware
inspection limit to be in the range 256 to 1280 bytes.

Steinar Haug, AS 2116


From nobody Wed Apr 22 00:22: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 BCEA51B3295 for ; Wed, 22 Apr 2015 00:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level: 
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 HYdxdpdtots8 for ; Wed, 22 Apr 2015 00:22:53 -0700 (PDT)
Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E571B3263 for ; Wed, 22 Apr 2015 00:22:48 -0700 (PDT)
Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id E888F100E9EF3; Wed, 22 Apr 2015 07:22:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1429687365; bh=yYnK+KSd17RoHAhZSfE5OU9lrwAUmKlHI1HrSVcYifE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=mv7rL3rEIT29YJqhrVOjrFDR3UZAXTNVsCuW1vDwvheN8zmdGr+WIz353LlghhITo ccEAjiRXaFBfDkussl7L1yZGknxU0pgJfDwSrZNsQoFE2ICTGiWJw849hOSkDGhx4C U+w/XnbAPpuULMi9f1PF6+axXyj9zPSaTy8Ym9XLjOOP4nTrR843TmE9+P94iOKtmA l3nUB7ZiUC8MbLbhs/ZEExbEeJkFui6pUejf0JqNnZd6IpaRA+ZxypFpa106UghBRR 8l/i5nydu0DrVizN60/eGhA/vfAgUNPhwdTtwktFSDbzXYsooMyFbZdvq1+XdAZyaK SskWhICbyK5bA==
Message-ID: <55374C42.7030908@massar.ch>
Date: Wed, 22 Apr 2015 09:22:42 +0200
From: Jeroen Massar 
Organization: Massar
MIME-Version: 1.0
To: sthaug@nethelp.no, markzzzsmith@yahoo.com.au
References: <55374092.9000406@bogus.com> <1358113193.2147388.1429685168609.JavaMail.yahoo@mail.yahoo.com> <20150422.091227.74668510.sthaug@nethelp.no>
In-Reply-To: <20150422.091227.74668510.sthaug@nethelp.no>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 07:22:55 -0000

On 2015-04-22 09:12, sthaug@nethelp.no wrote:
>> So I wasn't naively asking those questions, I know what the answers were likely to be.
>> What I'd really like is for people to actually say what they want, which I think is an Internet with packets that look like
>> [IPv6 Fixed Hdr][TCP Hdr], total size <= 1280[IPv6 Fixed Hdr][UDP Hdr], total size <= 1280
>> and that is it.
>> The consequence would be to deprecate many existing protocols and making them work over fragment unnecessary TCP or UDP.
> 
> I see no reason to deprecate IPv6 EHs. But I need 
> 
>  [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit
> 
> in order for the router hardware to be able to filter based on TCP/UDP
> headers at line rate.

The nasty answer to such a statement is: increase your hardware
inspection limit.


But the easier one, that works today is that very likely your DNS
servers recursing IP space is dedicated.

Hence, any packet headed toward those addresses is "private" and should
not get an answer.

Thus, instead of doing filtering on L4, why not just not route those
packets at all (L3)? Don't even have to firewall it.


My printer for instance has a nice global address, but as the border
router does not forward packets from $internet to $printer-net, a
traceroute or anything else ends up in a simple !N.

No per-port inspection needed, just plain old good routing.



Btw, does your hardware-load-balancer inspect ICMPv6 to do stateless
flow routing for ICMPv6 errors to the correct host? Or are you also just
fumbling with ICMPv6 PTBs like Amazon (+NetFlix) & Google?

Greets,
 Jeroen


From nobody Wed Apr 22 00:27: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 D08F81B32B5 for ; Wed, 22 Apr 2015 00:27:16 -0700 (PDT)
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 mU9T6R93VWGb for ; Wed, 22 Apr 2015 00:27:12 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC01E1B329A for ; Wed, 22 Apr 2015 00:27:05 -0700 (PDT)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 57F6D60CC; Wed, 22 Apr 2015 00:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=DHuuXmPDh0j/tMg5mc9+/leqmAE=; b= ekSWO9MzcON2WmlWLuhJEDuJzmx1bIipLQ+z50NeS6MtCUsS6LoQt/651SeZX7A0 GoTwpCCjTLEv9WkVMxoIcfrSDKqoxKEvd41ucWEQ8NkMcnA12qsS2t6Eq7yQOvdC hUe90vU4nFxX7eAWUwj+YDWtJPdcSJcWqgd2LWB1444=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=QMBhf0DQJhT+VP/ccvjKqql9Gx Py6lUQ/i9bNOCeywrWE0eR9gju0YS5A1TM9AqzZztIffhBvczbBL/YDwmnqKT1tH L0AgaiwweywUEwyRKHLxuppuWgPLMg+NF943uOVX3Pj7elqtTAiHZ/ZtVEhUew/n sJVE8mqx/Bf0/leNg=
Received: from gomlefisk.localdomain (unknown [173.38.220.50]) (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 97DFB60B7; Wed, 22 Apr 2015 00:27:03 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 2C07C4305C99; Wed, 22 Apr 2015 09:27:01 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed; boundary="Apple-Mail=_7CB169CF-71FB-4DB2-ACC0-C2E46CD7DBC9"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Ole Troan 
In-Reply-To: <20150422.084056.74672865.sthaug@nethelp.no>
Date: Wed, 22 Apr 2015 09:27:00 +0200
Message-Id: 
References: <553696EC.4060207@isi.edu> <55369855.1040101@joelhalpern.com> <55369B2D.80906@isi.edu> <20150422.084056.74672865.sthaug@nethelp.no>
To: sthaug@nethelp.no
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, fgont@si6networks.com, merike@doubleshotsecurity.com
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 07:27:17 -0000

--Apple-Mail=_7CB169CF-71FB-4DB2-ACC0-C2E46CD7DBC9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Steinar,

>> Protecting the control plane can be done by the receiving host
>> (destination router).
>=20
> This is a fundamental disagreement. Protecting the control plane needs
> to be done by *all* intermediate routers in today's somewhat hostile
> Internet environment. That also includes some traffic not explicitly
> addressed to the routers themselves (for instance traceroute to a
> destination reached *through* the routers). Only looking at traffic
> addressed to the routers themselves is not sufficient.

assuming we=E2=80=99re talking about a transit provider and transit =
traffic.
to help those of us who are lacking operational clue, could you expand =
on the cases where this is necessary?

>> Protecting the network as a whole is useful, and may involve some =
level
>> of DPI - or may not. If the traffic is encrypted, then only the
>> destination router can protect itself anyway. But dropping the =
packets
>> because of EH use just makes the filtering router an attacker to the =
E2E
>> communication between the routers.
>=20
> We have some services that are available within our AS, and should not
> be available outside the AS. One such example is DNS resolvers (there
> are others). We have chosen to block such services at the border - by
> having the border routers explicitly blocking UDP/TCP port 53 to the
> resolver addresses. This obviously means the border routers must be
> able to *find* the UDP/TCP header in that part of the IPv6 packet they
> are able to inspect at line rate. This is not "DPI" in any sense of
> the word - it is very basic filtering.
>=20
> And here, I assume, is the next disagreement. If the UDP/TCP headers
> cannot be found because IPv6 EHs have pushed them beyond what the
> routers can inspect at line rate - the packet will be dropped.

if you drop packets with DA =3D=3D your DNS server where you cannot find =
the L4 information, that seems perfectly fine.
if you drop packets with _any_ DA where you cannot find (or understand) =
the L4 information then you are offering broken service. again talking =
about transit here.
to do the former you don=E2=80=99t need to parse deep into the packet, =
nor deprecate EHs.

> If we can get improved filtering capabilities in our routers as part
> of regular equipment upgrade cycles - great, everybody is happy. But
> we are not likely to buy significantly more expensive routers *just*
> to be able to peek further into the packets (number of customers
> needing this are *many* orders of magnitude too low - if they exist
> at all).

even if you had routers that could parse to the end of the packet, I =
don=E2=80=99t quite see how that =E2=80=9Chelps=E2=80=9D. the =
Internet=E2=80=99s success is to a large extent based on being able to =
route around broken networks, like this would be.

cheers,
Ole

--Apple-Mail=_7CB169CF-71FB-4DB2-ACC0-C2E46CD7DBC9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVN01EAAoJEFuJXizso86g4aQH/imAHQHVgbqRJeMkgyt/CLlw
g8hPbDwJmLe/Y15LxA219QRmY+byij80kF1J7n9eJkmH5jPo85TZlxI5OQmSITAq
vfYnUeiupX56TEmwEEIKeK3cAgRnbB8QtlQl9sMfq/8HHKIV8X15zfHUakHBf0BD
TnyQgexm6HjHEMfqSnU/MSpPvgHhDaGs3zfefE4VdQIEK8/JfR1YphKkkniWWWrC
rDtKW35W7h3INiz/ORzvPkc+KGRJamQuxfDHeNlEjicNUNuLPJbmjpS6uQBnZeT9
WspUOQTSm3BbzQkVJ/EUO6M6jq7jJ4yN5s1c7yEuOEVSgjArvRSEU+bVhlhuIAM=
=PqFL
-----END PGP SIGNATURE-----

--Apple-Mail=_7CB169CF-71FB-4DB2-ACC0-C2E46CD7DBC9--


From nobody Wed Apr 22 00:31: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 B74251B32C2 for ; Wed, 22 Apr 2015 00:31:13 -0700 (PDT)
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 qLwGKRrltfkt for ; Wed, 22 Apr 2015 00:31:11 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 923B61B32DE for ; Wed, 22 Apr 2015 00:31:03 -0700 (PDT)
Received: (qmail 84640 invoked from network); 22 Apr 2015 07:31:02 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Apr 2015 07:31:02 -0000
Date: Wed, 22 Apr 2015 09:31:02 +0200 (CEST)
Message-Id: <20150422.093102.41714241.sthaug@nethelp.no>
To: jeroen@massar.ch
From: sthaug@nethelp.no
In-Reply-To: <55374C42.7030908@massar.ch>
References: <1358113193.2147388.1429685168609.JavaMail.yahoo@mail.yahoo.com> <20150422.091227.74668510.sthaug@nethelp.no> <55374C42.7030908@massar.ch>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 07:31:13 -0000

> > I see no reason to deprecate IPv6 EHs. But I need 
> > 
> >  [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit
> > 
> > in order for the router hardware to be able to filter based on TCP/UDP
> > headers at line rate.
> 
> The nasty answer to such a statement is: increase your hardware
> inspection limit.

And that will probably happen - as part of regular equipment upgrade
cycles.

> But the easier one, that works today is that very likely your DNS
> servers recursing IP space is dedicated.
> 
> Hence, any packet headed toward those addresses is "private" and should
> not get an answer.
> 
> Thus, instead of doing filtering on L4, why not just not route those
> packets at all (L3)? Don't even have to firewall it.

The world is not that simple.

> Btw, does your hardware-load-balancer inspect ICMPv6 to do stateless
> flow routing for ICMPv6 errors to the correct host? Or are you also just
> fumbling with ICMPv6 PTBs like Amazon (+NetFlix) & Google?

Don't have those boxes doing IPv6 in my network.

Steinar Haug, AS 2116


From nobody Wed Apr 22 00: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 E0B4F1B32E1 for ; Wed, 22 Apr 2015 00:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1HPaFK_H5ylK for ; Wed, 22 Apr 2015 00:33:35 -0700 (PDT)
Received: from bastion.ch.unfix.org (citadel.ch.unfix.org [IPv6:2001:1620:20b0::50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B70F1B32DC for ; Wed, 22 Apr 2015 00:33:24 -0700 (PDT)
Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id B299C10038A25; Wed, 22 Apr 2015 07:33:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1429688001; bh=RVm3yIVAVyG1ak8tV7OdIsROxoyADhQ84/S0lkIY63o=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=p3TultB5zwb1iN7SNsrkj5grZUTRaW9pACCjZFatH6lnOaCyTll0d2m59BiDZTk/l 61Y7r/ooUacwK0CzfsGC0FsWEtFqp3kuxLC6G3Dx7JcJnGXFknXEyTMqbpdMMbTsBj 4aYqjCuukVN0mrVHG+1WpIP84X+zx4nzzJMw7vgAE65lzXhm0SmIwunFS+1TiFgzLn eL9sh2BfwFCTfK+6aiMi8qmgXjV4gtrigJgaFmPGuKhyfYJfXPpLKFuRzMr/gV9sRG Tdz6u9Z/VnkpOj6CU4p9qr+UEWk/k3MgTLeMehnecEdThgP5K/YY8kWfO2z5XScYvP LNhhB9D/wFa1g==
Message-ID: <55374EC1.2020708@massar.ch>
Date: Wed, 22 Apr 2015 09:33:21 +0200
From: Jeroen Massar 
Organization: Massar
MIME-Version: 1.0
To: sthaug@nethelp.no
References: <1358113193.2147388.1429685168609.JavaMail.yahoo@mail.yahoo.com>	<20150422.091227.74668510.sthaug@nethelp.no>	<55374C42.7030908@massar.ch> <20150422.093102.41714241.sthaug@nethelp.no>
In-Reply-To: <20150422.093102.41714241.sthaug@nethelp.no>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 07:33:37 -0000

On 2015-04-22 09:31, sthaug@nethelp.no wrote:
>>> I see no reason to deprecate IPv6 EHs. But I need 
>>>
>>>  [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit
>>>
>>> in order for the router hardware to be able to filter based on TCP/UDP
>>> headers at line rate.
>>
>> The nasty answer to such a statement is: increase your hardware
>> inspection limit.
> 
> And that will probably happen - as part of regular equipment upgrade
> cycles.

Changing a protocol that is trying be deployed for 20+ years already is
not going to happen quicker than the above ;)

>> But the easier one, that works today is that very likely your DNS
>> servers recursing IP space is dedicated.
>>
>> Hence, any packet headed toward those addresses is "private" and should
>> not get an answer.
>>
>> Thus, instead of doing filtering on L4, why not just not route those
>> packets at all (L3)? Don't even have to firewall it.
> 
> The world is not that simple.

Then please define the real problem you are trying to solve.

Your statement was that you have a private DNS server that you do not
want reachable from the outside.

Hence, not routing packets from $outside solves your problem.

Greets,
 Jeroen


From nobody Wed Apr 22 01:51:45 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 5B2871B317F for ; Wed, 22 Apr 2015 01:51:44 -0700 (PDT)
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 lpf_WWHF16TJ for ; Wed, 22 Apr 2015 01:51:42 -0700 (PDT)
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 E640B1B2F65 for ; Wed, 22 Apr 2015 01:51:41 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A18AA608A5 for ; Wed, 22 Apr 2015 10:51:39 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2DD2E60A3F for ; Wed, 22 Apr 2015 10:51:39 +0200 (CEST)
Received: (qmail 64891 invoked by uid 1007); 22 Apr 2015 10:51:38 +0200
Date: Wed, 22 Apr 2015 10:51:38 +0200
From: Gert Doering 
To: Mark ZZZ Smith 
Message-ID: <20150422085138.GE54385@Space.Net>
References: <5536814D.7030708@foobar.org> <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 08:51:44 -0000

Hi,

On Wed, Apr 22, 2015 at 06:20:00AM +0000, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.
> What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always in the same
> place in the packet, so that hardware can look at them for the
> purposes of dropping them in hardware or as inputs into LB. Is that
> the case?

No :-) - Hardware *is* sophisticated today, but only up to a certain limit.

What I think would be implementable with reasonable tradeoffs between
"unsane hardware effort that my end customers are not going to pay" and
"still flexible" is to require that the final EH is contained in the 
first  bytes (say, 512) and that the final header must be in the 
first fragment.

Right now, we have "the packet can have any size, and the final header can
be anywhere" - and doing that in hardware is just too expensive.

> What I'm curious about then is how do you handle DDoSes that are
> using IP fragments, where there are no TCP or UDP headers ports to
> look at?

That is actually quite easy: rate-limit fragments against the control plane, 
and drop first fragments if there is no L4 header inside.

(The thing is: not all packets are equal - for some, like ICMP, you want
to permit them towards the control plane up to a certain limit - say, 
10 Mbit/s, sufficient to permit people to do network testing, but not 
to overwhelm your control plane link or CPU.  For others, like BGP from
established peers, you take what they give you, because it speeds up 
convergence.  BGP SYNs, rate-limit.  And so on)

> I'm also curious about how you LB packets (either at layer 2 or
> layer 3) that don't have TCP or UDP headers, or aren't IP. I've
> seen LB become completely ineffective at layer 2 because a customer
> was using MPLS between two routers, so no MAC address variation,
> and no IP addresses and no TCP or UDP ports to look at.

This is actually a hard problem in the generic case.  If the hardware can
find reasonable discriminators, you can hash based on that (like, MAC 
addresses in Ethernet-over-MPLS packets) - if not, fall back to flow label
or "src/dst MAC address", which is usually a spectacularily bad idea 
between routers.

[..]
> "LAG is good, but it???s not as good as a fatter pipe."

True.  But sometimes life is not nice, and you have to live with what
you have - like, you can get 2x 10G wavelength between cities, but not
40G or 100G, or your equipment just cannot handle 40G/100G.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Wed Apr 22 01:56: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 429681B31D3 for ; Wed, 22 Apr 2015 01:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qBYA9NNaW-Vj for ; Wed, 22 Apr 2015 01:56:00 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E201B31CC for ; Wed, 22 Apr 2015 01:55:59 -0700 (PDT)
Received: from [85.158.136.3] by server-10.bemta-5.messagelabs.com id F0/17-21049-D1267355; Wed, 22 Apr 2015 08:55:57 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-10.tower-123.messagelabs.com!1429692956!40660912!1
X-Originating-IP: [149.254.241.76]
X-StarScan-Received: 
X-StarScan-Version: 6.13.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10008 invoked from network); 22 Apr 2015 08:55:57 -0000
Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-10.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  22 Apr 2015 08:55:57 -0000
Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Wed, 22 Apr 2015 09:55:53 +0100
Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Wed, 22 Apr 2015 09:55:49 +0100
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 09:55:16 +0100
From: "Heatley, Nick" 
To: James Woodyatt , Xing Li 
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYtCVneMUqIFM3UWKOHw0TbKROp0lUOcAgAA3nwCAA2c/gIABUuaAgAFbCwCAABVpgIAAAIqAgAAPA4CAAAtsAIAAbkKAgAGv2wCAABSlgIAA/X4AgAAHmQCAAFthgIAL+9OAgAADYgCAAtG/AIAB4f6AgAD7QgCAAMs5AIAF7pkAgAOeT4CADJ5Bd4AA3PKg
Date: Wed, 22 Apr 2015 08:55:16 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <5536776A.9060204@cernet.edu.cn> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.246.208.5]
Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303E8C63AUK30S005EXS06EE_"
MIME-Version: 1.0
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 08:56:03 -0000

--_000_6536E263028723489CCD5B6821D4B21303E8C63AUK30S005EXS06EE_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SW4gdGhlIGV2ZW50IHRoYXQgdGhlcmUgaXMgb25seSBvbmUgT1MgZWNvc3lzdGVtIGF0IHRoZSBw
YXJ0eSB0aGF0IGRvZXNu4oCZdCBzdXBwb3J0IHRoZSBJUHY0LXNvY2tldCB0cmFuc2l0aW9uLCB3
aGF0IHN0b3J5IHdpbGwgdGhleSB0ZWxsPw0KSW4gdGhhdCBzY2VuYXJpbywgSSBkb27igJl0IHNl
ZSB0aGVyZSBpcyBhIGdyZWF0IGN1c3RvbWVyIHN0b3J5IHRoZXJlIChzdHVjayBydW5uaW5nIGEg
bGVnYWN5IHByb3RvY29sIGFzIHRyYW5zcG9ydC9iZWluZyBkaXNjb25uZWN0ZWQgZnJvbSBsaXRl
cmFscykuDQpTaW1wbHkgcG9pbnRpbmcgYXQgdGhlIG90aGVyIHBhcnR5IGd1ZXN0cyBhbmQgc2F5
aW5nIHRoZXkgc2hvdWxkIGhhdmUgZG9uZSBtb3JlIHRvIHJlbW92ZSB0aGUgcHJvYmxlbSBpbiB0
aGUgZmlyc3QgcGxhY2UgaXNu4oCZdCBnb2luZyB0byBjdXQgaXQgSU1PLCB3aGVuIHRoZXJlIGlz
IGEgZml4IGluIHRoZWlyIE9TIHRoYXQgdGhleSBjb3VsZCB3b3JrIG9uLg0KRnJvbSBhIHNtYXJ0
cGhvbmUvdGFibGV0IHBlcnNwZWN0aXZlIHRoYXQgaXMgbG9va2luZyBhIGxpa2VseSBzY2VuYXJp
by4NCg0KV2hhdCBJIGJlbGlldmUgdG8gYmUgdHJ1ZSBmb3IgbW9iaWxlOiB0aGUgZGlzZWFzZSBp
cyBJUHY0IGxpdGVyYWxzLCBpdCBjYW5ub3QgYmUgZXJhZGljYXRlZCwgZ28gaW1tdW5pc2UgdGhl
IE9TLg0KDQooSW4gdGhlIG1vYmlsZSBjb25zdW1lciBjYXNlLCBJIGRvbuKAmXQgaGF2ZSBhbiBp
c3N1ZSB3aXRoIElQdjQtbGl0ZXJhbHMgZmFpbGluZyBwZXIgc2UsIEkgaGF2ZSBhbiBpc3N1ZSB3
aXRoIElQdjQtbGl0ZXJhbHMgZmFpbGluZyBhbmQgY3VzdG9tZXJzIHRoaW5raW5nIGl0IGlzIG15
IG5ldHdvcmsgYW5kIHJpbmdpbmcgbXkgaGVscGxpbmVzLg0KSWYgYnJvd3NlcnMgcmVkaXJlY3Rl
ZCB0aGVzZSBmYWlscyB0byBhIHBhZ2UgdGhhdCBzYWlkIOKAnElQdjQgbGl0ZXJhbCBwcm9ibGVt
IGVuY291bnRlcmVkIC0gcmluZyB2ZW5kb3IgQeKAnSB0aGVuIHRoYXQgd291bGQgYmUgZmluZSBi
eSBtZS4gQSBmb29saXNoIGlkZWE/IFdlbGwsIGl0IGJvaWxzIGRvd24gdG8gdGFrZSBzb21lIG93
bmVyc2hpcCwgYW5kIGRvbuKAmXQgcGVuYWxpc2Ugb3BlcmF0b3JzIHRha2luZyB0aGUgbGVhZCEg
SVB2Ni1vbmx5IHRyYW5zcG9ydCBoYXMgdG8gYmUgdGhlIHRhcmdldCwgd2UgYWxsIGtub3cgdGhp
cy4pDQoNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgSmFtZXMgV29vZHlhdHQNClNlbnQ6IDIxIEFwcmlsIDIwMTUgMjA6MDINClRvOiBY
aW5nIExpDQpDYzogSVB2NiBPcHMgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNdIFRoZSBuZWVkIGZv
ciBsb2NhbC1pcHY0IHNvY2tldCB0cmFuc2l0aW9uIHNvbHV0aW9ucyAtLSBOQVQ2NC9ETlM2NCBy
ZW1haW5zIGluc3VmZmljaWVudA0KDQpPbiBUdWUsIEFwciAyMSwgMjAxNSBhdCA5OjE0IEFNLCBY
aW5nIExpIDx4aW5nQGNlcm5ldC5lZHUuY248bWFpbHRvOnhpbmdAY2VybmV0LmVkdS5jbj4+IHdy
b3RlOg0KDQooMSkgSWYgdGhlIGhvc3Qgc3lzdGVtIGNhbiBub3QgZG8gUkZDNjE0NSwgdGhlIGFk
ZGl0aW9uYWwgQ1BFIGlzDQpyZXF1aXJlZCB0byBkbyBzbywgYW5kIHRoYXQgYWxzbyBrZWVwcyB0
aGUgSVB2NCBsaXRlcmFscyBvbiB0aGUgSW50ZXJuZXQNCmZvcmV2ZXIuDQoNCkkgd291bGRuJ3Qg
Y2hhcmFjdGVyaXplIGl0IGxpa2UgdGhhdC4gSSB0aGluayB3aGF0IHlvdSBtZWFuIHRvIHNheSBp
cyB0aGlzOiBiZWNhdXNlIHN1cHBvcnQgZm9yIElQdjQgbGl0ZXJhbHMgY2FuIG5ldmVyIGJlIHJl
bW92ZWQgZnJvbSB0aGUgSW50ZXJuZXQsIGhvc3RzIG11c3QgZWl0aGVyIGJlIHByb3ZpZGVkIHdp
dGggSVB2NCBzZXJ2aWNlIGZvcmV2ZXIgb3IgYWxsIHRoZSBob3N0cyBvbiB0aGUgSW50ZXJuZXQg
bXVzdCBiZSB1cGdyYWRlZCB0byBzdXBwb3J0IHRoZSBDTEFUIGZ1bmN0aW9uIGluIDQ2NFhMQVQu
IE15IHBvaW50IGlzIHRoYXQgeW91IGNhbid0IHJlcXVpcmUgYWxsIHRoZSBob3N0cyB0byBiZSB1
cGdyYWRlZCB3aXRoIENMQVQgZnVuY3Rpb25zIGFueSBtb3JlIHRoYW4geW91ciByZXF1aXJlIGFs
bCB0aGUgYXBwbGljYXRpb25zIHRvIHN0b3AgdXNpbmcgSVB2NCBsaXRlcmFscyBldmVyeXdoZXJl
LiBZb3UgYXJlIGxlZnQgd2l0aCBleGFjdGx5IG9uZSBhbHRlcm5hdGl2ZTogeW91IG11c3Qgc3Vw
cG9ydCBJUHY0IGZvcmV2ZXIsIGFuZCB0aGlzIGlzIG5vdCBiZWNhdXNlIGhvc3RzIGRvbid0IGhh
dmUgQ0xBVCBmdW5jdGlvbnMsIGJ1dCBlbnRpcmVseSBiZWNhdXNlIHlvdSBjYW5ub3QgYWJpZGUg
YnJlYWtpbmcgYW55IG9mIHRoZSBhcHBsaWNhdGlvbnMgdG9kYXkgdGhhdCB1c2UgSVB2NCBsaXRl
cmFscy4NCg0KU2hvcnRlciBqYW1lczogeW91ciBwcm9ibGVtIGlzIHRoZSBJUHY0IGxpdGVyYWxz
LiBJZiB5b3UgY2FuJ3QgaWdub3JlIHRoZW0sIGFuZCB5b3UgY2FuJ3QgZG8gYW55dGhpbmcgZWxz
ZSBhYm91dCB0aGVtLCB0aGVuIHlvdSBjYW4ndCBkZXBsb3kgSVB2Ni1vbmx5LiBJdCdzIHJlYWxs
eSB0aGF0IHNpbXBsZS4NCg0KKDIpIE5vIElTUCB3aWxsIGRlcGxveSB0aGUgSVB2Ni1vbmx5IG5l
dHdvcmssIGlmIHRoZSBlbmQgdXNlcnMgY2Fubm90DQphY2Nlc3MgdGhlIHdlYnNpdGVzIHdpdGgg
SVB2NCBsaXRlcmFscy4NCg0KSSBkb24ndCBoYXZlIGEgcHJvYmxlbSB3aXRoIHRoYXQuIEkndmUg
YmVlbiBzYXlpbmcgYWxsIGFsb25nIHRoYXQgSVNQcyBzaG91bGQgbm90IGJlIGluIGFueSBodXJy
eSB0byB0dXJuIG9mZiBJUHY0IHNlcnZpY2UgdG8gQ1BFIGRldmljZXMgY29tcGxldGVseS4NCg0K
LS0NCmphbWVzIHdvb2R5YXR0IDxqaHdAbmVzdGxhYnMuY29tPG1haWx0bzpqaHdAbmVzdGxhYnMu
Y29tPj4NCk5lc3QgTGFicywgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcNCg0KTk9USUNFIEFO
RCBESVNDTEFJTUVSDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMg
aW50ZW5kZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuICBJZiB5b3UgYXJlIG5vdCB0
aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZGVs
ZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRpc2Nsb3NlIG9yIHVz
ZSBmb3IgYW55IHB1cnBvc2UuICANCiANCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBhbmQg
b3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZl
IHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFy
ZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmlsaXR5
IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91LiANCg0K
RUUgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFueSBSZWdp
c3RlcmVkIE51bWJlcjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRl
bnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJX
Lg0K

--_000_6536E263028723489CCD5B6821D4B21303E8C63AUK30S005EXS06EE_
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
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0
IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+SW4gdGhlIGV2ZW50IHRoYXQgdGhlcmUgaXMgb25seSBvbmUgT1MgZWNv
c3lzdGVtIGF0IHRoZSBwYXJ0eSB0aGF0IGRvZXNu4oCZdCBzdXBwb3J0IHRoZSBJUHY0LXNvY2tl
dCB0cmFuc2l0aW9uLCB3aGF0IHN0b3J5IHdpbGwgdGhleSB0ZWxsPzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5JbiB0aGF0IHNjZW5hcmlvLCBJIGRvbuKAmXQgc2VlIHRoZXJlIGlzIGEg
Z3JlYXQgY3VzdG9tZXIgc3RvcnkgdGhlcmUgKHN0dWNrIHJ1bm5pbmcgYSBsZWdhY3kgcHJvdG9j
b2wgYXMgdHJhbnNwb3J0L2JlaW5nIGRpc2Nvbm5lY3RlZCBmcm9tIGxpdGVyYWxzKS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2ltcGx5IHBvaW50aW5nIGF0IHRoZSBvdGhlciBwYXJ0
eSBndWVzdHMgYW5kIHNheWluZyB0aGV5IHNob3VsZCBoYXZlIGRvbmUgbW9yZSB0byByZW1vdmUg
dGhlIHByb2JsZW0gaW4gdGhlIGZpcnN0IHBsYWNlIGlzbuKAmXQgZ29pbmcgdG8gY3V0IGl0IElN
Tywgd2hlbiB0aGVyZQ0KIGlzIGEgZml4IGluIHRoZWlyIE9TIHRoYXQgdGhleSBjb3VsZCB3b3Jr
IG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gcm9tIGEgc21hcnRwaG9uZS90YWJs
ZXQgcGVyc3BlY3RpdmUgdGhhdCBpcyBsb29raW5nIGEgbGlrZWx5IHNjZW5hcmlvLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+V2hhdCBJIGJlbGlldmUgdG8gYmUgdHJ1ZSBmb3IgbW9iaWxlOiB0aGUgZGlzZWFzZSBpcyBJ
UHY0IGxpdGVyYWxzLCBpdCBjYW5ub3QgYmUgZXJhZGljYXRlZCwgZ28gaW1tdW5pc2UgdGhlIE9T
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+KEluIHRoZSBtb2JpbGUgY29uc3VtZXIgY2FzZSwgSSBkb27igJl0IGhhdmUg
YW4gaXNzdWUgd2l0aCBJUHY0LWxpdGVyYWxzIGZhaWxpbmcgcGVyIHNlLCBJIGhhdmUgYW4gaXNz
dWUgd2l0aCBJUHY0LWxpdGVyYWxzIGZhaWxpbmcgYW5kIGN1c3RvbWVycyB0aGlua2luZyBpdA0K
IGlzIG15IG5ldHdvcmsgYW5kIHJpbmdpbmcgbXkgaGVscGxpbmVzLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5JZiBicm93c2VycyByZWRpcmVjdGVkIHRoZXNlIGZhaWxzIHRvIGEgcGFn
ZSB0aGF0IHNhaWQg4oCcSVB2NCBsaXRlcmFsIHByb2JsZW0gZW5jb3VudGVyZWQgLSByaW5nIHZl
bmRvciBB4oCdIHRoZW4gdGhhdCB3b3VsZCBiZSBmaW5lIGJ5IG1lLiBBIGZvb2xpc2ggaWRlYT8g
V2VsbCwNCiBpdCBib2lscyBkb3duIHRvIHRha2Ugc29tZSBvd25lcnNoaXAsIGFuZCBkb27igJl0
IHBlbmFsaXNlIG9wZXJhdG9ycyB0YWtpbmcgdGhlIGxlYWQhIElQdjYtb25seSB0cmFuc3BvcnQg
aGFzIHRvIGJlIHRoZSB0YXJnZXQsIHdlIGFsbCBrbm93IHRoaXMuKTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3Vu
Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYW1lcyBXb29keWF0dDxicj4NCjxi
PlNlbnQ6PC9iPiAyMSBBcHJpbCAyMDE1IDIwOjAyPGJyPg0KPGI+VG86PC9iPiBYaW5nIExpPGJy
Pg0KPGI+Q2M6PC9iPiBJUHY2IE9wcyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3Bz
XSBUaGUgbmVlZCBmb3IgbG9jYWwtaXB2NCBzb2NrZXQgdHJhbnNpdGlvbiBzb2x1dGlvbnMgLS0g
TkFUNjQvRE5TNjQgcmVtYWlucyBpbnN1ZmZpY2llbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDIxLCAyMDE1IGF0IDk6MTQg
QU0sIFhpbmcgTGkgJmx0OzxhIGhyZWY9Im1haWx0bzp4aW5nQGNlcm5ldC5lZHUuY24iIHRhcmdl
dD0iX2JsYW5rIj54aW5nQGNlcm5ldC5lZHUuY248L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDEpIElmIHRoZSBob3N0
IHN5c3RlbSBjYW4gbm90IGRvIFJGQzYxNDUsIHRoZSBhZGRpdGlvbmFsIENQRSBpczxicj4NCnJl
cXVpcmVkIHRvIGRvIHNvLCBhbmQgdGhhdCBhbHNvIGtlZXBzIHRoZSBJUHY0IGxpdGVyYWxzIG9u
IHRoZSBJbnRlcm5ldDxicj4NCmZvcmV2ZXIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkbid0IGNoYXJhY3Rlcml6ZSBpdCBsaWtlIHRoYXQuIEkg
dGhpbmsgd2hhdCB5b3UgbWVhbiB0byBzYXkgaXMgdGhpczogYmVjYXVzZSBzdXBwb3J0IGZvciBJ
UHY0IGxpdGVyYWxzIGNhbiBuZXZlciBiZSByZW1vdmVkIGZyb20gdGhlIEludGVybmV0LCBob3N0
cyBtdXN0IGVpdGhlciBiZSBwcm92aWRlZCB3aXRoIElQdjQgc2VydmljZSBmb3JldmVyIG9yIGFs
bCB0aGUgaG9zdHMgb24gdGhlIEludGVybmV0DQogbXVzdCBiZSB1cGdyYWRlZCB0byBzdXBwb3J0
IHRoZSBDTEFUIGZ1bmN0aW9uIGluIDQ2NFhMQVQuIE15IHBvaW50IGlzIHRoYXQgeW91IGNhbid0
IHJlcXVpcmUgYWxsIHRoZSBob3N0cyB0byBiZSB1cGdyYWRlZCB3aXRoIENMQVQgZnVuY3Rpb25z
IGFueSBtb3JlIHRoYW4geW91ciByZXF1aXJlIGFsbCB0aGUgYXBwbGljYXRpb25zIHRvIHN0b3Ag
dXNpbmcgSVB2NCBsaXRlcmFscyBldmVyeXdoZXJlLiBZb3UgYXJlIGxlZnQgd2l0aCBleGFjdGx5
DQogb25lIGFsdGVybmF0aXZlOiB5b3UgbXVzdCBzdXBwb3J0IElQdjQgZm9yZXZlciwgYW5kIHRo
aXMgaXMgbm90IGJlY2F1c2UgaG9zdHMgZG9uJ3QgaGF2ZSBDTEFUIGZ1bmN0aW9ucywgYnV0IGVu
dGlyZWx5IGJlY2F1c2UgeW91IGNhbm5vdCBhYmlkZSBicmVha2luZyBhbnkgb2YgdGhlIGFwcGxp
Y2F0aW9ucyB0b2RheSB0aGF0IHVzZSBJUHY0IGxpdGVyYWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG9ydGVyIGphbWVzOiB5b3VyIHBy
b2JsZW0gaXMgdGhlIElQdjQgbGl0ZXJhbHMuIElmIHlvdSBjYW4ndCBpZ25vcmUgdGhlbSwgYW5k
IHlvdSBjYW4ndCBkbyBhbnl0aGluZyBlbHNlIGFib3V0IHRoZW0sIHRoZW4geW91IGNhbid0IGRl
cGxveSBJUHY2LW9ubHkuIEl0J3MgcmVhbGx5IHRoYXQgc2ltcGxlLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oMikgTm8gSVNQIHdp
bGwgZGVwbG95IHRoZSBJUHY2LW9ubHkgbmV0d29yaywgaWYgdGhlIGVuZCB1c2VycyBjYW5ub3Q8
YnI+DQphY2Nlc3MgdGhlIHdlYnNpdGVzIHdpdGggSVB2NCBsaXRlcmFscy48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0
IGhhdmUgYSBwcm9ibGVtIHdpdGggdGhhdC4gSSd2ZSBiZWVuIHNheWluZyBhbGwgYWxvbmcgdGhh
dCBJU1BzIHNob3VsZCBub3QgYmUgaW4gYW55IGh1cnJ5IHRvIHR1cm4gb2ZmIElQdjQgc2Vydmlj
ZSB0byBDUEUgZGV2aWNlcyBjb21wbGV0ZWx5LjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+amFtZXMgd29vZHlhdHQgJmx0OzxhIGhyZWY9Im1h
aWx0bzpqaHdAbmVzdGxhYnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+amh3QG5lc3RsYWJzLmNvbTwv
YT4mZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmVzdCBM
YWJzLCBDb21tdW5pY2F0aW9ucyBFbmdpbmVlcmluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KDQo8UD5OT1RJQ0UgQU5EIERJ
U0NMQUlNRVI8QlI+VGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGlu
dGVuZGVkIA0KZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuJm5ic3A7IElmIHlvdSBhcmUg
bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIA0Kbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl
bHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCANCmRpc2Ns
b3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuJm5ic3A7IDxCUj4mbmJzcDs8QlI+V2UgbWF5IG1v
bml0b3IgYWxsIGluY29taW5nIA0KYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3Vy
cmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byANCmVuc3VyZSB0aGF0IHRo
aXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQg
cmVtYWlucyANCnlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBu
b3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIDwvUD4NCjxQPkVFIExpbWl0ZWQ8QlI+UmVnaXN0ZXJl
ZCBpbiBFbmdsYW5kIGFuZCBXYWxlczxCUj5Db21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiANCjAy
MzgyMTYxPEJSPlJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1
aXRvIFdheSwgSGF0ZmllbGQsIA0KSGVydGZvcmRzaGlyZSwgQUwxMCA5Qlc8L1A+DQo8UD4mbmJz
cDs8L1A+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_6536E263028723489CCD5B6821D4B21303E8C63AUK30S005EXS06EE_--


From nobody Wed Apr 22 02:16: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 9C2A21B3349 for ; Wed, 22 Apr 2015 02:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gYhq3MjkhVD for ; Wed, 22 Apr 2015 02:16:01 -0700 (PDT)
Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FD31B32C7 for ; Wed, 22 Apr 2015 02:15:59 -0700 (PDT)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A0E2E25D3A92 for ; Wed, 22 Apr 2015 09:15:57 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id EC0DBC76FCF for ; Wed, 22 Apr 2015 09:15:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id pkARiLpv3xbS for ; Wed, 22 Apr 2015 09:15:55 +0000 (UTC)
Received: from [IPv6:fde9:577b:c1a9:4410:3d50:bfb0:aca:91] (unknown [IPv6:fde9:577b:c1a9:4410:3d50:bfb0:aca:91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1DD9FC76FD7 for ; Wed, 22 Apr 2015 09:15:55 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Bjoern A. Zeeb" 
In-Reply-To: <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK>
Date: Wed, 22 Apr 2015 09:15:23 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <5536776A.9060204@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK>
To: IPv6 Ops WG 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 09:16:02 -0000

> On 22 Apr 2015, at 08:55 , Heatley, Nick  =
wrote:
>=20
> In the event that there is only one OS ecosystem at the party that =
doesn=E2=80=99t support the IPv4-socket transition, what story will they =
tell?

Given the entire =E2=80=9CWinXP is still alive and IPv6 story=E2=80=9D =
the timeframe to put to this is at least half a decade to a decade from =
now.

I think when people here mean =E2=80=9COS=E2=80=9D they often think in =
=E2=80=9Cmobile OS=E2=80=9D but don=E2=80=99t say?


> If browsers redirected these fails to a page that said =E2=80=9CIPv4 =
literal problem encountered - ring vendor A=E2=80=9D then that would be =
fine by me. A foolish idea? Well, it boils down to take some ownership, =
and don=E2=80=99t penalise operators taking the lead! IPv6-only =
transport has to be the target, we all know this.)

See, the thing I like about this thread is, that everybody is trying to =
point their fingers to someone else in order to fix something elsewhere =
but not with themselves or where the &^%$#$%^&*() problem occurs.   =
Anyone saying =E2=80=9Cyou cannot get rid of IPv4 literals=E2=80=9D to =
the extend that it doesn=E2=80=99t bother anyone anymore is mislead.  =
You just have not tried hard enough (probably because you are distracted =
seeking solutions elsewhere).

If everyone complaining here, would work towards getting rid of them =
rather than discussing who=E2=80=99s problem it is to put a workaround =
in place, we=E2=80=99d probably be half-way done.  We have people =
crawling the web, people having users and test networks, people who seem =
to be able to write enough emails on the topic that they could even =
direct it to the right people.

I could even be more adventurous and say:  give them a 90 day notice, =
publish it (that=E2=80=99s the important part, so that yur users hear =
about it as well), and if they don=E2=80=99t get back to you that =
they=E2=80=99ll fix it (timely) break them.  Isn=E2=80=99t that what =
people do with major security bugs?  I=E2=80=99d be surprised if major =
shopping sites and news papers wouldn=E2=80=99t react, once their sales =
and page views go down by a few % over night, but you need to let them =
and their users know upfront.

=E2=80=94=20
Bjoern A. Zeeb                                  Charles Haddon Spurgeon:
"Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend."


From nobody Wed Apr 22 03:20: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 7921B1B33CF for ; Wed, 22 Apr 2015 03:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 MD-dTttyMUI2 for ; Wed, 22 Apr 2015 03:20:30 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0924B1B33CD for ; Wed, 22 Apr 2015 03:20:29 -0700 (PDT)
Received: from [85.158.136.35] by server-1.bemta-5.messagelabs.com id F5/0A-20070-CE577355; Wed, 22 Apr 2015 10:20:28 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-9.tower-125.messagelabs.com!1429698027!34988534!1
X-Originating-IP: [149.254.241.76]
X-StarScan-Received: 
X-StarScan-Version: 6.13.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 683 invoked from network); 22 Apr 2015 10:20:28 -0000
Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-9.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  22 Apr 2015 10:20:28 -0000
Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Wed, 22 Apr 2015 11:20:23 +0100
Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Wed, 22 Apr 2015 11:20:27 +0100
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 11:20:26 +0100
From: "Heatley, Nick" 
To: "Bjoern A. Zeeb" , IPv6 Ops WG 
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYtCVneMUqIFM3UWKOHw0TbKROp0lUOcAgAA3nwCAA2c/gIABUuaAgAFbCwCAABVpgIAAAIqAgAAPA4CAAAtsAIAAbkKAgAGv2wCAABSlgIAA/X4AgAAHmQCAAFthgIAL+9OAgAADYgCAAtG/AIAB4f6AgAD7QgCAAMs5AIAF7pkAgAOeT4CADJ5Bd4AA3PKggAAAeoCAACJCgA==
Date: Wed, 22 Apr 2015 10:20:26 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303E8C7BE@UK30S005EXS06.EEAD.EEINT.CO.UK>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <5536776A.9060204@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net>
In-Reply-To: <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 10:20:32 -0000

DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmpvZXJuIEEuIFplZWINCg0KDQo+IE9uIDIy
IEFwciAyMDE1LCBhdCAwODo1NSAsIEhlYXRsZXksIE5pY2sgPG5pY2suaGVhdGxleUBlZS5jby51
az4gd3JvdGU6DQo+IA0KPiBJbiB0aGUgZXZlbnQgdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSBPUyBl
Y29zeXN0ZW0gYXQgdGhlIHBhcnR5IHRoYXQgZG9lc27igJl0IHN1cHBvcnQgdGhlIElQdjQtc29j
a2V0IHRyYW5zaXRpb24sIHdoYXQgc3Rvcnkgd2lsbCB0aGV5IHRlbGw/DQoNCkdpdmVuIHRoZSBl
bnRpcmUg4oCcV2luWFAgaXMgc3RpbGwgYWxpdmUgYW5kIElQdjYgc3RvcnnigJ0gdGhlIHRpbWVm
cmFtZSB0byBwdXQgdG8gdGhpcyBpcyBhdCBsZWFzdCBoYWxmIGEgZGVjYWRlIHRvIGEgZGVjYWRl
IGZyb20gbm93Lg0KDQpJIHRoaW5rIHdoZW4gcGVvcGxlIGhlcmUgbWVhbiDigJxPU+KAnSB0aGV5
IG9mdGVuIHRoaW5rIGluIOKAnG1vYmlsZSBPU+KAnSBidXQgZG9u4oCZdCBzYXk/DQoNCltIZWF0
bGV5LCBOaWNrXSBObyBJIHNhaWQgZWNvLXN5c3RlbSBub3QgcGxhdGZvcm0gdmVyc2lvbi4gRWFj
aCBlY29zeXN0ZW0gbmVlZHMgYW4gSVB2Ni1vbmx5IHN0b3J5LiBXaGV0aGVyIHRoZXkgdXNlIDQ2
NHhsYXQgb3IgbGV0IGxpdGVyYWxzIGZhaWwsIHRoZXkgbmVlZCBhIHN0b3J5Lg0KDQoNCg0KTk9U
SUNFIEFORCBESVNDTEFJTUVSDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50
cykgaXMgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuICBJZiB5b3UgYXJl
IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs
eSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRpc2Nsb3Nl
IG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuICANCiANCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWlu
ZyBhbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBX
ZSBoYXZlIHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1l
bnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNp
YmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91
LiANCg0KRUUgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFu
eSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6
IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFM
MTAgOUJXLg0K


From nobody Wed Apr 22 03:32: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 3E5FD1B33EA for ; Wed, 22 Apr 2015 03:32:40 -0700 (PDT)
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, 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 kh0lcLwo804Y for ; Wed, 22 Apr 2015 03:32:37 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B706C1A028A for ; Wed, 22 Apr 2015 03:32:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C0A5640332; Wed, 22 Apr 2015 12:32:36 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ_ILZ__Qkif; Wed, 22 Apr 2015 12:32:32 +0200 (CEST)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id B9B4540244; Wed, 22 Apr 2015 12:32:32 +0200 (CEST)
Message-ID: <553778BF.4050706@globis.net>
Date: Wed, 22 Apr 2015 12:32:31 +0200
From: Ray Hunter 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Gert Doering 
References: <5536814D.7030708@foobar.org> <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com> <20150422085138.GE54385@Space.Net>
In-Reply-To: <20150422085138.GE54385@Space.Net>
Content-Type: multipart/alternative; boundary="------------080704020406060300030000"
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 10:32:40 -0000

This is a multi-part message in MIME format.
--------------080704020406060300030000
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



Gert Doering wrote:
> Hi,
>
> On Wed, Apr 22, 2015 at 06:20:00AM +0000, Mark ZZZ Smith wrote:
>> So I'm going to call the emperor naked.
>> What I think you and Gert actually want is for EHs to be completely
>> deprecated, so that the TCP and UDP headers are always in the same
>> place in the packet, so that hardware can look at them for the
>> purposes of dropping them in hardware or as inputs into LB. Is that
>> the case?
>
> No :-) - Hardware *is* sophisticated today, but only up to a certain limit.
>
> What I think would be implementable with reasonable tradeoffs between
> "unsane hardware effort that my end customers are not going to pay" and
> "still flexible" is to require that the final EH is contained in the
> first  bytes (say, 512) and that the final header must be in the
> first fragment.
>
> Right now, we have "the packet can have any size, and the final header can
> be anywhere" - and doing that in hardware is just too expensive.
>
>> What I'm curious about then is how do you handle DDoSes that are
>> using IP fragments, where there are no TCP or UDP headers ports to
>> look at?
>
> That is actually quite easy: rate-limit fragments against the control plane,
> and drop first fragments if there is no L4 header inside.
>
> (The thing is: not all packets are equal - for some, like ICMP, you want
> to permit them towards the control plane up to a certain limit - say,
> 10 Mbit/s, sufficient to permit people to do network testing, but not
> to overwhelm your control plane link or CPU.  For others, like BGP from
> established peers, you take what they give you, because it speeds up
> convergence.  BGP SYNs, rate-limit.  And so on)
>
I do think there's a strong need to differentiate between
i)  packets switched by a device (e.g. normal unicast),
ii) packets switched by a device but which require some local action 
(e.g. replying to an ICMP packet with a hop limit expiry, or processing 
hop by hop options which are anyway an allowable exception in RFC7045), and
iii) packets destined for the device itself as an end host (e.g. BGP 
session).

Which to me suggests that the correct fix to this problem is that a 
hardware vendor worried about control plane performance can introduce a 
queueing mechanism between any fast path switch fabric and any slower 
control plane, in a similar way to implementing WRED or other queuing 
mechanisms on outgoing interfaces. Packets containing "excessive EH" 
would then probably be placed in one of the slow/high drop probability 
queues.

So I really do understand the desire to protect any slow path, but I 
don't see this as an IPv6 protocol issue.

IMHO I think this problem was already fixed at the protocol level by 
https://tools.ietf.org/html/rfc7112

>> I'm also curious about how you LB packets (either at layer 2 or
>> layer 3) that don't have TCP or UDP headers, or aren't IP. I've
>> seen LB become completely ineffective at layer 2 because a customer
>> was using MPLS between two routers, so no MAC address variation,
>> and no IP addresses and no TCP or UDP ports to look at.
>
> This is actually a hard problem in the generic case.  If the hardware can
> find reasonable discriminators, you can hash based on that (like, MAC
> addresses in Ethernet-over-MPLS packets) - if not, fall back to flow label
> or "src/dst MAC address", which is usually a spectacularily bad idea
> between routers.
>
> [..]
>> "LAG is good, but it???s not as good as a fatter pipe."
>
> True.  But sometimes life is not nice, and you have to live with what
> you have - like, you can get 2x 10G wavelength between cities, but not
> 40G or 100G, or your equipment just cannot handle 40G/100G.
>
> Gert Doering
>          -- NetMaster

--------------080704020406060300030000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit







Gert Doering wrote:


  
Hi,

On Wed, Apr 22, 2015 at 06:20:00AM +0000, Mark ZZZ Smith wrote:


  
So I'm going to call the emperor naked.
What I think you and Gert actually want is for EHs to be completely
deprecated, so that the TCP and UDP headers are always in the same
place in the packet, so that hardware can look at them for the
purposes of dropping them in hardware or as inputs into LB. Is that
the case?


  

No :-) - Hardware *is* sophisticated today, but only up to a certain limit.

What I think would be implementable with reasonable tradeoffs between
"unsane hardware effort that my end customers are not going to pay" and
"still flexible" is to require that the final EH is contained in the 
first <n> bytes (say, 512) and that the final header must be in the 
first fragment.

Right now, we have "the packet can have any size, and the final header can
be anywhere" - and doing that in hardware is just too expensive.



  
What I'm curious about then is how do you handle DDoSes that are
using IP fragments, where there are no TCP or UDP headers ports to
look at?


  

That is actually quite easy: rate-limit fragments against the control plane, 
and drop first fragments if there is no L4 header inside.

(The thing is: not all packets are equal - for some, like ICMP, you want
to permit them towards the control plane up to a certain limit - say, 
10 Mbit/s, sufficient to permit people to do network testing, but not 
to overwhelm your control plane link or CPU.  For others, like BGP from
established peers, you take what they give you, because it speeds up 
convergence.  BGP SYNs, rate-limit.  And so on)





I do think there's a strong need to differentiate between

i)  packets 
switched by a device (e.g. normal unicast),

ii) packets switched by a 
device but which require some local action (e.g. replying to an ICMP 
packet with a hop limit 
expiry, or processing hop by hop options which are anyway an allowable 
exception in RFC7045), and

iii) packets destined for the device itself as an end host (e.g. BGP 
session). 



Which to me suggests that the correct fix to this problem is that a 
hardware vendor worried about control plane performance can introduce a 
queueing mechanism between any fast path switch fabric and any slower 
control plane, in a similar way to implementing WRED or other queuing 
mechanisms on outgoing interfaces. Packets containing "excessive EH" 
would then probably be placed in one of the slow/high drop probability 
queues.



So I really do understand the desire to protect any slow path, but I 
don't see this as an IPv6 protocol issue.



IMHO I think this problem was already fixed at the protocol level by 
https://tools.ietf.org/html/rfc7112





  
I'm also curious about how you LB packets (either at layer 2 or
layer 3) that don't have TCP or UDP headers, or aren't IP. I've
seen LB become completely ineffective at layer 2 because a customer
was using MPLS between two routers, so no MAC address variation,
and no IP addresses and no TCP or UDP ports to look at.


  

This is actually a hard problem in the generic case.  If the hardware can
find reasonable discriminators, you can hash based on that (like, MAC 
addresses in Ethernet-over-MPLS packets) - if not, fall back to flow label
or "src/dst MAC address", which is usually a spectacularily bad idea 
between routers.

[..]


  
"LAG is good, but it???s not as good as a fatter pipe."


  

True.  But sometimes life is not nice, and you have to live with what
you have - like, you can get 2x 10G wavelength between cities, but not
40G or 100G, or your equipment just cannot handle 40G/100G.

Gert Doering
        -- NetMaster






--------------080704020406060300030000--


From nobody Wed Apr 22 03:55:40 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 3A24E1B341D for ; Wed, 22 Apr 2015 03:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.502
X-Spam-Level: 
X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 Jht9nuqqDVkp for ; Wed, 22 Apr 2015 03:55:37 -0700 (PDT)
Received: from nm31-vm2.bullet.mail.bf1.yahoo.com (nm31-vm2.bullet.mail.bf1.yahoo.com [72.30.239.10]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B721B341E for ; Wed, 22 Apr 2015 03:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048;  t=1429700128; bh=hrv1lQc7pJmTZ7uzDhOJCBIJhJ5FUS/c4LxePoHvUR4=;  h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject;  b=CXDOYu96Ir6z2iblQQ7Fv43hwOr/fTCU1Fo0M4PopTsxisC2pjcpv5phBoyYk2Jo+pAD6OBvGPZJ25f0XpCT5eitJtahBV+hpC4dI5NzUTSBtgSvpLV52bDdupl7H83sM5YVcLUSV0AN1c/Iq9DDIMJ1j16K9g6Ayi0cqHr6rNE3tWF9IMfEql3Blrn/WUXnEnBuibdifPM7Cm5HbiOZIli5/ypQah5fTtbL41KaICOWZ5ogMMrcsRxTA0w26IXSDbCE+pz0ASk/a5cd4DBgfiCixdT/G5TVtwkT9V4M6OytELcrFrQZDP7UmwDkSEfbYKmQe2J0wZ+/WR3HlqBt9w==
Received: from [66.196.81.174] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 22 Apr 2015 10:55:28 -0000
Received: from [98.139.215.254] by tm20.bullet.mail.bf1.yahoo.com with NNFMP;  22 Apr 2015 10:55:28 -0000
Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 22 Apr 2015 10:55:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 525891.23154.bm@omp1067.mail.bf1.yahoo.com
X-YMail-OSG: LJiQxZ0VM1k3FWvW8EHp63QR.soKbUVtj7G5FppXHEkHGrzZUuqoe3SgtlAz1D5 yVb4t8JLWLM.TJ4UnaRwk7Dh17pHgs59PoDh4bddV.Fddkbn0XFacSFv.8fOhsPL4xRDILeFflY0 vzjcoQtMCr5XJ0XxbeVJpQ7mfaKu..HuGc5hF6jurrUJ0qoKt_.0_iKihddfbuBnFYaQOBsl86wB ggdZvyl0G.ERMm1Ks3Z41EfX2_lNtUARmsrKFOJbuzdYXVmSqh99ZWKQhxy4e58bdlNFbwcwQpGu 3.nuPtbiocNoJsAB2Z.A_drnGLEiThfsKZ_zkZKN2I9CQGFbwq3PzwtlQpbx5Fv3.TaCs_JJYZq7 hm5W1dp0rdthAgfLpnOw1C8qSddhZPCpI_xkrJ1_dm1CPDHpCDOjWhRrkmf8Yj1MW9xrdXyP2HRS yN4fyDgNnMrEBCZXGE9KFEtkzhS951kvvZxRHI03cOiUoc9_pHmVtQgQ5XAc_POvpew_LuqXpL23 XwQ5nmucbc7oIZUvwf2_SSHI4acBxA0st9OChYpPIQOVhOinX
Received: by 76.13.27.132; Wed, 22 Apr 2015 10:55:28 +0000 
Date: Wed, 22 Apr 2015 10:55:26 +0000 (UTC)
From: Mark ZZZ Smith 
To: Gert Doering 
Message-ID: <597629658.2257851.1429700126987.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <20150422085138.GE54385@Space.Net>
References: <20150422085138.GE54385@Space.Net>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_2257850_1895722181.1429700126981"
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
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, 22 Apr 2015 10:55:39 -0000

------=_Part_2257850_1895722181.1429700126981
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


      From: Gert Doering 
 To: Mark ZZZ Smith =20
Cc: Nick Hilliard ; "v6ops@ietf.org" =20
 Sent: Wednesday, 22 April 2015, 18:51
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarificatio=
n text
  =20
Hi,

On Wed, Apr 22, 2015 at 06:20:00AM +0000, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.
> What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always in the same
> place in the packet, so that hardware can look at them for the
> purposes of dropping them in hardware or as inputs into LB. Is that
> the case?

No :-) - Hardware *is* sophisticated today, but only up to a certain limit.

What I think would be implementable with reasonable tradeoffs between
"unsane hardware effort that my end customers are not going to pay" and
"still flexible" is to require that the final EH is contained in the=20
first  bytes (say, 512) and that the final header must be in the=20
first fragment.

/ So would you expect all of your routers to be able to do this level of pr=
ocessing? It seems to me that you'd only need routers that can do that proc=
essing facing potential malicious sources e.g. transit, peering, and possib=
ly customer (although customers have a strong disincentive because it is in=
 their interests for the router to stay available). I wouldn't think it wou=
ld be worth the expense to have this level of hardware filtering available =
on core routers.


Right now, we have "the packet can have any size, and the final header can
be anywhere" - and doing that in hardware is just too expensive.

> What I'm curious about then is how do you handle DDoSes that are
> using IP fragments, where there are no TCP or UDP headers ports to
> look at?

That is actually quite easy: rate-limit fragments against the control plane=
,=20
and drop first fragments if there is no L4 header inside.

(The thing is: not all packets are equal - for some, like ICMP, you want
to permit them towards the control plane up to a certain limit - say,=20
10 Mbit/s, sufficient to permit people to do network testing, but not=20
to overwhelm your control plane link or CPU.=C2=A0 For others, like BGP fro=
m
established peers, you take what they give you, because it speeds up=20
convergence.=C2=A0 BGP SYNs, rate-limit.=C2=A0 And so on)

> I'm also curious about how you LB packets (either at layer 2 or
> layer 3) that don't have TCP or UDP headers, or aren't IP. I've
> seen LB become completely ineffective at layer 2 because a customer
> was using MPLS between two routers, so no MAC address variation,
> and no IP addresses and no TCP or UDP ports to look at.

This is actually a hard problem in the generic case.=C2=A0 If the hardware =
can
find reasonable discriminators, you can hash based on that (like, MAC=20
addresses in Ethernet-over-MPLS packets) - if not, fall back to flow label
or "src/dst MAC address", which is usually a spectacularily bad idea=20
between routers.

[..]
> "LAG is good, but it???s not as good as a fatter pipe."

True.=C2=A0 But sometimes life is not nice, and you have to live with what
you have - like, you can get 2x 10G wavelength between cities, but not
40G or 100G, or your equipment just cannot handle 40G/100G.



Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo=
rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 USt-IdNr.: DE813=
185279


  
------=_Part_2257850_1895722181.1429700126981
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



   
 
 
   From: Gert Doering <gert@space.net>
 To: Mark ZZZ Smith <markzzzsmith@ya=
hoo.com.au> 
Cc: Nic=
k Hilliard <nick@foobar.org>; "v6ops@ietf.org" <v6ops@ietf.org>=
 
 Sent: Wednesday, 22 =
April 2015, 18:51
 Subject:=
 Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification tex=
t
  
 

Hi,

On Wed, Apr 2=
2, 2015 at 06:20:00AM +0000, Mark ZZZ Smith wrote:
> S=
o I'm going to call the emperor naked.
> What I think =
you and Gert actually want is for EHs to be completely
&g=
t; deprecated, so that the TCP and UDP headers are always in the same
> place in the packet, so that hardware can look at them fo=
r the
> purposes of dropping them in hardware or as in=
puts into LB. Is that
> the case?
No :-) - Hardware *is* sophisticated today, but only up to=
 a certain limit.

What I think would b=
e implementable with reasonable tradeoffs between
"unsane=
 hardware effort that my end customers are not going to pay" and
"still flexible" is to require that the final EH is contained in =
the 
first <n> bytes (say, 512) and that the final =
header must be in the 
first fragment.
=

/ So would you expect all of your routers to be able to do this level o=
f processing? It seems to me that you'd only need routers that can do that =
processing facing potential malicious sources e.g. transit, peering, and po=
ssibly customer (although customers have a strong disincentive because it i=
s in their interests for the router to stay available). I wouldn't think it=
 would be worth the expense to have this level of hardware filtering availa=
ble on core routers.


Right now, we have "the pack=
et can have any size, and the final header can
be anywher=
e" - and doing that in hardware is just too expensive.
> What I'm curious about then is how do you handle DDoS=
es that are
> using IP fragments, where there are no T=
CP or UDP headers ports to
> look at?

That is actually quite easy: rate-limit fragments agai=
nst the control plane, 
and drop first fragments if there=
 is no L4 header inside.

(The thing is=
: not all packets are equal - for some, like ICMP, you want
to permit them towards the control plane up to a certain limit - say, 10 Mbit/s, sufficient to permit people to do network testi=
ng, but not 
to overwhelm your control plane link or CPU.=
  For others, like BGP from
established peers, you t=
ake what they give you, because it speeds up 
convergence=
.  BGP SYNs, rate-limit.  And so on)

> I'm also curious about how you LB packets (either at layer 2=
 or
> layer 3) that don't have TCP or UDP headers, or =
aren't IP. I've
> seen LB become completely ineffectiv=
e at layer 2 because a customer
> was using MPLS betwe=
en two routers, so no MAC address variation,
> and no =
IP addresses and no TCP or UDP ports to look at.

This is actually a hard problem in the generic case.  If th=
e hardware can
find reasonable discriminators, you can ha=
sh based on that (like, MAC 
addresses in Ethernet-over-M=
PLS packets) - if not, fall back to flow label
or "src/ds=
t MAC address", which is usually a spectacularily bad idea 
between routers.

[..]
> "LAG is good, but it???s not as good as a fatter pipe."

True.  But sometimes life is not nice, an=
d you have to live with what
you have - like, you can get=
 2x 10G wavelength between cities, but not
40G or 100G, o=
r your equipment just cannot handle 40G/100G.
<=
br>


Gert Doering

    &=
nbsp;   -- NetMaster
-- 
have you =
enabled IPv6 on something today...?

Sp=
aceNet AG                  &nb=
sp;     Vorstand: Sebastian v. Bomhard
Joseph-D=
ollinger-Bogen 14          Aufsichtsratsvors.: A. =
Grundner-Culemann
D-80807 Muenchen      &n=
bsp;            HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-I=
dNr.: DE813185279



 
 
  

------=_Part_2257850_1895722181.1429700126981--


From nobody Wed Apr 22 04:25:14 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 421C71B34A2 for ; Wed, 22 Apr 2015 04:25:13 -0700 (PDT)
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 i8CgFvPt5yRj for ; Wed, 22 Apr 2015 04:25:11 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 909401B349C for ; Wed, 22 Apr 2015 04:25:10 -0700 (PDT)
Received: (qmail 93540 invoked from network); 22 Apr 2015 11:25:08 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Apr 2015 11:25:08 -0000
Date: Wed, 22 Apr 2015 13:25:08 +0200 (CEST)
Message-Id: <20150422.132508.112543177.sthaug@nethelp.no>
To: markzzzsmith@yahoo.com.au
From: sthaug@nethelp.no
In-Reply-To: <597629658.2257851.1429700126987.JavaMail.yahoo@mail.yahoo.com>
References: <20150422085138.GE54385@Space.Net> <597629658.2257851.1429700126987.JavaMail.yahoo@mail.yahoo.com>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 11:25:13 -0000

> So would you expect all of your routers to be able to do this
> level of processing?

Yes.

> It seems to me that you'd only need routers that can do that
> processing facing potential malicious sources e.g. transit, peering,
> and possibly customer (although customers have a strong disincentive
> because it is in their interests for the router to stay
> available).

Customers themselves may have such a disincentive (unless they are
trying to deliberately sabotage the network infrastructure - which has
been known to happen). Customer PCs and other equipment which are
"owned" (i.e. part of a botnet, under control of an external party)
may well have a strong incentive to deliberately create problems.

> I wouldn't think it would be worth the expense to have
> this level of hardware filtering available on core routers.

Reasonable arguments can be made either way (Same level of hardware
filtering for core routers: Potentially more expensive hardware, but
potentially simpler logistics - fewer hardware product variants).

I *might* consider core routers without such hardware filtering *if*
I was running a pure MPLS core, and was reasonably certain customer
traffic wouldn't hit the core routers directly.

Steinar Haug, AS 2116


From nobody Wed Apr 22 05:03: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 F313F1B34F4 for ; Wed, 22 Apr 2015 05:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 oKftfDC4xM6D for ; Wed, 22 Apr 2015 05:03:18 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.145]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EE61AC3A6 for ; Wed, 22 Apr 2015 05:03:18 -0700 (PDT)
Received: from [85.158.136.3] by server-9.bemta-5.messagelabs.com id 90/5F-19899-40E87355; Wed, 22 Apr 2015 12:03:16 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-10.tower-123.messagelabs.com!1429704168!40703998!1
X-Originating-IP: [149.254.241.76]
X-StarScan-Received: 
X-StarScan-Version: 6.13.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6911 invoked from network); 22 Apr 2015 12:02:48 -0000
Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-10.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  22 Apr 2015 12:02:48 -0000
Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Wed, 22 Apr 2015 13:02:44 +0100
Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Wed, 22 Apr 2015 13:02:47 +0100
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 13:02:47 +0100
From: "Heatley, Nick" 
To: "Bjoern A. Zeeb" , IPv6 Ops WG 
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYtCVneMUqIFM3UWKOHw0TbKROp0lUOcAgAA3nwCAA2c/gIABUuaAgAFbCwCAABVpgIAAAIqAgAAPA4CAAAtsAIAAbkKAgAGv2wCAABSlgIAA/X4AgAAHmQCAAFthgIAL+9OAgAADYgCAAtG/AIAB4f6AgAD7QgCAAMs5AIAF7pkAgAOeT4CADJ5Bd4AA3PKggAAAeoCAADxNoA==
Date: Wed, 22 Apr 2015 12:02:47 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <5536776A.9060204@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net>
In-Reply-To: <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 12:03:22 -0000

DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmpvZXJuIEEuIFplZWINClNlbnQ6IDIyIEFw
cmlsIDIwMTUgMTA6MTUNCg0KU2VlLCB0aGUgdGhpbmcgSSBsaWtlIGFib3V0IHRoaXMgdGhyZWFk
IGlzLCB0aGF0IGV2ZXJ5Ym9keSBpcyB0cnlpbmcgdG8gcG9pbnQgdGhlaXIgZmluZ2VycyB0byBz
b21lb25lIGVsc2UgaW4gb3JkZXIgdG8gZml4IHNvbWV0aGluZyBlbHNld2hlcmUgYnV0IG5vdCB3
aXRoIHRoZW1zZWx2ZXMgb3Igd2hlcmUgdGhlICZeJSQjJCVeJiooKSBwcm9ibGVtIG9jY3Vycy4g
ICBBbnlvbmUgc2F5aW5nIOKAnHlvdSBjYW5ub3QgZ2V0IHJpZCBvZiBJUHY0IGxpdGVyYWxz4oCd
IHRvIHRoZSBleHRlbmQgdGhhdCBpdCBkb2VzbuKAmXQgYm90aGVyIGFueW9uZSBhbnltb3JlIGlz
IG1pc2xlYWQuICBZb3UganVzdCBoYXZlIG5vdCB0cmllZCBoYXJkIGVub3VnaCAocHJvYmFibHkg
YmVjYXVzZSB5b3UgYXJlIGRpc3RyYWN0ZWQgc2Vla2luZyBzb2x1dGlvbnMgZWxzZXdoZXJlKS4N
Cg0KSWYgZXZlcnlvbmUgY29tcGxhaW5pbmcgaGVyZSwgd291bGQgd29yayB0b3dhcmRzIGdldHRp
bmcgcmlkIG9mIHRoZW0gcmF0aGVyIHRoYW4gZGlzY3Vzc2luZyB3aG/igJlzIHByb2JsZW0gaXQg
aXMgdG8gcHV0IGEgd29ya2Fyb3VuZCBpbiBwbGFjZSwgd2XigJlkIHByb2JhYmx5IGJlIGhhbGYt
d2F5IGRvbmUuICBXZSBoYXZlIHBlb3BsZSBjcmF3bGluZyB0aGUgd2ViLCBwZW9wbGUgaGF2aW5n
IHVzZXJzIGFuZCB0ZXN0IG5ldHdvcmtzLCBwZW9wbGUgd2hvIHNlZW0gdG8gYmUgYWJsZSB0byB3
cml0ZSBlbm91Z2ggZW1haWxzIG9uIHRoZSB0b3BpYyB0aGF0IHRoZXkgY291bGQgZXZlbiBkaXJl
Y3QgaXQgdG8gdGhlIHJpZ2h0IHBlb3BsZS4NCg0KSSBjb3VsZCBldmVuIGJlIG1vcmUgYWR2ZW50
dXJvdXMgYW5kIHNheTogIGdpdmUgdGhlbSBhIDkwIGRheSBub3RpY2UsIHB1Ymxpc2ggaXQgKHRo
YXTigJlzIHRoZSBpbXBvcnRhbnQgcGFydCwgc28gdGhhdCB5dXIgdXNlcnMgaGVhciBhYm91dCBp
dCBhcyB3ZWxsKSwgYW5kIGlmIHRoZXkgZG9u4oCZdCBnZXQgYmFjayB0byB5b3UgdGhhdCB0aGV5
4oCZbGwgZml4IGl0ICh0aW1lbHkpIGJyZWFrIHRoZW0uICBJc27igJl0IHRoYXQgd2hhdCBwZW9w
bGUgZG8gd2l0aCBtYWpvciBzZWN1cml0eSBidWdzPyAgSeKAmWQgYmUgc3VycHJpc2VkIGlmIG1h
am9yIHNob3BwaW5nIHNpdGVzIGFuZCBuZXdzIHBhcGVycyB3b3VsZG7igJl0IHJlYWN0LCBvbmNl
IHRoZWlyIHNhbGVzIGFuZCBwYWdlIHZpZXdzIGdvIGRvd24gYnkgYSBmZXcgJSBvdmVyIG5pZ2h0
LCBidXQgeW91IG5lZWQgdG8gbGV0IHRoZW0gYW5kIHRoZWlyIHVzZXJzIGtub3cgdXBmcm9udC4N
Cg0KDQpbSGVhdGxleSwgTmlja10gQWdyZWUgdGhhdCBhdCBzb21lIHBvaW50IHRoZSBmaW5nZXIg
cG9pbnRpbmcgbmVlZHMgdG8gc3RvcC4NCk15IGNyaXRlcmlhIHRob3VnaCBpcyBub3QgYWJvdXQg
ImZpeGluZyBhdCBzb3VyY2UiLCBpdCBpcyBhYm91dCBiZWluZyBsZWFzdCBkaXNydXB0aXZlIG9y
IGRpc3R1cmJpbmcgdG8gY3VzdG9tZXJzLg0KVGhlIHByb2JsZW0gd2l0aCB0aGUgc291cmNlIG9m
IElQdjQgbGl0ZXJhbHMgaXMgdGhhdCBpdCBpbmNsdWRlcyBzbWFsbCBidXNpbmVzc2VzLCBtb20g
JiBwb3AgY29tcGFuaWVzLCBhcyB3ZWxsIGFzIG1ham9ycy4NCkkgYW0gY2VydGFpbmx5IG5vdCBp
bnRlcmVzdGVkIGluIHNlbmRpbmcgb3V0IGFueSAidGhlIHNreSBpcyBmYWxsaW5nIGRvd24iIG5v
dGljZXMgdG8gY3VzdG9tZXJzLCBpdCBpcyBtb3JlIGxpa2VseSB0aGV5IHdpbGwganVzdCBzaGlm
dCBwcm92aWRlcnM7IGFuZCBJIGRvbid0IHdhbnQgYW4gIm5vIElQdjQgbGl0ZXJhbCIgZmxhZyBk
YXkuDQpUaGUgcHJvYmxlbSBoYXMgdG8gcmVzaWRlIHdpdGggdGhvc2Ugb24gdGhlIHNpZGUgb2Yg
cHJvdmlkaW5nIHRoZSBzZXJ2aWNlLCBub3QgcHVudGluZyBpdCB0byB0aGUgY3VzdG9tZXJzIG9y
IHVzZXJzLg0KDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGlu
ZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29u
KHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBz
ZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5k
IGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3NlLiAgDQogDQpXZSBtYXkgbW9u
aXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVu
dCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVt
YWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFp
bnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZl
cnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBh
bmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVk
IE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBI
ZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCg==


From nobody Wed Apr 22 05:11: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 3649F1B34EF for ; Wed, 22 Apr 2015 05:11:24 -0700 (PDT)
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 qpTb770K_5LV for ; Wed, 22 Apr 2015 05:11:18 -0700 (PDT)
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 5DF561ABD3C for ; Wed, 22 Apr 2015 05:11:05 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 057AC608B9 for ; Wed, 22 Apr 2015 14:11:04 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B49D86029D for ; Wed, 22 Apr 2015 14:11:03 +0200 (CEST)
Received: (qmail 86620 invoked by uid 1007); 22 Apr 2015 14:11:03 +0200
Date: Wed, 22 Apr 2015 14:11:03 +0200
From: Gert Doering 
To: Mark ZZZ Smith 
Message-ID: <20150422121103.GH54385@Space.Net>
References: <20150422085138.GE54385@Space.Net> <597629658.2257851.1429700126987.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="52/+Pj69ZsQRDGwg"
Content-Disposition: inline
In-Reply-To: <597629658.2257851.1429700126987.JavaMail.yahoo@mail.yahoo.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 12:11:24 -0000

--52/+Pj69ZsQRDGwg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

(re-formatted weird Mark ZZZ quoting style to gain proper attribution)

On Wed, Apr 22, 2015 at 10:55:26AM +0000, Mark ZZZ Smith wrote:
> > No :-) - Hardware *is* sophisticated today, but only up to a certain li=
mit.
> >=20
> > What I think would be implementable with reasonable tradeoffs between
> > "unsane hardware effort that my end customers are not going to pay" and
> > "still flexible" is to require that the final EH is contained in the=20
> > first  bytes (say, 512) and that the final header must be in the=20
> > first fragment.
>=20
> / So would you expect all of your routers to be able to do this
> level of processing? It seems to me that you'd only need routers
> that can do that processing facing potential malicious sources e.g.
> transit, peering, and possibly customer (although customers have a
> strong disincentive because it is in their interests for the router
> to stay available). I wouldn't think it would be worth the expense
> to have this level of hardware filtering available on core routers.

Unless you define a "core router" to be a pure MPLS P node, which does not=
=20
do *any* IP processing, yes, it will have to do the same thing.

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

--52/+Pj69ZsQRDGwg
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVTeP199WwGXkzn/FAQKVXw//fjR//5HUk3FsZpUCvUy/QRcfK+J1Cee+
yP/3o8iwt2uANdLHSl3haM+dC2uGb3XrQgIBBg7IcjBZ+S0/XnAT/DkkRmILmCIx
6d4y2ev+F5S5FnLn1rDJqF6OgGoUNtYoN0k2CWkQ0fH2JXgGNPHeUJRu8OW+zrUG
d5CVEKf50lVBIHZY0SO1VuXZvb/Ig0PHeWMhunemzYbVnnvNL+XVqaoH3SppgTYx
49MyjfmJN0vH+C8nkX9F72PHRXoiiXZ6+81TLXofCx4sI33Gq56LEzZUq0+QE5ts
OKnRbpC4AzDJs8mNPrrztpBG5CPLA11rFwNKJq2Jf/wkgoWX1J0ftD+z6pXPhy6e
WDqCkHPTnbrnpTpv0m2MEVljzRTUYyiG3exeseQQ/I9//BpdW9F0XfxrHsYeq1/H
zF8v0v+x/ciFRQeB/ytfzR+WfQy3dIjMnLBpW1WOcp/pGhQW4Qz5WjFompvk/leS
hOCUOCRCkaqkKTZ673ZN3watGE1zFlLLqrZTKfQbrzLnSUzH0PMt6IJv+CsHtD0D
tepkygjbNUVCqi4numBhOSh4aUVkLRdVFhPLecrUFfxVa/s3rKHtFtveypb69J+i
4x4rivpMFvu9Omo6L60au24zL5ntxmrOzAQBrZ+cwJ6nQtRGNsCrzD/fnwtvRw5B
QKbEDZKuAnE=
=nTmG
-----END PGP SIGNATURE-----

--52/+Pj69ZsQRDGwg--


From nobody Wed Apr 22 07:00: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 9BC671A9139 for ; Wed, 22 Apr 2015 07:00:15 -0700 (PDT)
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 NXuthZbrslay for ; Wed, 22 Apr 2015 07:00:09 -0700 (PDT)
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 7D6961A910B for ; Wed, 22 Apr 2015 07:00:09 -0700 (PDT)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 18A7BDA0098; Wed, 22 Apr 2015 14:00:09 +0000 (UTC)
Received: from [10.0.20.172] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 22 Apr 2015 07:00:08 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK>
Date: Wed, 22 Apr 2015 09:59:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <5536776A.9060204@cernet.ed u.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK>
To: "Heatley, Nick" 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:00:15 -0000

On Apr 22, 2015, at 8:02 AM, Heatley, Nick  =
wrote:
> If everyone complaining here, would work towards getting rid of them =
rather than discussing who=92s problem it is to put a workaround in =
place, we=92d probably be half-way done.  We have people crawling the =
web, people having users and test networks, people who seem to be able =
to write enough emails on the topic that they could even direct it to =
the right people.

The problem is that the people who are using IPv4 literals are not =
_here_.   If fixing this were up to the people who are _here_, it would =
already have been fixed.   Nobody _here_ thinks that using IPv4 literals =
is okay (I suppose I will be corrected if I am wrong).

So while what you are saying would definitely be right if those people =
were here, since they are not, it isn't practical.


From nobody Wed Apr 22 07:24: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 33C441ACD2F for ; Wed, 22 Apr 2015 07:24:38 -0700 (PDT)
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 K3I81mmsWSwN for ; Wed, 22 Apr 2015 07:24:36 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852601ABB19 for ; Wed, 22 Apr 2015 07:23:17 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3MENFoN019672 for ; Wed, 22 Apr 2015 16:23:15 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1B1942028CF for ; Wed, 22 Apr 2015 16:24:40 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 123142028CB for ; Wed, 22 Apr 2015 16:24:40 +0200 (CEST)
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 t3MENEBU029841 for ; Wed, 22 Apr 2015 16:23:15 +0200
Message-ID: <5537AED2.4090306@gmail.com>
Date: Wed, 22 Apr 2015 16:23:14 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: v6ops@ietf.org
References:      <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <5536776A.9060204@cernet.ed u.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
In-Reply-To: <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:24:38 -0000

Le 22/04/2015 15:59, Ted Lemon a écrit :
> On Apr 22, 2015, at 8:02 AM, Heatley, Nick 
> wrote:
>> If everyone complaining here, would work towards getting rid of
>> them rather than discussing who’s problem it is to put a workaround
>> in place, we’d probably be half-way done.  We have people crawling
>> the web, people having users and test networks, people who seem to
>> be able to write enough emails on the topic that they could even
>> direct it to the right people.
>
> The problem is that the people who are using IPv4 literals are not
> _here_.   If fixing this were up to the people who are _here_, it
> would already have been fixed.   Nobody _here_ thinks that using IPv4
> literals is okay (I suppose I will be corrected if I am wrong).
>
> So while what you are saying would definitely be right if those
> people were here, since they are not, it isn't practical.

One path to fixing IPv4 literals is to make inet_pton () return -1 on 
anything which is not RFC5952 "IPv6 textual representation recomm't", 
including IPv4 literals.  Currently it returns 1 on IPv6 and IPv4 
literals.  Or display a warning "not valid after 2020".

That would first be in implementation, second at a Unix API SDO, and 
then maybe at IETF?

Alex

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



From nobody Wed Apr 22 07:31: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 5F3D61ACCFE for ; Wed, 22 Apr 2015 07:31:17 -0700 (PDT)
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 fF4VgSUGHux9 for ; Wed, 22 Apr 2015 07:31:13 -0700 (PDT)
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 7F0041ACCDF for ; Wed, 22 Apr 2015 07:31:04 -0700 (PDT)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4169EDA009E; Wed, 22 Apr 2015 14:31:04 +0000 (UTC)
Received: from [10.0.20.172] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 22 Apr 2015 07:31:04 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5537AED2.4090306@gmail.com>
Date: Wed, 22 Apr 2015 10:30:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References:      <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <5536776A.9060204@cernet.ed u.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com> <5537AED2.4090306@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:31:17 -0000

On Apr 22, 2015, at 10:23 AM, Alexandru Petrescu =
 wrote:
> One path to fixing IPv4 literals is to make inet_pton () return -1 on =
anything which is not RFC5952 "IPv6 textual representation recomm't", =
including IPv4 literals.  Currently it returns 1 on IPv6 and IPv4 =
literals.  Or display a warning "not valid after 2020".
>=20
> That would first be in implementation, second at a Unix API SDO, and =
then maybe at IETF?

So you are saying that someone has to break things for their customers, =
and take the heat.   And the people who would do that have already said =
they will not, and given good reasons why.   A way forward that requires =
well-intentioned people in a position to do something to do something =
that is not in their interests is not going to get consensus.


From nobody Wed Apr 22 07:34: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 CBE8D1B366C for ; Wed, 22 Apr 2015 07:34:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.475
X-Spam-Level: 
X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, 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 PVJodi-R5IgP for ; Wed, 22 Apr 2015 07:34:03 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0071ACD4C for ; Wed, 22 Apr 2015 07:33:47 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,623,1422939600"; d="scan'208";a="857145900"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Apr 2015 10:18:16 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 22 Apr 2015 10:33:46 -0400
From: "George, Wes" 
To: Ted Lemon , "Heatley, Nick" 
Date: Wed, 22 Apr 2015 10:33:44 -0400
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AdB9CVbuslOfxfNsTSuiIdIuRUbeUw==
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
In-Reply-To: <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:34:04 -0000

T24gNC8yMi8xNSwgOTo1OSBBTSwgIlRlZCBMZW1vbiIgPFRlZC5MZW1vbkBub21pbnVtLmNvbT4g
d3JvdGU6DQoNCg0KPlRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHBlb3BsZSB3aG8gYXJlIHVzaW5n
IElQdjQgbGl0ZXJhbHMgYXJlIG5vdA0KPl9oZXJlXy4NCg0KV0ddIFNob3VsZCB3ZSBiZSB0cnlp
bmcgdG8gcmFpc2UgdmlzaWJpbGl0eSBvbiB0aGlzIGlzc3VlIGluIG90aGVyIGZvcnVtcz8NCkZv
ciBpbnN0YW5jZSwgSUVURiBoYXMgYSBmb3JtYWwgbGlhaXNvbiByZWxhdGlvbnNoaXAgd2l0aCBX
M0MuIFBlcmhhcHMgYW4NCmVmZm9ydCB0aGVyZSB3b3VsZCBiZSB1c2VmdWwsIGV2ZW4gaWYgaXQg
ZG9lc24ndCBuZWNlc3NhcmlseSBjb3ZlciBub24td2ViDQphcHAgZGV2ZWxvcGVycz8gRGl0dG8g
Q0VBIGFuZCB0aGVpciBJUHY2IFdHIC0gd2hpbGUgSUVURiBkb2Vzbid0IGhhdmUgYQ0KZm9ybWFs
IGxpYWlzb24sIHdlIGRlZmluaXRlbHkgaGF2ZSBmb2xrcyB0aGF0IHBhcnRpY2lwYXRlIGluIGJv
dGggdjZvcHMNCmFuZCBDRUEgdGhhdCBjb3VsZCBnZXQgdGhlIG1lc3NhZ2Ugb3V0Lg0KDQpXZXMg
R2VvcmdlDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBj
b21wYW554oCZcyBtYWlsIHNlcnZlciwgSQ0KaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0t
LS0tLS0tLQ0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBj
b250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBp
cyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9u
Z2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5
IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBh
ZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBF
LW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRp
c3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBj
b250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJv
aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUt
bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBw
ZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFp
bCBhbmQgYW55IHByaW50b3V0Lg0K


From nobody Wed Apr 22 07:37:45 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 16C731B366E for ; Wed, 22 Apr 2015 07:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.348
X-Spam-Level: 
X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsYzDyKhvX6Y for ; Wed, 22 Apr 2015 07:37:42 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 3C9B11B3673 for ; Wed, 22 Apr 2015 07:35:51 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so88204787wic.1 for ; Wed, 22 Apr 2015 07:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ytaPAXwsG6dvybHfLVsZHS02CBjFHlXPc+9y2AWQBYA=; b=tNUnuNWiG0bU3h5iz/lZdcdRY3N+lE/KrgQWKfWaDSWpwOYBeAQNN4iSrCU2l18syf fbFS8tWL08jDkQJK2v0GEm0ZFLzpTcM/O7OOMHJ1DVM4aN6L1IUx64Ce/F0zpIj2Ej+4 tx6lz/6NPrnk9zfGqb6P8zkyh7jtyhYL7n3TqZYIhJiTVqcpUGRmkHfHuMaez9jqzxq5 SdCBNpFPU6SG/BflctHvxUBrecdKwNlQvkJCWbU4b5mFiP31bv6lCnL/2uS2w8ZLjh4l 1RyW+tGoYJruesbZzPuFaflb27U/ZiAs7Hfocbn05bfABmAz09jP9Tb1wa9v48M5ATkh Pyzg==
MIME-Version: 1.0
X-Received: by 10.180.95.10 with SMTP id dg10mr6546906wib.41.1429713349945; Wed, 22 Apr 2015 07:35:49 -0700 (PDT)
Received: by 10.194.40.231 with HTTP; Wed, 22 Apr 2015 07:35:49 -0700 (PDT)
In-Reply-To: <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
Date: Wed, 22 Apr 2015 07:35:49 -0700
Message-ID: 
From: Ca By 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=f46d04447f835aadb2051451140a
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:37:44 -0000

--f46d04447f835aadb2051451140a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 22, 2015 at 6:59 AM, Ted Lemon  wrote:

> On Apr 22, 2015, at 8:02 AM, Heatley, Nick  wrote:
> > If everyone complaining here, would work towards getting rid of them
> rather than discussing who=E2=80=99s problem it is to put a workaround in=
 place,
> we=E2=80=99d probably be half-way done.  We have people crawling the web,=
 people
> having users and test networks, people who seem to be able to write enoug=
h
> emails on the topic that they could even direct it to the right people.
>
> The problem is that the people who are using IPv4 literals are not
> _here_.   If fixing this were up to the people who are _here_, it would
> already have been fixed.   Nobody _here_ thinks that using IPv4 literals =
is
> okay (I suppose I will be corrected if I am wrong).
>
> So while what you are saying would definitely be right if those people
> were here, since they are not, it isn't practical.
>
>

The key is that:

1) We can only "fix" what is in our control -- as a network operator
464XLAT is in my  toolbox -- thank you IETF / Android / Microsoft.

2) Any solution that involves creating a negative customer experience (xyz
website or abc app does not work), is a non-starter.  Please stop
suggesting pain on paying customers, no network operator will do it. No
appstore will do it (with teeth, in the near term)

3) As Ted noted, the "ipv4-only deployers" are here and they are not
moving.  They include Google (hangouts), Apple (facetime), Spotify,
Netflix, so on and so forth. They understand the issue, and they are not
running to fix it.  So what is an ipv4-poor network to do?  Well, let's
check the tool box:

1) CGN -- tried true, but really just kicks the can down the road -- oh,
and RFC1918 ran out soo....  i hear there is some IPv4 space that is not
announce on the internet i can use .... So, this is a pretty anti-social
option, but it works.

2)  464XLAT / MAP / DS-lite -- Yay!  i can give users unique IPv6 public
addresses, grow the real IPv6 internet, and let ipv4 die on the vine (x
decade process, but real meaningful ipv6 progress now)

3.  Buy IPv4 (does not scale well, also anti-social)

Keep in mind, the tool box only includes these 3 things.  Wishing some
vigilante titan network is going to rain fire down on IPv4-only apps is not
realistic at all.  Same is true for  "mega-mobile-phone eco-system", they
will also not bar IPv4-only apps in a timescale that is helpful.  And, they
too have customers that want to go to http://192.0.1.1 on the public
internet ... and no, they are not going enroll networks to switch to
IPv6-only without IPv4-socket support to reach 99% of internet while other
networks are delivering 100% of the internet.

Regards,

CB




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

--f46d04447f835aadb2051451140a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Apr 22, 2015 at 6:59 AM, Ted Lemon <Ted.Lemon@nominum.com<=
/a>> wrote:
On=
 Apr 22, 2015, at 8:02 AM, Heatley, Nick <nick.heatley@ee.co.uk> wrote:

> If everyone complaining here, would work towards getting rid of them r=
ather than discussing who=E2=80=99s problem it is to put a workaround in pl=
ace, we=E2=80=99d probably be half-way done.=C2=A0 We have people crawling =
the web, people having users and test networks, people who seem to be able =
to write enough emails on the topic that they could even direct it to the r=
ight people.



The problem is that the people who are using IPv4 literals are not _=
here_.=C2=A0 =C2=A0If fixing this were up to the people who are _here_, it =
would already have been fixed.=C2=A0 =C2=A0Nobody _here_ thinks that using =
IPv4 literals is okay (I suppose I will be corrected if I am wrong).



So while what you are saying would definitely be right if those people were=
 here, since they are not, it isn't practical.



<=
br>

The key is that:

1) W=
e can only "fix" what is in our control -- as a network operator =
464XLAT is in my =C2=A0toolbox -- thank you IETF / Android / Microsoft.

2) Any solution that involves creating a negative cus=
tomer experience (xyz website or abc app does not work), is a non-starter.=
=C2=A0 Please stop suggesting pain on paying customers, no network operator=
 will do it. No appstore will do it (with teeth, in the near term)

3) As Ted noted, the "ipv4-only deployers" are h=
ere and they are not moving.=C2=A0 They include Google (hangouts), Apple (f=
acetime), Spotify, Netflix, so on and so forth. They understand the issue, =
and they are not running to fix it.=C2=A0 So what is an ipv4-poor network t=
o do?=C2=A0 Well, let's check the tool box:

1)=
 CGN -- tried true, but really just kicks the can down the road -- oh, and =
RFC1918 ran out soo.... =C2=A0i hear there is some IPv4 space that is not a=
nnounce on the internet i can use .... So, this is a pretty anti-social opt=
ion, but it works.

2) =C2=A0464XLAT / MAP / DS-lit=
e -- Yay! =C2=A0i can give users unique IPv6 public addresses, grow the rea=
l IPv6 internet, and let ipv4 die on the vine (x decade process, but real m=
eaningful ipv6 progress now)

3.=C2=A0 Buy IPv4 (do=
es not scale well, also anti-social)

Keep in mind,=
 the tool box only includes these 3 things.=C2=A0 Wishing some vigilante ti=
tan network is going to rain fire down on IPv4-only apps is not realistic a=
t all.=C2=A0 Same is true for =C2=A0"mega-mobile-phone eco-system"=
;, they will also not bar IPv4-only apps in a timescale that is helpful.=C2=
=A0 And, they too have customers that want to go to http://192.0.1.1 on the public internet ... and no, they are not =
going enroll networks to switch to IPv6-only without IPv4-socket support to=
 reach 99% of internet while other networks are delivering 100% of the inte=
rnet.

Regards,

CB


=C2=A0=C2=A0

_______________________________________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--f46d04447f835aadb2051451140a--


From nobody Wed Apr 22 07:40: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 E8BA61ACD88 for ; Wed, 22 Apr 2015 07:40:00 -0700 (PDT)
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 y1LSrI3wNQ0a for ; Wed, 22 Apr 2015 07:40:00 -0700 (PDT)
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 DDE4B1B3661 for ; Wed, 22 Apr 2015 07:38:07 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id D2FBBDA0098; Wed, 22 Apr 2015 14:38:07 +0000 (UTC)
Received: from [10.0.20.172] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 22 Apr 2015 07:38:07 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Wed, 22 Apr 2015 10:37:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com> 
To: "George, Wes" 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:40:01 -0000

On Apr 22, 2015, at 10:33 AM, George, Wes  =
wrote:
> WG] Should we be trying to raise visibility on this issue in other =
forums?
> For instance, IETF has a formal liaison relationship with W3C. Perhaps =
an
> effort there would be useful, even if it doesn't necessarily cover =
non-web
> app developers?

I am skeptical that the people who are using IPv4 literals are active in =
any standards community.   I suppose it's possible, and reaching out and =
getting e.g. W3C to make a strong statement about this would certainly =
be good in the sense that it might shorten the long tail, but I don't =
think it's going to fix the problem soon enough.   I really can't see =
any way to address this that doesn't look something like 464xlat or =
IPv4-as-a-service (e.g. softwire MAP/lw4over6).


From nobody Wed Apr 22 07:44:40 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 7A7041ACD6D for ; Wed, 22 Apr 2015 07:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.387
X-Spam-Level: 
X-Spam-Status: No, score=-1.387 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, NORMAL_HTTP_TO_IP=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 mEMQ5g88XHVG for ; Wed, 22 Apr 2015 07:44:37 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 AB26F1ACD63 for ; Wed, 22 Apr 2015 07:44:34 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so105606068igb.0 for ; Wed, 22 Apr 2015 07:44:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jkoB0KQwqjN1Sm56qQozyiOYQFc0C06IeW6xVaN+DYg=; b=K/jVSMvv2gZFKFVnLJqui0aAo7RssOwADhYfysHxbpw6ji6H3lHAA5yCp9T5T2WlbV Zo6vYsjg6G/alebtUGylOun4dkcWVFMhaP5RUT7CU9iWJpDrr1wiqnkYApp9WLmAySdo ussUyyKe/s+tFjB5RjsxGlf2DKuK6KsXQWzJZoktHl9wx0q2rtA9cZxR4K8BvfVfLq1M xvZnsFBPvcCuWxfV0JCmS8cZErXnKLnPMq8AS4jgKNrhjcOed/GmwABSzX9QhPvVqTzM x/Wns8PPJSLkL0DH0gcuxv953hqzHvtFbeRNnfg6rwgFvJQsHoIHufh36K2aQ0o/2MXe iMUg==
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=jkoB0KQwqjN1Sm56qQozyiOYQFc0C06IeW6xVaN+DYg=; b=INpwBMKSOP2AvgqYog/77gVbT/zJ3C+AO3Rq14y08e3qxR0Z/L2L8p7KutULsf14xS q5wejOIBExwgK9JYAP5IFW6CGR0eZVVn49eElLVYKBoAE3FkpTTPRhv9Ail6Fi4DE5fK pI4EjfeVC2tEQPq4+9gJdb9sHo7OQ/JtAeuvvIBcblTlzdzJdPtokwK4XijJYD/j/7d0 dkBO9ujpXQ9FaUGLYMXh/VZHUAhgxtAX+5qCYMTb7g0/L6rv1NMjU7JTqPkBMclrktL4 plNV8WVgXiU9xNYFdxYV03WliT0wpijN3vVpOAtaPtSBZ5Qmv67V8fv6Xk9BpFAR99TI h/cA==
X-Gm-Message-State: ALoCoQk1XpTxB8N3cGSQGKQmUcUI+E82Rn5PjdD3Ftfl/ggvs303YkSQhmIEZl6Zr53EqZrpJ8bh
X-Received: by 10.50.137.97 with SMTP id qh1mr5003139igb.39.1429713874107; Wed, 22 Apr 2015 07:44:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.73.2 with HTTP; Wed, 22 Apr 2015 07:44:13 -0700 (PDT)
In-Reply-To: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com> 
From: Lorenzo Colitti 
Date: Wed, 22 Apr 2015 23:44:13 +0900
Message-ID: 
To: Ca By 
Content-Type: multipart/alternative; boundary=001a11c3f1f498faab051451333f
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:44:38 -0000

--001a11c3f1f498faab051451333f
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 22, 2015 at 11:35 PM, Ca By  wrote:

> Keep in mind, the tool box only includes these 3 things.  Wishing some
> vigilante titan network is going to rain fire down on IPv4-only apps is not
> realistic at all.  Same is true for  "mega-mobile-phone eco-system", they
> will also not bar IPv4-only apps in a timescale that is helpful.  And, they
> too have customers that want to go to http://192.0.1.1 on the public
> internet ... and no, they are not going enroll networks to switch to
> IPv6-only without IPv4-socket support to reach 99% of internet while other
> networks are delivering 100% of the internet.
>

What he said. The only question, really, is whether we end up doing #1 or
#2.

--001a11c3f1f498faab051451333f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Apr 22, 2015 at 11:35 PM, Ca By <cb.list6@gmail.com> wr=
ote:
Keep in mind, the tool box only includes these 3 =
things.=C2=A0 Wishing some vigilante titan network is going to rain fire do=
wn on IPv4-only apps is not realistic at all.=C2=A0 Same is true for =C2=A0=
"mega-mobile-phone eco-system", they will also not bar IPv4-only =
apps in a timescale that is helpful.=C2=A0 And, they too have customers tha=
t want to go to http://192.0=
.1.1 on the public internet ... and no, they are not going enroll netwo=
rks to switch to IPv6-only without IPv4-socket support to reach 99% of inte=
rnet while other networks are delivering 100% of the internet.
<=
/div>

What he said. The only question=
, really, is whether we end up doing #1 or #2.


--001a11c3f1f498faab051451333f--


From nobody Wed Apr 22 07:46: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 D1A601ACD66 for ; Wed, 22 Apr 2015 07:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GQ5_5BIzYXq for ; Wed, 22 Apr 2015 07:46:54 -0700 (PDT)
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E92A1AC419 for ; Wed, 22 Apr 2015 07:46:54 -0700 (PDT)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1F87925D385E for ; Wed, 22 Apr 2015 14:46:52 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 6F1BAC76FE4 for ; Wed, 22 Apr 2015 14:46:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id S2ECBrU7irWH for ; Wed, 22 Apr 2015 14:46:49 +0000 (UTC)
Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9921AC76FE5 for ; Wed, 22 Apr 2015 14:46:49 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Bjoern A. Zeeb" 
In-Reply-To: 
Date: Wed, 22 Apr 2015 14:46:48 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <20D5E991-C6E9-4679-8331-AF0D6BF60213@lists.zabbadoz.net>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303 E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com> 
To: IPv6 Ops WG 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:46:56 -0000

> On 22 Apr 2015, at 14:35 , Ca By  wrote:
>=20
> The key is that:
>=20
> 1) We can only =E2=80=9Cfix=E2=80=9D what is in our control -- as a =
network operator 464XLAT is in my  toolbox -- thank you IETF / Android / =
Microsoft.

You control a network. You forward packets or you don=E2=80=99t.

You assuming to have control over my end node device is wrong.  You can =
only let me on your network or you can=E2=80=99t.   If you are concerned =
about 1 million IPv4 literals out there, why are you not concerned abut =
1 million handsets that will never do IPv6 in the next 5 years and will =
require IPv4 one way or another from you?


> 2) Any solution that involves creating a negative customer experience =
(xyz website or abc app does not work), is a non-starter.  Please stop =
suggesting pain on paying customers, no network operator will do it. No =
appstore will do it (with teeth, in the near term)

The way no major content provider wanted to turn IPv6 on.  Then they did =
for a day, and then they did it permanently.


=E2=80=94=20
Bjoern A. Zeeb                                  Charles Haddon Spurgeon:
"Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend."


From nobody Wed Apr 22 07:55: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 6E1641B366E for ; Wed, 22 Apr 2015 07:55:22 -0700 (PDT)
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 VAc5r5w5UEfw for ; Wed, 22 Apr 2015 07:55:21 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 92D8C1B3663 for ; Wed, 22 Apr 2015 07:55:13 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so105797166igb.0 for ; Wed, 22 Apr 2015 07:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CC9xOhm91OPTzHiLlMr4zV7XRbelU2mVXL/RlcQpJxE=; b=FUdJBS8AZ7/N2aLjN6w41yZyjVV2MwjxqdhLL66xScVWi2s28A4+3llWOuN7nKFUTU 0Kd4htJmRz20lWccuO+TW1A8J8vgyLTmfE0NVS2NhjYSwxRistPDJ81UhX8nPUEoU7ka LTEnp63mjSyKL7N12UYA1BG11nS1BrjQF8E6y5ItKbfMAPhcEVbZK1AOxD/h8jreT7oB +7eq8SCtU/dCiatqIHJfysAaf0lCvGFndUvN+AKLSrbi0lJIUeUfv69AA4GhUBhB9dMr ZVdWQdsDLI0Z0IMXOzX3rNEQboR7+q1ydcqHS7MpNIn77I5CQ9DTvQXgJLYFWsAOb+QK ceBw==
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=CC9xOhm91OPTzHiLlMr4zV7XRbelU2mVXL/RlcQpJxE=; b=Rai9Ji2sO6qvZIHtGgJS7oMFRac1g1cmQTnuWVtCvJZE3OvG7e7/S83O5g3EaES7fI ttLNEHlgI7RG7X0v8KJ86nHXXn8Sw9ws4FuWm7KZHVj2LUhN+bAE3pvu08TBoR1C9WiF 84hbzU2qmSz6Gw1UFrInk9esn7ZCaR9tkj+S/0Vn4socqmMDpRnS9XLVbsKamOM6kBsG 5WbqRtQulck0R4oS3KF4iLm0hcLdbt9+9M8udC7F8zsGoNp8UE1M0DkC+i6bZxbehBZN PZyWSfycI5Ebc8uAYshPtIErEPoPSTlzjA/TNs0J/IrmL1WfWaWV2tf7sDVayHKXVT3x Kayg==
X-Gm-Message-State: ALoCoQmJaLofVkMIiV9vHmFlGF/Gf13QnbQt6RjCTWoRzGJVXAgoYpz1BD1m3lpIS2GA3lS9yAMX
X-Received: by 10.107.33.21 with SMTP id h21mr37275434ioh.1.1429714513065; Wed, 22 Apr 2015 07:55:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.73.2 with HTTP; Wed, 22 Apr 2015 07:54:52 -0700 (PDT)
In-Reply-To: <20D5E991-C6E9-4679-8331-AF0D6BF60213@lists.zabbadoz.net>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <20D5E991-C6E9-4679-8331-AF0D6BF60213@lists.zabbadoz.net>
From: Lorenzo Colitti 
Date: Wed, 22 Apr 2015 23:54:52 +0900
Message-ID: 
To: "Bjoern A. Zeeb" 
Content-Type: multipart/alternative; boundary=001a1140408cae9fea05145159e0
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 14:55:22 -0000

--001a1140408cae9fea05145159e0
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 22, 2015 at 11:46 PM, Bjoern A. Zeeb <
bzeeb-lists@lists.zabbadoz.net> wrote:

> If you are concerned about 1 million IPv4 literals out there, why are you
> not concerned abut 1 million handsets that will never do IPv6 in the next 5
> years and will require IPv4 one way or another from you?
>

That *is* what he's concerned about. He's wishing those handsets supported
464xlat.


> > 2) Any solution that involves creating a negative customer experience
> (xyz website or abc app does not work), is a non-starter.  Please stop
> suggesting pain on paying customers, no network operator will do it. No
> appstore will do it (with teeth, in the near term)
>
> The way no major content provider wanted to turn IPv6 on.  Then they did
> for a day, and then they did it permanently.
>

They were only able to do it because breakage was < 0.05%. That's way lower
than "spotify, google video chat, skype (?), , ".

And when you say "permanent" - note that some content providers (like
Google) still don't provide AAAA records all the time to everyone -
precisely because measurements show there is breakage. (Search for
no_aaaa.txt)

--001a1140408cae9fea05145159e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Apr 22, 2015 at 11:46 PM, Bjoern A. Zeeb <bzeeb-lists@li=
sts.zabbadoz.net> wrote:
If=
 you are concerned about 1 million IPv4 literals out there, why are you not=
 concerned abut 1 million handsets that will never do IPv6 in the next 5 ye=
ars and will require IPv4 one way or another from you?

That *is* what he's concerned about. He's wishing t=
hose handsets supported 464xlat.
=C2=A0
> 2) Any solution that involves creating a n=
egative customer experience (xyz website or abc app does not work), is a no=
n-starter.=C2=A0 Please stop suggesting pain on paying customers, no networ=
k operator will do it. No appstore will do it (with teeth, in the near term=
)



The way no major content provider wanted to turn IPv6 on.=C2=A0 Then=
 they did for a day, and then they did it permanently.

They were only able to do it because breakage was < 0.05=
%. That's way lower than "spotify, google video chat, skype (?), &=
lt;unknown number of other apps>, <large number of websites with lite=
rals>".

And when you say "permanent&q=
uot; - note that some content providers (like Google) still don't provi=
de AAAA records all the time to everyone - precisely because measurements s=
how there is breakage. (Search for no_aaaa.txt)


--001a1140408cae9fea05145159e0--


From nobody Wed Apr 22 08:12: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 BCB611A1A6D for ; Wed, 22 Apr 2015 08:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7YDnTUVGiUt for ; Wed, 22 Apr 2015 08:12:54 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 263F81A1A62 for ; Wed, 22 Apr 2015 08:12:54 -0700 (PDT)
Received: by wgyo15 with SMTP id o15so250486380wgy.2 for ; Wed, 22 Apr 2015 08:12:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PNbzHwkDAx5J3bfHMKMx6kMRzt018Xf8sWbUdQrESbY=; b=SjCf4u4n22rfsPc7U1OFbETe3kPfQJXuUIR6KPib6sAueFOg3P/GIR4KRUgimtsc4U 2/2uGr+JJvT/ayIvRn0rDvdMmGOAKnlYJSddIukJF4fVWZKsY+7VGpoCJxlG3iiynQz1 M68cf2I6qQHoi+eTIABic0hzWmxF6AWRpvHK9K4PCGKQ5T7sZymkd3B/6GiNkQr96EHk YN74Zalmx2HmL3+Oc/y/2wjc9N8xTqqZCW8/ZcWzsl/nrIllxIH5zyoCsn65/6vhCssO 5Xt8hxfpP/uJObQurRyOFqnlffMZZyJGiyx5RSJBwZ0rD7G5iLA4INKavbs1LwFRIeHc A4qQ==
MIME-Version: 1.0
X-Received: by 10.180.102.34 with SMTP id fl2mr6669121wib.73.1429715572832; Wed, 22 Apr 2015 08:12:52 -0700 (PDT)
Received: by 10.194.40.231 with HTTP; Wed, 22 Apr 2015 08:12:52 -0700 (PDT)
In-Reply-To: <20D5E991-C6E9-4679-8331-AF0D6BF60213@lists.zabbadoz.net>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <20D5E991-C6E9-4679-8331-AF0D6BF60213@lists.zabbadoz.net>
Date: Wed, 22 Apr 2015 08:12:52 -0700
Message-ID: 
From: Ca By 
To: "Bjoern A. Zeeb" 
Content-Type: multipart/alternative; boundary=f46d04451809d9427005145198eb
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 15:12:55 -0000

--f46d04451809d9427005145198eb
Content-Type: text/plain; charset=UTF-8

>
>
> > 2) Any solution that involves creating a negative customer experience
> (xyz website or abc app does not work), is a non-starter.  Please stop
> suggesting pain on paying customers, no network operator will do it. No
> appstore will do it (with teeth, in the near term)
>
> The way no major content provider wanted to turn IPv6 on.  Then they did
> for a day, and then they did it permanently.
>
>
I am fully open to the  next generation of iThingies  being IPv6-only
mandatory on all networks in the USA, this would achieve a lot in one
stroke.  The USA market is huge, and would shock the entire internet / web
/ apps into compliance "with this one weird trick."

The key is that a unified front is presented by all operators and enforced
by the owner of the ecosystem.  They can kill off IPv4 just like they
killed off Flash.  But, we cannot have free-riders that avoid the
requirement.

My honest opinion is that this alliance cannot be formed.  That said, mark
me as first in line for accepting this requirement if and only if all other
USA networks accept the requirement as well.


CB

--f46d04451809d9427005145198eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




> 2) Any solution that involves creating a negative customer experience =
(xyz website or abc app does not work), is a non-starter.=C2=A0 Please stop=
 suggesting pain on paying customers, no network operator will do it. No ap=
pstore will do it (with teeth, in the near term)



The way no major content provider wanted to turn IPv6 on.=C2=A0 Then=
 they did for a day, and then they did it permanently.



I am =
fully open to the =C2=A0next generation of iThingies =C2=A0being IPv6-only =
mandatory on all networks in the USA, this would achieve a lot in one strok=
e.=C2=A0 The USA market is huge, and would shock the entire internet / web =
/ apps into compliance "with this one weird trick."
The key is that a unified front is presented by all operators a=
nd enforced by the owner of the ecosystem.=C2=A0 They can kill off IPv4 jus=
t like they killed off Flash.=C2=A0 But, we cannot have free-riders that av=
oid the requirement.

My honest opinion is that thi=
s alliance cannot be formed.=C2=A0 That said, mark me as first in line for =
accepting this requirement if and only if all other USA networks accept the=
 requirement as well.


CB
<=
div>
=C2=A0


--f46d04451809d9427005145198eb--


From nobody Wed Apr 22 09:55: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 E1A041B3807 for ; Wed, 22 Apr 2015 09:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNhU_UFuRV4q for ; Wed, 22 Apr 2015 09:55:20 -0700 (PDT)
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 E86861B380D for ; Wed, 22 Apr 2015 09:55:08 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:0:0:0:110]) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t3MGt4X5097613 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2015 17:55:05 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100:0:0:0:110] claimed to be cupcake.foobar.org
Message-ID: <5537D268.1010603@foobar.org>
Date: Wed, 22 Apr 2015 17:55:04 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Mark ZZZ Smith , "v6ops@ietf.org" 
References: <5536814D.7030708@foobar.org> <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 16:55:23 -0000

Mark,

Gert and Steiner have answered many of the issues which you bring up.

On 22/04/2015 07:20, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.

The emperor is not naked.  We live in a real world with real constraints.

> What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always in the same place in
> the packet, so that hardware can look at them for the purposes of dropping
> them in hardware or as inputs into LB. Is that the case?

Nope, EHs cannot be removed from the spec and no-one is suggesting this.
As Steiner said, we need something like:

>  [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit

I'd suggest that we need a chunk of encapsulation overhead in that
equation.  The hardware inspection limit will vary, but the larger it is,
the more expensive both in terms of financial cost and performance.

> What I'm curious about then is how do you handle DDoSes that are using IP
> fragments, where there are no TCP or UDP headers ports to look at?

s/rtbh or d/rtbh, depending on which looks like it will be more effective.
 But please don't try to imply that because something is broken in ipv4
that we should be ok if it's broken in ipv6 too.  This is a unhelpful fallacy.

> I'm also curious about how you LB packets (either at layer 2 or layer 3)
> that don't have TCP or UDP headers, or aren't IP. I've seen LB become
> completely ineffective at layer 2 because a customer was using MPLS between
> two routers, so no MAC address variation, and no IP addresses and no TCP or
> UDP ports to look at.

tbh, with great difficulty and expense.  I spend an inordinate amount of
time trying to deal with this particular problem.  And if it's bad for the
L3 ISP stuff I do, it's far worse on an L2 IXP lan.

> In fact, given the trouble LAG has caused me in the past 2 years (LAG
> member links that are not current members are supposed to be considered by
> the bridge as normal bridge ports, so if you want to avoid loops across the
> links that are candidate members of the LAG, the IEEE expect you to be
> running STP of some form across them...)

yep, bridges require bridging protocols for loop avoidance.

>, I'm a big fan of the quote on the
> last slide of this presentation:
> 
> "IEEE 802.3ad Link Aggregation (LAG) what it is, and what it is not"
> http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf
> 
> "LAG is good, but it’s not as good as a fatter pipe."

which is fine until the point that a fatter pipe will not handle all the
data you need to transfer.  If I had a choice about using LAGs, I wouldn't
use them.  I don't have that choice.

Nick



From nobody Wed Apr 22 10:18: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 ED44F1B3895 for ; Wed, 22 Apr 2015 10:18:31 -0700 (PDT)
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 RzebUwr3YRhD for ; Wed, 22 Apr 2015 10:18:30 -0700 (PDT)
Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B438B1B376B for ; Wed, 22 Apr 2015 10:18:30 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3MHHRhf023913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2015 10:17:27 -0700 (PDT)
Message-ID: <5537D7A6.4020106@isi.edu>
Date: Wed, 22 Apr 2015 10:17:26 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: sthaug@nethelp.no
References: <553696EC.4060207@isi.edu>	<55369855.1040101@joelhalpern.com>	<55369B2D.80906@isi.edu> <20150422.084056.74672865.sthaug@nethelp.no>
In-Reply-To: <20150422.084056.74672865.sthaug@nethelp.no>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, merike@doubleshotsecurity.com, fgont@si6networks.com
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 17:18:32 -0000

On 4/21/2015 11:40 PM, sthaug@nethelp.no wrote:
> 
...
> 
>> Protecting the control plane can be done by the receiving host
>> (destination router).
> 
> This is a fundamental disagreement. Protecting the control plane needs
> to be done by *all* intermediate routers in today's somewhat hostile
> Internet environment. That also includes some traffic not explicitly
> addressed to the routers themselves (for instance traceroute to a
> destination reached *through* the routers). Only looking at traffic
> addressed to the routers themselves is not sufficient.

Sure - so here's the solution:

1) declare that your routers won't accept "host" packets (i.e., to their
interface addresses) that use EHs

	if you want to try, extend that to any AS whose routing
	packets you want to DDOS filter (but they need to think this
	is acceptable)

2) if you want to do DDOS filtering, do so on IP addresses for the
specific routers you are trying to protect

	either rate-limit everything to that address, drop
	anything with an EH, rate-limit/drop based on TCP/UDP
	ports, or any combination thereof

I.e., not using EHs is your prerogative, and not forwarding EHs to
others is *their* prerogative, but castrating IPv6 for the entire
Internet is not necessary.

Joe



> 
>> Protecting the network as a whole is useful, and may involve some level
>> of DPI - or may not. If the traffic is encrypted, then only the
>> destination router can protect itself anyway. But dropping the packets
>> because of EH use just makes the filtering router an attacker to the E2E
>> communication between the routers.
> 
> We have some services that are available within our AS, and should not
> be available outside the AS. One such example is DNS resolvers (there
> are others). We have chosen to block such services at the border - by
> having the border routers explicitly blocking UDP/TCP port 53 to the
> resolver addresses. This obviously means the border routers must be
> able to *find* the UDP/TCP header in that part of the IPv6 packet they
> are able to inspect at line rate. This is not "DPI" in any sense of
> the word - it is very basic filtering.
> 
> And here, I assume, is the next disagreement. If the UDP/TCP headers
> cannot be found because IPv6 EHs have pushed them beyond what the
> routers can inspect at line rate - the packet will be dropped.
> 
> If we can get improved filtering capabilities in our routers as part
> of regular equipment upgrade cycles - great, everybody is happy. But
> we are not likely to buy significantly more expensive routers *just*
> to be able to peek further into the packets (number of customers
> needing this are *many* orders of magnitude too low - if they exist
> at all).
> 
> Steinar Haug, AS 2116
> 


From nobody Wed Apr 22 10:26: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 A75871B38C2 for ; Wed, 22 Apr 2015 10:26:56 -0700 (PDT)
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 dP3eJzg_FHkX for ; Wed, 22 Apr 2015 10:26:55 -0700 (PDT)
Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84081AD0EA for ; Wed, 22 Apr 2015 10:26:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3MHQsNl001056; Wed, 22 Apr 2015 10:26:54 -0700
Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3MHQh6o000416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 22 Apr 2015 10:26:44 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.30]) with mapi id 14.03.0235.001; Wed, 22 Apr 2015 10:26:43 -0700
From: "Templin, Fred L" 
To: Joe Touch 
Thread-Topic: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
Thread-Index: AQHQfSBocvX3GrVyukWwwBTvA1/wuJ1ZSC1Q
Date: Wed, 22 Apr 2015 17:26:43 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832E4FB3E@XCH-BLV-504.nw.nos.boeing.com>
References: <553696EC.4060207@isi.edu>	<55369855.1040101@joelhalpern.com> <55369B2D.80906@isi.edu> <20150422.084056.74672865.sthaug@nethelp.no> <5537D7A6.4020106@isi.edu>
In-Reply-To: <5537D7A6.4020106@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 17:26:56 -0000

Hi, we will want to make use of IPv6 EHs (at least Destination Options
and Fragment Header). Are people trying to get rid of them altogether?

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: Wednesday, April 22, 2015 10:17 AM
> To: sthaug@nethelp.no
> Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org; v6ops@ietf.or=
g; merike@doubleshotsecurity.com;
> fgont@si6networks.com
> Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarificati=
on text
>=20
>=20
>=20
> On 4/21/2015 11:40 PM, sthaug@nethelp.no wrote:
> > 
> ...
> >
> >> Protecting the control plane can be done by the receiving host
> >> (destination router).
> >
> > This is a fundamental disagreement. Protecting the control plane needs
> > to be done by *all* intermediate routers in today's somewhat hostile
> > Internet environment. That also includes some traffic not explicitly
> > addressed to the routers themselves (for instance traceroute to a
> > destination reached *through* the routers). Only looking at traffic
> > addressed to the routers themselves is not sufficient.
>=20
> Sure - so here's the solution:
>=20
> 1) declare that your routers won't accept "host" packets (i.e., to their
> interface addresses) that use EHs
>=20
> 	if you want to try, extend that to any AS whose routing
> 	packets you want to DDOS filter (but they need to think this
> 	is acceptable)
>=20
> 2) if you want to do DDOS filtering, do so on IP addresses for the
> specific routers you are trying to protect
>=20
> 	either rate-limit everything to that address, drop
> 	anything with an EH, rate-limit/drop based on TCP/UDP
> 	ports, or any combination thereof
>=20
> I.e., not using EHs is your prerogative, and not forwarding EHs to
> others is *their* prerogative, but castrating IPv6 for the entire
> Internet is not necessary.
>=20
> Joe
>=20
>=20
>=20
> >
> >> Protecting the network as a whole is useful, and may involve some leve=
l
> >> of DPI - or may not. If the traffic is encrypted, then only the
> >> destination router can protect itself anyway. But dropping the packets
> >> because of EH use just makes the filtering router an attacker to the E=
2E
> >> communication between the routers.
> >
> > We have some services that are available within our AS, and should not
> > be available outside the AS. One such example is DNS resolvers (there
> > are others). We have chosen to block such services at the border - by
> > having the border routers explicitly blocking UDP/TCP port 53 to the
> > resolver addresses. This obviously means the border routers must be
> > able to *find* the UDP/TCP header in that part of the IPv6 packet they
> > are able to inspect at line rate. This is not "DPI" in any sense of
> > the word - it is very basic filtering.
> >
> > And here, I assume, is the next disagreement. If the UDP/TCP headers
> > cannot be found because IPv6 EHs have pushed them beyond what the
> > routers can inspect at line rate - the packet will be dropped.
> >
> > If we can get improved filtering capabilities in our routers as part
> > of regular equipment upgrade cycles - great, everybody is happy. But
> > we are not likely to buy significantly more expensive routers *just*
> > to be able to peek further into the packets (number of customers
> > needing this are *many* orders of magnitude too low - if they exist
> > at all).
> >
> > Steinar Haug, AS 2116
> >
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Wed Apr 22 10:55: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 2BD681A8874 for ; Wed, 22 Apr 2015 10:55:00 -0700 (PDT)
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 VWl9SKZ9EHfp for ; Wed, 22 Apr 2015 10:54:58 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBF61ACE64 for ; Wed, 22 Apr 2015 10:54:54 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1F9FB608CE for ; Wed, 22 Apr 2015 19:54:53 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C2927607F0 for ; Wed, 22 Apr 2015 19:54:52 +0200 (CEST)
Received: (qmail 9818 invoked by uid 1007); 22 Apr 2015 19:54:52 +0200
Date: Wed, 22 Apr 2015 19:54:52 +0200
From: Gert Doering 
To: Joe Touch 
Message-ID: <20150422175452.GK54385@Space.Net>
References: <553696EC.4060207@isi.edu> <55369855.1040101@joelhalpern.com> <55369B2D.80906@isi.edu> <20150422.084056.74672865.sthaug@nethelp.no> <5537D7A6.4020106@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5537D7A6.4020106@isi.edu>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, merike@doubleshotsecurity.com, fgont@si6networks.com
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 17:55:00 -0000

Hi,

On Wed, Apr 22, 2015 at 10:17:26AM -0700, Joe Touch wrote:
> I.e., not using EHs is your prerogative, and not forwarding EHs to
> others is *their* prerogative, but castrating IPv6 for the entire
> Internet is not necessary.

I'm not sure what the benfefit is in insisting that IPv6 as currently 
standardized is The Only And Proper Way To Do Networking?  It was designed
20 years ago, and some of the assumptions from back then are turning out
to cause enormous amount of friction today.

"Forwarding packets with EH" is one aspect of this, "RA guard" is 
another one, and "correctly operating firewalls" (be it host-based or
traditional perimeter based) is a third one.

So what's wrong with just fixing the damn protocol, and doing something
productive with our time, like, "play with our kids"?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Wed Apr 22 11:04:37 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 C56581ACF02 for ; Wed, 22 Apr 2015 11:04:35 -0700 (PDT)
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 c4C1IZE9cx7I for ; Wed, 22 Apr 2015 11:04:34 -0700 (PDT)
Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27C61ACEFD for ; Wed, 22 Apr 2015 11:04:27 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3MI1mwu007001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2015 11:01:50 -0700 (PDT)
Message-ID: <5537E20C.5030804@isi.edu>
Date: Wed, 22 Apr 2015 11:01:48 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Gert Doering 
References: <553696EC.4060207@isi.edu> <55369855.1040101@joelhalpern.com> <55369B2D.80906@isi.edu> <20150422.084056.74672865.sthaug@nethelp.no> <5537D7A6.4020106@isi.edu> <20150422175452.GK54385@Space.Net>
In-Reply-To: <20150422175452.GK54385@Space.Net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, merike@doubleshotsecurity.com, fgont@si6networks.com
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 18:04:35 -0000

On 4/22/2015 10:54 AM, Gert Doering wrote:
> Hi,
> 
> On Wed, Apr 22, 2015 at 10:17:26AM -0700, Joe Touch wrote:
>> I.e., not using EHs is your prerogative, and not forwarding EHs to
>> others is *their* prerogative, but castrating IPv6 for the entire
>> Internet is not necessary.
> 
> I'm not sure what the benfefit is in insisting that IPv6 as currently 
> standardized is The Only And Proper Way To Do Networking?  It was designed
> 20 years ago, and some of the assumptions from back then are turning out
> to cause enormous amount of friction today.

And might not tomorrow.

There are a lot of reasons why EHs are critical - source fragmentation
is one very important one.

> "Forwarding packets with EH" is one aspect of this, "RA guard" is 
> another one, and "correctly operating firewalls" (be it host-based or
> traditional perimeter based) is a third one.
> 
> So what's wrong with just fixing the damn protocol, and doing something
> productive with our time, like, "play with our kids"?

Nothing is wrong with fixing something that's broken.

That includes routers that don't support EH, and maybe the long shopping
list of "what if" extensions that we might not need. It also might
include a "jump to the transport header" EH.

But, FWIW, none of these problems are going away even without EHs. Today
it's EHs, tomorrow it'll be tunnel headers (which have the same
problem), and the next it'll be encryption.

It's always useful to explore the entire constellation of what needs to
be done. If it's critical to update IPv6, that ought to be done in
INTAREA, not as a convenience for operators, though.

Joe


From nobody Wed Apr 22 11:34: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 05AB61AD1EE for ; Wed, 22 Apr 2015 11:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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] 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 3NuTg92uZTWd for ; Wed, 22 Apr 2015 11:34:04 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (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 20D761AD16B for ; Wed, 22 Apr 2015 11:34:03 -0700 (PDT)
Received: by wgin8 with SMTP id n8so255723339wgi.0 for ; Wed, 22 Apr 2015 11:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=aKexKOhQsCSd8HL8V9O95+HCgdVSGRCBr6IgBQn6eZQ=; b=EYpfl7MVZBrZRc/gFVtmz9Wy1Jf7Xrf4at7zkL92lXvr0XQJ+Q6HNwyALhfCyhA5WR G8v0repjhVU9EmDr17K/BYo4S8huzL3HRUsjaN1rNXPDVgxRvK7jwpXoSAn7Sd9zD/p8 y8eeLivIfQOynbUJ64srxnAKHoervoGG/Z1Ws=
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=aKexKOhQsCSd8HL8V9O95+HCgdVSGRCBr6IgBQn6eZQ=; b=AQO0t1I4T4lfHXyzdJOu7yRlhwzk1sE8JC7g8A99urPxYA8gfINI0texdbgKqPAIPH szL60foWELnDlrCC77tRA3nj30QCoqMbolqWBBGslIjKXcXHGlwHD3Npt56Sw1HN3zJT /wqCiQPVgevaB7yLY7e3Tt5pRpYxFYtuF/X7rfbA/+iWanR56W+OHsC1NkOsg0KxEE60 eE4ltXGw4RpDhedjKmhc7H2PfrhS6drL4Grhnd0zOxKAiqJyvvg1BL4OZZUyE0ZhlWOE NUCEr980KTq1qfE+QVZkZ2g5yNwYgDdAflXco6ILkqJSUakUYmAmsQCDefJmwKMNkUeT K2HQ==
X-Gm-Message-State: ALoCoQlAODJEguQO43eVrS2dp7d/7N+wzQ3dWn3AvDojE9b7lFbGNod/+iVecQd9Z7egkXgzx9XM
MIME-Version: 1.0
X-Received: by 10.180.73.198 with SMTP id n6mr8545968wiv.3.1429727642699; Wed, 22 Apr 2015 11:34:02 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Wed, 22 Apr 2015 11:34:02 -0700 (PDT)
In-Reply-To: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com> 
Date: Wed, 22 Apr 2015 11:34:02 -0700
Message-ID: 
From: James Woodyatt 
To: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary=f46d0435c06c44dfab0514546807
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 18:34:05 -0000

--f46d0435c06c44dfab0514546807
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 22, 2015 at 7:35 AM, Ca By  wrote:

>
> [...]  So what is an ipv4-poor network to do? [...]
>

I thought this thread was about what the IETF should recommend everyone to
do.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--f46d0435c06c44dfab0514546807
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Apr 22, 2015 at 7:35 AM, Ca By <cb.list6@gmail.com> wro=
te:

[...] =C2=A0So what i=
s an ipv4-poor network to do? [...]

I thought this thread was about what the IETF should recommend every=
one to do.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs,=
 Communications Engineering




--f46d0435c06c44dfab0514546807--


From nobody Wed Apr 22 12:55: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 1AA431B2A5E for ; Wed, 22 Apr 2015 12:55:54 -0700 (PDT)
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 t6RBcV9tQbn6 for ; Wed, 22 Apr 2015 12:55:53 -0700 (PDT)
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 18E161B2A08 for ; Wed, 22 Apr 2015 12:55:53 -0700 (PDT)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 93B93DA008E; Wed, 22 Apr 2015 19:55:52 +0000 (UTC)
Received: from [10.0.20.195] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 22 Apr 2015 12:55:52 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Wed, 22 Apr 2015 15:55:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 19:55:54 -0000

On Apr 22, 2015, at 2:34 PM, James Woodyatt  wrote:
> I thought this thread was about what the IETF should recommend =
everyone to do.

The IETF should recommend that everybody stop using IPv4 literals, if =
there is a way to do that (it's not clear to me that there is).


From nobody Wed Apr 22 13:48:40 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 61F741A1A2C for ; Wed, 22 Apr 2015 13:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 kbUhmjT0_d9o for ; Wed, 22 Apr 2015 13:48:38 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id E21BC1A1A2D for ; Wed, 22 Apr 2015 13:48:37 -0700 (PDT)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,626,1422939600"; d="scan'208";a="677535336"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Apr 2015 16:32:23 -0400
Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 22 Apr 2015 16:48:35 -0400
From: "Howard, Lee" 
To: Ted Lemon , James Woodyatt 
Date: Wed, 22 Apr 2015 16:48:34 -0400
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AdB9PbOIADwWQQpVTGGbUJCla0IS+Q==
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>
In-Reply-To: <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 20:48:39 -0000

On 4/22/15, 3:55 PM, "Ted Lemon"  wrote:

>On Apr 22, 2015, at 2:34 PM, James Woodyatt  wrote:
>> I thought this thread was about what the IETF should recommend everyone
>>to do.
>
>The IETF should recommend that everybody stop using IPv4 literals, if
>there is a way to do that (it's not clear to me that there is).


I look forward to reading draft-lemon-ipv4literals-considered-harmful

:)
Lee


This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.


From nobody Wed Apr 22 15:36:41 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 04F241B3ACD for ; Wed, 22 Apr 2015 15:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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] 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 TR1BltP9gTHp for ; Wed, 22 Apr 2015 15:36:40 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 A33301B3AC9 for ; Wed, 22 Apr 2015 15:36:38 -0700 (PDT)
Received: by wgen6 with SMTP id n6so582560wge.3 for ; Wed, 22 Apr 2015 15:36:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=n03YUufqemy2HGZ3Gd9r5udgU0jLGgiJ35Dcmxg0k1s=; b=aUj03qicTJbpggDoD0Tp0LBhVw4wORfik0ZCEfjKbnJ+Fy4D32WCLKuM7IA/bgIfB0 6b+v+JyNVTqxEz/XYXO9imhODiPZR8bW3BQmR2spXR6Sg0VEZzVW7eWPWSOYBH0mKJae 4+5SFnkTyUtwJCGkMrVsVlE3Vr+CLiA4aV330=
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=n03YUufqemy2HGZ3Gd9r5udgU0jLGgiJ35Dcmxg0k1s=; b=F/I/o8Ti0ikx0zhazwlVmg7eToPdXwHou14uxiMSMIej2yCjTuNU7ZL04wgibhC5aZ cXnxdXl8ZBtsaftzHcz6o4/vH4QSIgWZgRnNIxWBRKXFqcgHXTb09e66y/H5giHGtv1k It16rV2YezrNLNjCMYJ0xAf/vTGRGcDPyw17EhDvAYiywJ0aKnpxOo2Eb++5jqagGHWK d4vQxJIEqHRe6ug8yGYsvffEShrRfsVZvylzXXK6jdelbe8IokwqZlCAcsQCheC35i/z o1IVFIap2cLedds7WXcgNNSOcuuYhdDTfw1bpZFi4ZcZuaCEth0uDqrCDOX2eDnetdRV kCeA==
X-Gm-Message-State: ALoCoQkA9VYa+kbaBS8zkmeD2NlgFzo6/KaI/DVXByBlEi2efWcVGR0Gf6zJGB+jjtbZZxwWa+pH
MIME-Version: 1.0
X-Received: by 10.194.71.208 with SMTP id x16mr53462231wju.129.1429742197350;  Wed, 22 Apr 2015 15:36:37 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Wed, 22 Apr 2015 15:36:37 -0700 (PDT)
In-Reply-To: <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>
Date: Wed, 22 Apr 2015 15:36:37 -0700
Message-ID: 
From: James Woodyatt 
To: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary=047d7bfcead0cb3d27051457cbd6
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 22:36:41 -0000

--047d7bfcead0cb3d27051457cbd6
Content-Type: text/plain; charset=UTF-8

I'm not optimistic that consensus would emerge for that recommendation.

Again: I think if 464XLAT promoters want to direct their energies on this
topic in the most useful direction possible, then the best course of action
would be to prepare drafts for updating RFC 3493 and RFC 3542 accordingly.
In particular, I think it's critical to have a clear understanding of
precisely what features of the PF_INET interfaces are expected to be
handled by the CLAT function. If the IP_PKTINFO socket option, for example,
is expected to be unsupported, then it's important to know that. What does
the CLAT do with IPv4 link-local scope addresses? What about the
SO_REUSEADDR option? A good place to start would probably be to go through
the entire POSIX.1 standard, and for all the IPv4 networking interfaces,
describe what is and isn't supported by the CLAT function recommended by
IETF.

If this stuff is going to be a standard feature of host operating system
for the foreseeable future, then I for one would like it to be standardized
as well as the current IPv6 programming interfaces are standardized. I
don't think that's an unreasonable position to start.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--047d7bfcead0cb3d27051457cbd6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm not optimistic that consensus would emerge for tha=
t recommendation.

Again: I think if 464XLAT promoters wa=
nt to direct their energies on this topic in the most useful direction poss=
ible, then the best course of action would be to prepare drafts for=C2=A0updating RFC 3493 and RFC 3542 a=
ccordingly. In particular, I think it's critical to have a clear unders=
tanding of precisely what features of the PF=
_INET interfaces=C2=A0are expected =
to be handled by the CLAT function. If the IP_PKTINFO socket option, for ex=
ample, is expected to be unsupported, then it's important to know that.=
 What does the CLAT do with IPv4 link-local scope addresses? What about the=
 SO_REUSEADDR option? A good place to start would probably be to go through=
 the entire POSIX.1 standard, and for all the IPv4 networking interfaces, d=
escribe what is and isn't supported by the CLAT function recommended by=
 IETF.

<=
div>If this stuff is going to be a standar=
d feature of host operating system for the foreseeable future, then I for o=
ne would like it to be standardized as well as the current IPv6 programming=
 interfaces are standardized. I don't think that's an unreasonable =
position to start.


-- 
james woodyatt <jhw@nestlabs.com>
Nes=
t Labs, Communications Engineering




--047d7bfcead0cb3d27051457cbd6--


From nobody Wed Apr 22 16:13: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 14EBD1A8AC8 for ; Wed, 22 Apr 2015 16:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12oxdHUKUNU3 for ; Wed, 22 Apr 2015 16:13:45 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (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 B26311A8BC3 for ; Wed, 22 Apr 2015 16:13:33 -0700 (PDT)
Received: by pdea3 with SMTP id a3so1335103pde.3 for ; Wed, 22 Apr 2015 16:13:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=swC1BLukRYFqXXoCoz7E4prh0q6j4yyz/2w/R9M1k14=; b=mEHPY9wEl8bHXcOXUsH8njyTNM1yilgNA0Qucrdz85ilQaBEU/k0ticd20++jGtYxL yjay2E36+hfVs9wPReFfeIzK2SrQmuHtzziH8I0N5nkG7/7cchCN/TS0grhguPIA5h+G Z6l1uNiQGin2JrjsxHjj/yvlzaUgXBU6CBpe7UmEStZmJoOzoIrxyfopm+aFUs+gjj8N f43FfC70HuMAUxnne+Y/rAc8I/1Ys0fYYObZIuT8QWyXQNOZXhscikD/b01mFmPbpV8z +Qdd8+RHm7pXc4tmZIllewSzd68w9CaargnRhMiJhPh58O4CJdlfvDJWvHABZCF0gV1y X/lw==
X-Received: by 10.70.45.79 with SMTP id k15mr51870245pdm.78.1429744413490; Wed, 22 Apr 2015 16:13:33 -0700 (PDT)
Received: from ?IPv6:2406:e007:55fb:1:28cc:dc4c:9703:6781? ([2406:e007:55fb:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id fh9sm6128276pdb.17.2015.04.22.16.13.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 16:13:32 -0700 (PDT)
Message-ID: <55382B21.4040508@gmail.com>
Date: Thu, 23 Apr 2015 11:13:37 +1200
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.6.0
MIME-Version: 1.0
To: Ray Hunter , Gert Doering 
References: <5536814D.7030708@foobar.org> <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com> <20150422085138.GE54385@Space.Net> <553778BF.4050706@globis.net>
In-Reply-To: <553778BF.4050706@globis.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 23:13:47 -0000

On 22/04/2015 22:32, Ray Hunter wrote:

...
> IMHO I think this problem was already fixed at the protocol level by https://tools.ietf.org/html/rfc7112

Exactly, which is one of the many reasons why we need RFC2460bis.

   Brian


From nobody Wed Apr 22 16:30: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 B37321B2B56 for ; Wed, 22 Apr 2015 16:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 TFRMpTfvztzn for ; Wed, 22 Apr 2015 16:30:26 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72FA1B2B58 for ; Wed, 22 Apr 2015 16:30:18 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 660AA1FCC7D; Wed, 22 Apr 2015 23:30:15 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A6C2416003C; Wed, 22 Apr 2015 23:30:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 60B32160071; Wed, 22 Apr 2015 23:30:21 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id klYAph6qQ28q; Wed, 22 Apr 2015 23:30:21 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id AF8AF16003C; Wed, 22 Apr 2015 23:30:20 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D70122D660D1; Thu, 23 Apr 2015 09:30:10 +1000 (EST)
To: James Woodyatt 
From: Mark Andrews 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303 E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com> 
In-reply-to: Your message of "Wed, 22 Apr 2015 15:36:37 -0700." 
Date: Thu, 23 Apr 2015 09:30:09 +1000
Message-Id: <20150422233010.D70122D660D1@rock.dv.isc.org>
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Apr 2015 23:30:28 -0000

In message , James Woodya
tt writes:
> 
> I'm not optimistic that consensus would emerge for that recommendation.
> 
> Again: I think if 464XLAT promoters want to direct their energies on this
> topic in the most useful direction possible, then the best course of action
> would be to prepare drafts for updating RFC 3493 and RFC 3542 accordingly.
> In particular, I think it's critical to have a clear understanding of
> precisely what features of the PF_INET interfaces are expected to be
> handled by the CLAT function. If the IP_PKTINFO socket option, for example,
> is expected to be unsupported, then it's important to know that. What does
> the CLAT do with IPv4 link-local scope addresses? What about the
> SO_REUSEADDR option? A good place to start would probably be to go through
> the entire POSIX.1 standard, and for all the IPv4 networking interfaces,
> describe what is and isn't supported by the CLAT function recommended by
> IETF.
> 
> If this stuff is going to be a standard feature of host operating system
> for the foreseeable future, then I for one would like it to be standardized
> as well as the current IPv6 programming interfaces are standardized. I
> don't think that's an unreasonable position to start.

Part of that is getting the Advanced Socket API recognised by POSIX.
As a developer it is a right pain in the backside that it isn't and
you have to do different magic incantations to make the Advanced
Socket API visible on different platforms.

Making "socket(AF_INET,...)" fail would also be a interesting idea.
You can talk to IPv4 nodes over socket(AF_INET6, ...) using mapped
addresses.

A boring but useful Google Code project would be to go through the
OSS that is still IPv4 only and add IPv6 support.   Adding fast
failover to the next address would also be useful at the same time.
Pick a something like FreeBSD ports and bring all current ports up
to scratch.

> -- 
> james woodyatt 
> Nest Labs, Communications Engineering
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Apr 22 18:46: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 2F7281B2D46 for ; Wed, 22 Apr 2015 18:46:33 -0700 (PDT)
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 kw50cEtGdCeF for ; Wed, 22 Apr 2015 18:46:32 -0700 (PDT)
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 14D5A1B2D31 for ; Wed, 22 Apr 2015 18:46:14 -0700 (PDT)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id A20EBDA0098; Thu, 23 Apr 2015 01:46:13 +0000 (UTC)
Received: from [10.0.20.195] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 22 Apr 2015 18:46:13 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Wed, 22 Apr 2015 21:46:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Apr 2015 01:46:33 -0000

On Apr 22, 2015, at 6:36 PM, James Woodyatt  wrote:
> If this stuff is going to be a standard feature of host operating =
system for the foreseeable future, then I for one would like it to be =
standardized as well as the current IPv6 programming interfaces are =
standardized. I don't think that's an unreasonable position to start.

I think this is a very reasonable position.   However, not everybody in =
the IETF thinks we should be defining APIs, and there's the rub.   =
Nominally, APIs of this sort are a POSIX thing.


From nobody Thu Apr 23 11:45: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 BD6A31B3194 for ; Thu, 23 Apr 2015 11:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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] 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 ys9Qc15EBPvC for ; Thu, 23 Apr 2015 11:45:42 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 656A41B3190 for ; Thu, 23 Apr 2015 11:45:42 -0700 (PDT)
Received: by wgso17 with SMTP id o17so27985236wgs.1 for ; Thu, 23 Apr 2015 11:45:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yRtJ3V+2Vyvrigbp02GF7+uKrjurw3D5zQ2dF7oZBqA=; b=UggbR14hu+2YFT90GLrTb+6b620oPBhhIU7AmDvDQBC2PKVv00Vu1ACNDjI0UlAfHq V/wThWEhSqT4mtluR8QpbqW8/yJSdDxMy9IQX4Ofak46tmY+ZZdSue2sd1K3jOL8+7zA 3IN5Ry5WNSjthP5Pxjb1dgEtcUwRJ/XK7hReU=
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=yRtJ3V+2Vyvrigbp02GF7+uKrjurw3D5zQ2dF7oZBqA=; b=S30tfqd0N+/0PicPuwRA08G1vb7s+SxhKiyaws7JzVV82QQHQEv5EUg7qInjfU3O/R xvKRBlsEonvL9wvzhZbDA0msFMHH9PP5/HHZMNg+A/SCdd80HYX5WeocIjuGrVFx221C b/gOmcNqDYofHuZvW1+Fa8MkkyFhPYVjjlG3LO7J1rU6DOdPHvN2Ni0unzWl5RPdx2BD LxNicMES1R6XdS0URqKd/4ts8+D7P9ezV9o12I6UdIk9sePUlntkkAVDtqAxbSrVNaco 7ChQZIeZmna4Nu6WAMYhOQYhhqCPFXzBwk+ZJsY8OXVZXxFpqRjWvbKWQuzUV67IRhsc hcfw==
X-Gm-Message-State: ALoCoQl58SrS168p3mnGadk5YkO42kNHB8WoJTZAgxStol2CPium5hwE6zzGiLA00EnicID2dFBp
MIME-Version: 1.0
X-Received: by 10.194.52.10 with SMTP id p10mr7921860wjo.98.1429814741079; Thu, 23 Apr 2015 11:45:41 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Thu, 23 Apr 2015 11:45:40 -0700 (PDT)
In-Reply-To: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>  
Date: Thu, 23 Apr 2015 11:45:40 -0700
Message-ID: 
From: James Woodyatt 
To: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary=047d7bae4286bcac39051468af66
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Apr 2015 18:45:43 -0000

--047d7bae4286bcac39051468af66
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ted=E2=80=94

I'm not saying IETF should obsolete the excellent work that POSIX has
already done. I'm simply saying that IETF is probably the better place to
define what the POSIX network programming interfaces for IPv4 are expected
to do on hosts with IPv6 network interfaces and an integrated CLAT
function. I further think this work would be more suitable for 6MAN than
V6OPS, and until I see a standard track draft adopted, I'm going to be
opposed to V6OPS adopting a work item to produce a BCP for host operating
systems to implement a CLAT function.

On Wed, Apr 22, 2015 at 6:46 PM, Ted Lemon  wrote:

> On Apr 22, 2015, at 6:36 PM, James Woodyatt  wrote:
> > If this stuff is going to be a standard feature of host operating syste=
m
> for the foreseeable future, then I for one would like it to be standardiz=
ed
> as well as the current IPv6 programming interfaces are standardized. I
> don't think that's an unreasonable position to start.
>
> I think this is a very reasonable position.   However, not everybody in
> the IETF thinks we should be defining APIs, and there's the rub.
>  Nominally, APIs of this sort are a POSIX thing.
>
>


--=20
james woodyatt 
Nest Labs, Communications Engineering

--047d7bae4286bcac39051468af66
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Ted=E2=80=94

I'm not saying IETF sh=
ould obsolete the excellent work that POSIX has already done. I'm simpl=
y saying that IETF is probably the better place to define what the POSIX ne=
twork programming interfaces for IPv4 are expected to do on hosts with IPv6=
 network interfaces and an integrated CLAT function. I further think this w=
ork would be more suitable for 6MAN than V6OPS, and until I see a standard =
track draft adopted, I'm going to be opposed to V6OPS adopting a work i=
tem to produce a BCP for host operating systems to implement a CLAT functio=
n.

On =
Wed, Apr 22, 2015 at 6:46 PM, Ted Lemon <Ted.Lemon@nominum.com>=
 wrote:
On Apr 22=
, 2015, at 6:36 PM, James Woodyatt <=
jhw@nestlabs.com> wrote:

> If this stuff is going to be a standard feature of host operating syst=
em for the foreseeable future, then I for one would like it to be standardi=
zed as well as the current IPv6 programming interfaces are standardized. I =
don't think that's an unreasonable position to start.



I think this is a very reasonable position.=C2=A0 =C2=A0However, not=
 everybody in the IETF thinks we should be defining APIs, and there's t=
he rub.=C2=A0 =C2=A0Nominally, APIs of this sort are a POSIX thing.







-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs,=
 Communications Engineering




--047d7bae4286bcac39051468af66--


From nobody Thu Apr 23 11:47: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 1487A1B3192; Thu, 23 Apr 2015 11:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAsiibi5kbSt; Thu, 23 Apr 2015 11:47:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A1D1ACEDE; Thu, 23 Apr 2015 11:47:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150423184705.31382.56349.idtracker@ietfa.amsl.com>
Date: Thu, 23 Apr 2015 11:47:05 -0700
Archived-At: 
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-in-real-world-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: Thu, 23 Apr 2015 18:47:10 -0000

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

        Title           : Observations on IPv6 EH Filtering in the Real World
        Authors         : Fernando Gont
                          J. Linkova
                          Tim Chown
                          Will(Shucheng) Liu
	Filename        : draft-ietf-v6ops-ipv6-ehs-in-real-world-00.txt
	Pages           : 16
	Date            : 2015-04-21

Abstract:
   This document presents real-world data regarding the extent to which
   packets with IPv6 extension headers are filtered in the Internet (as
   measured in August 2014), and where in the network such filtering
   occurs.  The aforementioned results serve as a problem statement that
   is expected to trigger operational advice on the filtering of IPv6
   packets carrying IPv6 Extension Headers, so that the situation
   improves over time.  This document also explains how the
   aforementioned results were obtained, such that the corresponding
   measurements can be reproduced by other members of the community.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world-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 Thu Apr 23 13:41: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 3CCA31B354E; Mon, 20 Apr 2015 16:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 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_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 QzpNnBhzLFjK; Mon, 20 Apr 2015 16:55:14 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 52A1E1B354C; Mon, 20 Apr 2015 16:55:13 -0700 (PDT)
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t3KNt2wp021161 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2015 19:55:03 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t3KNt2wp021161
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1429574103; bh=vvI7mdqwnp4UEbaR6HS0zqWGM1E=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hBpCtF6FgBGnsp4YR+FgYsRqiq9hG1KOb8tZ9n6fmUCAKYXBbGdFW4oniwgVMuSlQ su4q8ibF5gz/UU5cBG7TXo9UO45gi90x/wqIH3ieFbi8Howg6IUL8NtP9kObE/cpXS OjJlmI+BfkJaMbrmf+sgVJ4VSgu2ala9Q4TIfbEA=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t3KNt2wp021161
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 20 Apr 2015 19:55:06 -0400
Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t3KNsiDi001237 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Apr 2015 19:54:44 -0400
Received: from MXHUB203.corp.emc.com (10.253.68.29) by mxhub24.corp.emc.com (128.222.70.136) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 20 Apr 2015 19:54:44 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB203.corp.emc.com ([10.253.68.29]) with mapi id 14.03.0224.002; Mon, 20 Apr 2015 19:54:44 -0400
From: "Black, David" 
To: "mohamed.boucadair@orange.com" , "alexandre.petrescu@cea.fr" , "fred@cisco.com" , "General Area Review Team (gen-art@ietf.org)" 
Thread-Topic: Gen-ART review of draft-ietf-v6ops-cidr-prefix-01
Thread-Index: AdB7xV84EgWdL+8PRg+ua70vblqnKg==
Date: Mon, 20 Apr 2015 23:54:43 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.238.44.123]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public, Resumes
Archived-At: 
X-Mailman-Approved-At: Thu, 23 Apr 2015 13:41:37 -0700
Cc: "v6ops@ietf.org" , "ietf@ietf.org" , "Black, David" 
Subject: [v6ops] Gen-ART review of draft-ietf-v6ops-cidr-prefix-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 20 Apr 2015 23:55:16 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-v6ops-cidr-prefix-01
Reviewer: David Black
Review Date: April 20, 2015
IETF LC End Date: April 20, 2015

Summary: This draft is basically ready for publication, but has nits that
	should be fixed before publication.

This is a short crisp draft on behavior of CIDR prefixes in IPv6 forwarding
with respect to the /64 boundary in IPv6 addresses.  It's clear, well expla=
ined
easy to understand, plus refreshingly short.  Nicely done!

Major issues: (none)

Minor issues: (none)

Nits/editorial comments: Ok, I found a nit ... and so did idnits ;-).

-- Abstract

   Hardware and software
   algorithms should therefore impose no rules on prefix length, but
   implement longest-match-first on prefixes of any valid length.

"algorithms" isn't the right word.
I suggest "implementations of routing and forwarding"

idnits pointed out that: A later version (-06) exists of
     draft-ietf-opsec-v6-05

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778=
6
david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754
----------------------------------------------------



From nobody Thu Apr 23 14:17: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 6A32F1B3488 for ; Thu, 23 Apr 2015 14:17:18 -0700 (PDT)
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 NjZfDo-r-tAQ for ; Thu, 23 Apr 2015 14:17:17 -0700 (PDT)
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 CBF021B3483 for ; Thu, 23 Apr 2015 14:17:10 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 54BBEDA007D; Thu, 23 Apr 2015 21:17:10 +0000 (UTC)
Received: from [10.0.20.108] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 23 Apr 2015 14:17:03 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 23 Apr 2015 17:17:00 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>   
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Apr 2015 21:17:18 -0000

On Apr 23, 2015, at 2:45 PM, James Woodyatt  wrote:
> I'm not saying IETF should obsolete the excellent work that POSIX has =
already done. I'm simply saying that IETF is probably the better place =
to define what the POSIX network programming interfaces for IPv4 are =
expected to do on hosts with IPv6 network interfaces and an integrated =
CLAT function. I further think this work would be more suitable for 6MAN =
than V6OPS, and until I see a standard track draft adopted, I'm going to =
be opposed to V6OPS adopting a work item to produce a BCP for host =
operating systems to implement a CLAT function.

Would you be willing to co-author such a document?


From nobody Thu Apr 23 15:04: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 280F91B34CA for ; Thu, 23 Apr 2015 15:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.51
X-Spam-Level: 
X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 i1TEa5sgN5C7 for ; Thu, 23 Apr 2015 15:04:09 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674D01A8ACE for ; Thu, 23 Apr 2015 15:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3837; q=dns/txt; s=iport; t=1429826643; x=1431036243; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xAdvWH8DKfJVva4rF4o5Fejc95NFEZtevZw5yrs2c+E=; b=MTls+ylU/dKW0qwEW42Pa4bWy/XU9z3cBqGrVkaw0VtF0iEhswJY2fX4 jqQfbhNu9rY78YbaO930USz4Jb5JC2YpG3WdDFXhwdlmTx/vgiloWKgsd NF+vl0A8nDqgVojCDqCTepqoKpLP5qf5KMVvym+fKHNARSTb2ajWLyAaN o=;
X-Files: signature.asc : 487
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BVBADjazlV/51dJa1bgkVHgS4FgxXDCwmHVQKBODgUAQEBAQEBAYEKhCABAQEDASNWBQsCAQgECgojBwICMiUCBA4FDg2ICAi3YZULAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s3hQQHgmgvgRYFkUqBcoE3hwyVSyOCOIE8b4FEgQABAQE
X-IronPort-AV: E=Sophos;i="5.11,634,1422921600";  d="asc'?scan'208,217";a="144044060"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 23 Apr 2015 22:04:02 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3NM42wL018033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 22:04:02 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.172]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 17:04:02 -0500
From: "Fred Baker (fred)" 
To: James Woodyatt 
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQfhFoi9xfHPG68U2v30TUFA6RKA==
Date: Thu, 23 Apr 2015 22:04:02 +0000
Message-ID: 
References:   <20150320134204.32af9c67@echo.ms.redpill-linpro.com>  <550F1F1F.3060703@cernet.edu.cn>                 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.64.121]
Content-Type: multipart/signed; boundary="Apple-Mail=_B59BA143-396A-45D7-8750-F272A567725E"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Apr 2015 22:04:11 -0000

--Apple-Mail=_B59BA143-396A-45D7-8750-F272A567725E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F606D218-C224-4904-9756-1C1229D0A2B4"


--Apple-Mail=_F606D218-C224-4904-9756-1C1229D0A2B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Apr 3, 2015, at 2:15 PM, James Woodyatt  wrote:
>=20
> I think the former entails the latter. I think we get away from =
running IPv4 by deliberately and carefully removing support for IPv4 =
from application developers and users in a way that continuously makes =
forward progress at a manageable and predictable expense. If we deploy =
CLAT everywhere, then we will be making IPv4 more difficult to displace =
by removing support for it in the network.


I 75% agree. I think we move from IPv4 to ipv6 by making applications =
version agnostic (e.g., use getaddrinfo() rather than gethostbyname()), =
and getting networks to turn on IPv6 in the infrastructure. Given that, =
at someone economics kicks in. It=E2=80=99s cheaper to run one network =
than two.

--Apple-Mail=_F606D218-C224-4904-9756-1C1229D0A2B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Apr 3, 2015, at 2:15 PM, James Woodyatt <jhw@nestlabs.com> =
wrote:

I think the former entails the latter. I think we get away =
from running IPv4 by deliberately and carefully removing support for =
IPv4 from application developers and users in a way that continuously =
makes forward progress at a manageable and predictable expense. If we =
deploy CLAT everywhere, then we will be making IPv4 more difficult to =
displace by removing support for it in the =
network.


I 75% agree. I think we =
move from IPv4 to ipv6 by making applications version agnostic (e.g., =
use getaddrinfo() rather than gethostbyname()), and getting networks to =
turn on IPv6 in the infrastructure. Given that, at someone economics =
kicks in. It=E2=80=99s cheaper to run one network than =
two.
=

--Apple-Mail=_F606D218-C224-4904-9756-1C1229D0A2B4--

--Apple-Mail=_B59BA143-396A-45D7-8750-F272A567725E
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

iQEVAwUBVTlsUJ9ieig10VPpAQKoWAf/TVnbiPByD3f9/HHMq9YQVfWLNgHbTtLz
9RAZNzMGPGKglanakf6+g68YEeUaZhfjnKcVJ/beKs5drMEq7I8llqraZZnS6Iw8
Auk6ihy89BueXhl/gUcDlK7mGxpMMW+L7VbCiafz9Le1Ho6cpr2k832HZLQc9TB+
b+Y0aZ9X0PlLTyk2WTb/Qfa+Nkt6e6H6luQggN0c5zl5h4bhkWj3MpSSoj0zupX5
hYdKCVnsUS+pMCa0nsLgk5gQ7ueegPGonBR3+3QXpQgRxcYXD5cAEmyuExfq1OD6
oYepK95NWbLTDFk1bOg0L0B4XyynhGUTEDB1MTn6OHM/r9qyWNk+EA==
=fkDQ
-----END PGP SIGNATURE-----

--Apple-Mail=_B59BA143-396A-45D7-8750-F272A567725E--


From nobody Thu Apr 23 19:27: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 DEB4D1A00F7 for ; Thu, 23 Apr 2015 19:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WXlND335_pq for ; Thu, 23 Apr 2015 19:27:53 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 E82D21B2B2B for ; Thu, 23 Apr 2015 19:27:31 -0700 (PDT)
Received: by wiax7 with SMTP id x7so24986809wia.0 for ; Thu, 23 Apr 2015 19:27:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+Z9ltBW6Fs2wo6kHZ/hf7WefxQIHW80XQwZq3Xdwmh4=; b=P4ECNsveBRBZXM/Nwfkpbks54m9hGI8KIi/UDskaWnnjYa6526rQkoGaiOAyiroiE2 tLbPWIwCJvfF1mJl1OCovu0SpmhiJgS6Dl7S6wuqxpwIfzYzL4a2bzYj7hF3cm3Zn5hm c/zFZ0UKDfepZq0q8RQ8ri/idYvuOg+wwoslLogxwnVuJXxWbsDruLizJCbRZPY7gQVD rnBqWqsQ1nImUZJyrrp9TpePDV+fBoO/49LjL+jwNXICyLhPWyauVDN4VXVj/sf3jGy/ o31Wkt+ynhQBzAtTwfN6q0Xp+aYAH3q/l99WGRcut5e0Uzc0UdKXscjh8GGEzsCH8X3i HSlg==
MIME-Version: 1.0
X-Received: by 10.194.61.133 with SMTP id p5mr11446241wjr.132.1429842450761; Thu, 23 Apr 2015 19:27:30 -0700 (PDT)
Received: by 10.194.40.231 with HTTP; Thu, 23 Apr 2015 19:27:30 -0700 (PDT)
In-Reply-To: 
References:   <20150320134204.32af9c67@echo.ms.redpill-linpro.com>  <550F1F1F.3060703@cernet.edu.cn>                  
Date: Thu, 23 Apr 2015 19:27:30 -0700
Message-ID: 
From: Ca By 
To: "Fred Baker (fred)" 
Content-Type: multipart/alternative; boundary=047d7bacb5985cca8605146f23b2
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 02:27:55 -0000

--047d7bacb5985cca8605146f23b2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, April 23, 2015, Fred Baker (fred)  wrote:

>
> On Apr 3, 2015, at 2:15 PM, James Woodyatt  > wrote:
>
> I think the former entails the latter. I think we get away from running
> IPv4 by deliberately and carefully removing support for IPv4 from
> application developers and users in a way that continuously makes forward
> progress at a manageable and predictable expense. If we deploy CLAT
> everywhere, then we will be making IPv4 more difficult to displace by
> removing support for it in the network.
>
>
>
> I 75% agree. I think we move from IPv4 to ipv6 by making applications
> version agnostic (e.g., use getaddrinfo() rather than gethostbyname()), a=
nd
> getting networks to turn on IPv6 in the infrastructure. Given that, at
> someone economics kicks in. It=E2=80=99s cheaper to run one network than =
two.
>


What is the estimated time to turn the ship via this method? Meaning, when
will tangible results be delivered such that a network operator could
deploy ipv6-only?  You mentioned ecomomics, will the audiance for the api
change have a money benefit directly, or is this another case of misaligned
work / benefit ?

b4 and clat are already deployed at a meaningful scale on multiple
continents enabling ipv6 only. The network operators have done the work and
realized the benefit of ipv6-only.

I dont want to waste ietf time on re-inventing the wheel and writie docs of
an audience that wont read it.  we know how to do ipv6-only access networks
in the real world at scale with the work / benefit aligned.

CB

--047d7bacb5985cca8605146f23b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, April 23, 2015, Fred Baker (fred) <fred@cisco.com> wrote:

On Apr 3, 2015, at 2:15 PM, James Woodyatt <=
jhw@nestlabs.com> wrote:

I think the former entails the latter. I think we get away from=
 running IPv4 by deliberately and carefully removing support for IPv4 from =
application developers and users in a way that continuously makes forward p=
rogress at a manageable and predictable expense. If we deploy CLAT everywhe=
re, then we will be making IPv4 more difficult to displace by removing supp=
ort for it in the network.

I 75% agree. I think we move from IPv4 to ipv6 by making applic=
ations version agnostic (e.g., use getaddrinfo() rather than gethostbyname(=
)), and getting networks to turn on IPv6 in the infrastructure. Given that,=
 at someone economics kicks in. It=E2=80=99s cheaper to run one network tha=
n two.


What is t=
he estimated time to turn the ship via this method? Meaning, when will tang=
ible results be delivered such that a network operator could deploy ipv6-on=
ly?=C2=A0 You mentioned ecomomics, will the audiance for the api change hav=
e a money benefit directly, or is this another case of misaligned work / be=
nefit ?

b4 and clat are already deployed at a meaningfu=
l scale on multiple continents enabling ipv6 only. The network operators ha=
ve done the work and realized the benefit of ipv6-only.=C2=A0

I dont want to waste ietf time on re-inventing the wheel and writie d=
ocs of an audience that wont read it. =C2=A0we know how to do ipv6-only acc=
ess networks in the real world at scale with the work / benefit aligned.=C2=
=A0

CB=C2=A0


--047d7bacb5985cca8605146f23b2--


From nobody Thu Apr 23 20:39: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 834EA1ACEFA for ; Thu, 23 Apr 2015 20:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.51
X-Spam-Level: 
X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 JzqB-UDG4vAs for ; Thu, 23 Apr 2015 20:39:05 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D0A1ACEE8 for ; Thu, 23 Apr 2015 20:39:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6919; q=dns/txt; s=iport; t=1429846743; x=1431056343; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tdSaJaDVEUJeqnjde5nhtw5WloTJ5d52up9B2IgJFmI=; b=Bq46JDg/Z29wbeKJqLDmFoWN3S9JgjfgDvVdHvIhU9MzelC1rTysuk+Z MOL4PvN5EJbYOSOUZTUVW8wGzEhtHYQ9FD04Sgc0wcdalgCtkslpQm2E4 wbOZQKtC9SeYJPrbNaY5iboJCv6+PO8jErzFy6D36QJt0qJQzcLlGHGRZ k=;
X-Files: signature.asc : 487
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B+BADtuTlV/5tdJa1bgkVHgS4FgxXDDwmHVQKBNTgUAQEBAQEBAYEKhCABAQEDASNWBQsCAQgOCicDAgIhERQRAgQOBQ4Nh3wDCQi3AY80DYU6AQEBAQEBAQEBAQEBAQEBAQEBAQEBFAMGizGCTYI3B4JoL4EWBZFKgXKBN4U6gVKBIoY1hyKDBINOI4FlU4E8b4FEgQABAQE
X-IronPort-AV: E=Sophos;i="5.11,636,1422921600";  d="asc'?scan'208,217";a="144095936"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 24 Apr 2015 03:39:02 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3O3d2np019816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Apr 2015 03:39:02 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.172]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 22:39:01 -0500
From: "Fred Baker (fred)" 
To: Ca By 
Thread-Topic: The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQfkA0XKmBO1AYnUSH7VdeVhz5vQ==
Date: Fri, 24 Apr 2015 03:39:01 +0000
Message-ID: 
References:   <20150320134204.32af9c67@echo.ms.redpill-linpro.com>  <550F1F1F.3060703@cernet.edu.cn>                   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.64.121]
Content-Type: multipart/signed; boundary="Apple-Mail=_AE85881A-EDCE-4FBE-AA67-4B8A8876BF6D"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 03:39:07 -0000

--Apple-Mail=_AE85881A-EDCE-4FBE-AA67-4B8A8876BF6D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D5FDC2A9-6240-4B97-908A-529EFE976637"


--Apple-Mail=_D5FDC2A9-6240-4B97-908A-529EFE976637
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Apr 23, 2015, at 7:27 PM, Ca By  wrote:
>=20
>=20
>=20
> On Thursday, April 23, 2015, Fred Baker (fred) > wrote:
>=20
>> On Apr 3, 2015, at 2:15 PM, James Woodyatt > wrote:
>>=20
>> I think the former entails the latter. I think we get away from =
running IPv4 by deliberately and carefully removing support for IPv4 =
from application developers and users in a way that continuously makes =
forward progress at a manageable and predictable expense. If we deploy =
CLAT everywhere, then we will be making IPv4 more difficult to displace =
by removing support for it in the network.
>=20
>=20
> I 75% agree. I think we move from IPv4 to ipv6 by making applications =
version agnostic (e.g., use getaddrinfo() rather than gethostbyname()), =
and getting networks to turn on IPv6 in the infrastructure. Given that, =
at someone economics kicks in. It=E2=80=99s cheaper to run one network =
than two.
>=20
>=20
> What is the estimated time to turn the ship via this method? Meaning, =
when will tangible results be delivered such that a network operator =
could deploy ipv6-only?  You mentioned ecomomics, will the audiance for =
the api change have a money benefit directly, or is this another case of =
misaligned work / benefit ?
>=20
> b4 and clat are already deployed at a meaningful scale on multiple =
continents enabling ipv6 only. The network operators have done the work =
and realized the benefit of ipv6-only.
>=20
> I dont want to waste ietf time on re-inventing the wheel and writie =
docs of an audience that wont read it.  we know how to do ipv6-only =
access networks in the real world at scale with the work / benefit =
aligned.
>=20
> CB

Well, I think your question is really for James. But I=E2=80=99m with =
you, as you=E2=80=99ll note from the discussion we had in IETF 92.

--Apple-Mail=_D5FDC2A9-6240-4B97-908A-529EFE976637
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Apr 23, 2015, at 7:27 PM, Ca By <cb.list6@gmail.com> =
wrote:



On Thursday, April 23, 2015, =
Fred Baker (fred) <fred@cisco.com> wrote:
On Apr 3, 2015, at 2:15 PM, James Woodyatt <jhw@nestlabs.com> wrote:

I think the former entails the latter. I =
think we get away from running IPv4 by deliberately and carefully =
removing support for IPv4 from application developers and users in a way =
that continuously makes forward progress at a manageable and predictable =
expense. If we deploy CLAT everywhere, then we will be making IPv4 more =
difficult to displace by removing support for it in the =
network.


I 75% agree. I think we =
move from IPv4 to ipv6 by making applications version agnostic (e.g., =
use getaddrinfo() rather than gethostbyname()), and getting networks to =
turn on IPv6 in the infrastructure. Given that, at someone economics =
kicks in. It=E2=80=99s cheaper to run one network than =
two.


What is the estimated =
time to turn the ship via this method? Meaning, when will tangible =
results be delivered such that a network operator could deploy =
ipv6-only?  You mentioned ecomomics, will the audiance for the api =
change have a money benefit directly, or is this another case of =
misaligned work / benefit ?

b4 =
and clat are already deployed at a meaningful scale on multiple =
continents enabling ipv6 only. The network operators have done the work =
and realized the benefit of ipv6-only. 

I dont want to waste ietf time on =
re-inventing the wheel and writie docs of an audience that wont read it. =
 we know how to do ipv6-only access networks in the real world at =
scale with the work / benefit aligned. 

CB 



Well, I think =
your question is really for James. But I=E2=80=99m with you, as you=E2=80=99=
ll note from the discussion we had in IETF 92.
=

--Apple-Mail=_D5FDC2A9-6240-4B97-908A-529EFE976637--

--Apple-Mail=_AE85881A-EDCE-4FBE-AA67-4B8A8876BF6D
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

iQEVAwUBVTm60p9ieig10VPpAQIZBwf/Q7dyU5g6LplzgBauEHNbWxzb16DPAOHq
DrnL5AkcYFDsGQKhFq7osC6A4oRSa0KLluprBrTI9+8FlTZaZa78BkQE/uRqYh/W
Ac12uppakQia+3owkOK/XDfTWMf7w0cq1qwd53Bj1nyig0nfqiC6JZ3iLOuiIZkJ
RHSJJ7jHz0qLuHHECHCqTtCnNSDt0nMLLeUKE0jm3fvP4F9utZEF7qctqh0AewQQ
gT2hKi6synoW+bHMqkMCI8iQNqACK0zH1JWJgsDpdxUS6OliImId7quLVOEFaBij
tyHUf2gFShVJpzburGGZOKhK718jd0ip6ZohAT2t899+l/XfDqENWQ==
=DlY3
-----END PGP SIGNATURE-----

--Apple-Mail=_AE85881A-EDCE-4FBE-AA67-4B8A8876BF6D--


From nobody Thu Apr 23 21:00:52 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 C75EF1B2BEB for ; Thu, 23 Apr 2015 21:00:51 -0700 (PDT)
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 wmVL2D5HJ9oa for ; Thu, 23 Apr 2015 21:00:50 -0700 (PDT)
Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 E7C691B2BED for ; Thu, 23 Apr 2015 21:00:22 -0700 (PDT)
Received: by obfe9 with SMTP id e9so29132641obf.1 for ; Thu, 23 Apr 2015 21:00:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TG+zWeLGUtS+s9X5it3pbqZTEpGyguc6FLJe3eN5grs=; b=O+nsGw4FVHBZWnhp5QZ3SO7R4CQEsOhdx7h0mp7EDKTbaXAjlYtgpmDHxlAKoxfdye ULnmtQ9i7EdS0Ngjhsyvk+fuKd53t9AsBPfDM3XZIXTPT+dCcV7JGO2k6/JQWw83m5wI Z9DMcPzEMbwz4kjyrSHrccalCQq4Zm7IfnJcxpBQX3/ol1P+8+wFIPdCuXtUQkdHjelk UEnzdtEWZYFfAJ8WvtJrgTsUI/7yrGWnWDoxmF1vdO2Ji4GHoTNlyTc/mn4RirB0PaIW pX8rsp7XLpUG4NFhwCBzK4lO4o81XOtnC1/BdpzQSOBz69khkOOb8Ab7CSloEWB1txwU 5bBQ==
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=TG+zWeLGUtS+s9X5it3pbqZTEpGyguc6FLJe3eN5grs=; b=cXrravvNI89rnhrL2qYqobdGzl5EBh8qXc5N4AjNha0GyEmIEiM+tT25yG+bau8byJ MdXRAHvWVvPi3n8WlRJ8hjHArrncfLbNnmQjdvwI+2dVvtKmvGWZj/0IzCCIOmgb/MPw tMY8Le8ecdk5lWdDekcKZx/vHUojAxzQyLiKb3ip9Xat9mg3ZBQEmrRaSXnW07vdDgkE XhbLChXISIkT5NMUFW8g1JhKQE2UcGRJCRJicPbPByfJcLMgbVO/qr2w0ZllA16itFmG sMR1bPnFi/6jf56+3F05x5el2AltOt8awHFgte1wXE/SsKqZRMny4pMK+NoiCdYNhDae 7J/A==
X-Gm-Message-State: ALoCoQkZur6CwllOfib6cdnGT3THqzTGn1WcTBoWPbh/XR3X6VOEfi71CXwlYtlhs1ZBsexJ806o
X-Received: by 10.60.220.137 with SMTP id pw9mr5514531oec.47.1429848022336; Thu, 23 Apr 2015 21:00:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.89.166 with HTTP; Thu, 23 Apr 2015 21:00:01 -0700 (PDT)
In-Reply-To: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com> 
From: Lorenzo Colitti 
Date: Fri, 24 Apr 2015 13:00:01 +0900
Message-ID: 
To: James Woodyatt 
Content-Type: multipart/alternative; boundary=001a11347f907468a00514706f88
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 04:00:52 -0000

--001a11347f907468a00514706f88
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 23, 2015 at 7:36 AM, James Woodyatt  wrote:

> In particular, I think it's critical to have a clear understanding of
> precisely what features of the PF_INET interfaces are expected to be
> handled by the CLAT function. If the IP_PKTINFO socket option, for example,
> is expected to be unsupported, then it's important to know that. What
> does the CLAT do with IPv4 link-local scope addresses? What about the
> SO_REUSEADDR option? A good place to start would probably be to go through
> the entire POSIX.1 standard, and for all the IPv4 networking interfaces,
> describe what is and isn't supported by the CLAT function recommended by
> IETF.
>

I don't think such a fine-toothed-comb endeavour makes sense. 464xlat is
just an unnumbered point-to-point link. That directly implies that the
answers to your questions are "there's no reason not to support IP_PKTINFO,
and no extra work required to do so", "link-local scope addresses are not
supported because it's an unnumbered point-to-point link", and
"SO_REUSEADDR means exactly what it means on any other IP address on the
system".

I suppose we can always write a document saying the above, plus
recommending that there be a different local clat IP address for every
interface on the system. Such a document wouldn't be very long, but I
suppose it might be helpful.

I don't think there is a need to go through POSIX.1. looking for corner
cases.

--001a11347f907468a00514706f88
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Apr 23, 2015 at 7:36 AM, James Woodyatt <jhw@nestlabs.com> wrote:
In particular, I think it's critical to have a c=
lear understanding of precisely what features of the PF_INET interfaces=C2=A0ar=
e expected to be handled by the CLAT function. If the IP_PKTINFO socket opt=
ion, for example, is expected to be unsupported, then it's important to=
 know that.=C2=A0What does the CLAT=
 do with IPv4 link-local scope addresses? What about the SO_REUSEADDR optio=
n? A good place to start would probably be to go through the entire POSIX.1=
 standard, and for all the IPv4 networking interfaces, describe what is and=
 isn't supported by the CLAT function recommended by IETF.
=


I don't think such a fine-toothe=
d-comb endeavour makes sense. 464xlat is just an unnumbered point-to-point =
link. That directly implies that the answers to your questions are "th=
ere's no reason not to support IP_PKTINFO, and no extra work required t=
o do so", "link-local scope addresses are not supported because i=
t's an unnumbered point-to-point link", and "SO_REUSEADDR mea=
ns exactly what it means on any other IP address on the system".
=


I suppose we can always write a document saying the abo=
ve, plus recommending that there be a different local clat IP address for e=
very interface on the system. Such a document wouldn't be very long, bu=
t I suppose it might be helpful.

I don't t=
hink there is a need to go through POSIX.1. looking for corner cases.
=



--001a11347f907468a00514706f88--


From nobody Fri Apr 24 04:47: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 0084A1A8F3F for ; Fri, 24 Apr 2015 04:47:19 -0700 (PDT)
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 4bvbcG_utEj2 for ; Fri, 24 Apr 2015 04:47:18 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C8F1A8F3C for ; Fri, 24 Apr 2015 04:47:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139; q=dns/txt; s=iport; t=1429876037; x=1431085637; h=date:from:message-id:to:subject:cc; bh=QyWndVAos8yp3N86s4CDy9TYuLA2Z49Um0Hh/0JNXAc=; b=esjUDZqTfctK5OtGTTPIuhaoAa7C0MXKdhXM1ZQ89CvcYYCg0UDS+3+E SmfsIRXu8Oj3u7qHx125wpMwtexuGuzv8DuYwqzWPGNRas4dbYyhjmTah Ct+x1nhi54mhS0ghupp+3D7AZBUvG6j+JnQZ0zkhMrF+uw/4wCjMJDlP6 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BZCwDMLDpV/5hdJa1bgwxSXbgfAY4kCYFRhXsJgT04FAEBAQEBAQGBCkEFg119PDSJCwENy3IBAQgCAR+LN4UEHYQXBYtUiXeHVjyDCZBkI4QUgxMBAQE
X-IronPort-AV: E=Sophos;i="5.11,639,1422921600"; d="scan'208";a="144191566"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 24 Apr 2015 11:47:03 +0000
Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3OBl20S018430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 11:47:03 GMT
Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t3OBl1lq007038; Fri, 24 Apr 2015 04:47:01 -0700
Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t3OBl1FV007037; Fri, 24 Apr 2015 04:47:01 -0700
Date: Fri, 24 Apr 2015 04:47:01 -0700
From: fred@cisco.com
Message-Id: <201504241147.t3OBl1FV007037@irp-lnx1.cisco.com>
To: v6ops@ietf.org
Archived-At: 
Cc: draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org
Subject: [v6ops] new draft: draft-ietf-v6ops-ipv6-ehs-in-real-world
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Apr 2015 11:47:19 -0000

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world. Please take a look at it and comment.


From nobody Fri Apr 24 06:33: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 8F6991A9145 for ; Fri, 24 Apr 2015 06:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 7Yh7B6KHe5jF for ; Fri, 24 Apr 2015 06:33:14 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D071D1B2FAC for ; Fri, 24 Apr 2015 06:33:14 -0700 (PDT)
Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) with Microsoft SMTP Server (TLS) id 15.1.136.25; Fri, 24 Apr 2015 13:33:14 +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.0136.026; Fri, 24 Apr 2015 13:33:14 +0000
From: "Metzler, Dan J" 
To: Ted Lemon , "George, Wes" 
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYouA3ye9AcRTck+xU68IbGwQo50k3BQAgAB1XgCAADeeAIADZz+AgAFS54CAAVsLAIAAFWiAgAAAioCAAA8DgIAAC2wAgABuQoCAAa/cAIAAFKSAgAD9fgCAAAeaAIAAW2CAgAwMloCAAANjAIAC0b8AgAHh/oCAAPtCAIAAyzkAgAXumQCAA55OgIAMjYoagADohQCAAAWfgIAALsWAgAAgvgCAAAlvAIAAASwAgALroeA=
Date: Fri, 24 Apr 2015 13:33:13 +0000
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>
In-Reply-To: <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: nominum.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [2620:0:e50:1001:d4b7:97ba:25dc:ef4d]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB585;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(377454003)(24454002)(40100003)(50986999)(74316001)(99286002)(75432002)(93886004)(76576001)(54356999)(77096005)(77156002)(88552001)(33656002)(87936001)(62966003)(2656002)(106116001)(19580395003)(122556002)(90282001)(19580405001)(46102003)(2950100001)(92566002)(15975445007)(102836002)(5001770100001)(86362001)(76176999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB585; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:CO2PR04MB585; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB585; 
x-forefront-prvs: 05568D1FF7
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uiowa.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2015 13:33:13.7066 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB585
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 13:33:17 -0000

See below

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon
> Sent: Wednesday, April 22, 2015 9:38 AM
> To: George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions =
--
> NAT64/DNS64 remains insufficient
>=20
> On Apr 22, 2015, at 10:33 AM, George, Wes 
> wrote:
> > WG] Should we be trying to raise visibility on this issue in other foru=
ms?
> > For instance, IETF has a formal liaison relationship with W3C. Perhaps
> > an effort there would be useful, even if it doesn't necessarily cover
> > non-web app developers?
>=20
> I am skeptical that the people who are using IPv4 literals are active in =
any
> standards community.   I suppose it's possible, and reaching out and gett=
ing
> e.g. W3C to make a strong statement about this would certainly be good in=
 the
> sense that it might shorten the long tail, but I don't think it's going t=
o fix the
> problem soon enough.   I really can't see any way to address this that do=
esn't
> look something like 464xlat or IPv4-as-a-service (e.g. softwire MAP/lw4ov=
er6).

[DJM]=20
I see one common theme in this discussion:  "IPv4 literals are harmful." =20
If we really want to write a document, that states that IPv4 literals must =
not be used, shouldn't that be the first step?  Recognize the harm, and mak=
e a strong statement that IPv4 literals should/must not be used.
Why dance around these issues?  Seems to me that this is step 1.  The solut=
ion is to start by making that strong statement.  If we have tangible infor=
mation about who has IPv4 literals, why not make that public?  Let people k=
now where the problems are.
If the IETF can't bring itself to do this, then there is no need for this d=
iscussion, because it isn't really a problem, and we can all just turn off =
IPv4 today, or embrace it.

Only after addressing the above, (accepting that it is a problem), is it ti=
me to look at what to do in the meantime as a work around. =20
Dual stack is a certainly solution if people aren't ready to move to IPv6-o=
nly.  It gets around the IPv4 literal problem by simply maintaining support=
 for IPv4 while it's needed.

So then what if you don't have the IPv4 address space, or you can't do dual=
 stack?  Well you have 4 options, depending on your situation:
1) Go buy more IPv4 address space.  Ok, maybe that's going to be costly, bu=
t I think we knew that was going to happen.  If you need it, then you need =
it.  (If you are one of those who suggest that IPv4 will always be there, t=
hen do this and embrace your future now.)

2) Use 464xlat or IPv4 as a service, and just realize that not everything h=
as support for that.  When customers call to complain, don't blame the vend=
or who won't support your technology of choice.  Place the blame on those u=
sing IPv4 literals, where it belongs, and point out that there is a documen=
t that states it is wrong to implement IPv4 literals; (because IETF took th=
e first step as mentioned above.)

3) Maybe not everything on your network really needs to talk IPv4.  Shift s=
ome of your network to IPv6 only, and move the addresses around, to buy tim=
e.  If IPv6-only customers call to complain, place the blame on those using=
 IPv4 literals, where it belongs, and point out that there is a document th=
at states it is wrong to implement IPv4 literals; (because IETF took the fi=
rst step as mentioned above.)

4) Ignore the issue, and treat it as insignificant.  When customers call to=
 complain, place the blame on those using IPv4 literals, where it belongs, =
and point out that there is a document that states it is wrong to implement=
 IPv4 literals; (because IETF took the first step as mentioned above.)


If however, a WG and the IETF cannot be bothered to make the statement that=
 IPv4 literals are bad, then it follows that IETF really would be saying th=
at IPv4 literals are not a problem.  It would suggest that IETF is not real=
ly committed to IPv6-only, and that the plan is to try to scale IPv4 to sui=
t the needs of tomorrow.  My personal opinion is, I think that would be irr=
esponsible, but I'm starting to wonder if that's really where things stand =
for some.

- Dan Metzler

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


From nobody Fri Apr 24 07:27:40 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 86D3E1A09CF for ; Fri, 24 Apr 2015 07:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 b6cZm0lbrjDE for ; Fri, 24 Apr 2015 07:27:34 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0DF1A0A6A for ; Fri, 24 Apr 2015 07:27:33 -0700 (PDT)
Received: from [85.158.136.3] by server-11.bemta-5.messagelabs.com id 6F/62-30672-4D25A355; Fri, 24 Apr 2015 14:27:32 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-8.tower-123.messagelabs.com!1429885651!46435985!1
X-Originating-IP: [149.254.241.76]
X-StarScan-Received: 
X-StarScan-Version: 6.13.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19901 invoked from network); 24 Apr 2015 14:27:31 -0000
Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-8.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  24 Apr 2015 14:27:31 -0000
Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Fri, 24 Apr 2015 15:27:25 +0100
Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 24 Apr 2015 15:27:31 +0100
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Fri, 24 Apr 2015 15:27:30 +0100
From: "Heatley, Nick" 
To: "Metzler, Dan J" , Ted Lemon , "George, Wes" 
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYtCVneMUqIFM3UWKOHw0TbKROp0lUOcAgAA3nwCAA2c/gIABUuaAgAFbCwCAABVpgIAAAIqAgAAPA4CAAAtsAIAAbkKAgAGv2wCAABSlgIAA/X4AgAAHmQCAAFthgIAL+9OAgAADYgCAAtG/AIAB4f6AgAD7QgCAAMs5AIAF7pkAgAOeT4CADJ5Bd4AA3PKggAAAeoCAADxNoIAAEzYAgAAJbwCAAAEtAIADEpSAgAAVCCA=
Date: Fri, 24 Apr 2015 14:27:30 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303E8F236@UK30S005EXS06.EEAD.EEINT.CO.UK>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 14:27:38 -0000

Dan, those options are costly, unsustainable in the long term, and drive =
customers away from the network.
It doesn't matter what helpdesk staff blame it on, what matters is that c=
all has cost time and money.


-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Metzler, Dan J
Sent: 24 April 2015 14:33
To: Ted Lemon; George, Wes
Cc: Bjoern A. Zeeb; IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions =
-- NAT64/DNS64 remains insufficient

See below

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon
> Sent: Wednesday, April 22, 2015 9:38 AM
> To: George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: Re: [v6ops] The need for local-ipv4 socket transition=20
> solutions --
> NAT64/DNS64 remains insufficient
>=20
> On Apr 22, 2015, at 10:33 AM, George, Wes 
> wrote:
> > WG] Should we be trying to raise visibility on this issue in other fo=
rums?
> > For instance, IETF has a formal liaison relationship with W3C.=20
> > Perhaps an effort there would be useful, even if it doesn't=20
> > necessarily cover non-web app developers?
>=20
> I am skeptical that the people who are using IPv4 literals are active i=
n any
> standards community.   I suppose it's possible, and reaching out and ge=
tting
> e.g. W3C to make a strong statement about this would certainly be good =

> in the sense that it might shorten the long tail, but I don't think it'=
s going to fix the
> problem soon enough.   I really can't see any way to address this that =
doesn't
> look something like 464xlat or IPv4-as-a-service (e.g. softwire MAP/lw4=
over6).

[DJM]
I see one common theme in this discussion:  "IPv4 literals are harmful." =
=20
If we really want to write a document, that states that IPv4 literals mus=
t not be used, shouldn't that be the first step?  Recognize the harm, and=
=20make a strong statement that IPv4 literals should/must not be used.
Why dance around these issues?  Seems to me that this is step 1.  The sol=
ution is to start by making that strong statement.  If we have tangible i=
nformation about who has IPv4 literals, why not make that public?  Let pe=
ople know where the problems are.
If the IETF can't bring itself to do this, then there is no need for this=
=20discussion, because it isn't really a problem, and we can all just tur=
n off IPv4 today, or embrace it.

Only after addressing the above, (accepting that it is a problem), is it =
time to look at what to do in the meantime as a work around. =20
Dual stack is a certainly solution if people aren't ready to move to IPv6=
-only.  It gets around the IPv4 literal problem by simply maintaining sup=
port for IPv4 while it's needed.

So then what if you don't have the IPv4 address space, or you can't do du=
al stack?  Well you have 4 options, depending on your situation:
1) Go buy more IPv4 address space.  Ok, maybe that's going to be costly, =
but I think we knew that was going to happen.  If you need it, then you n=
eed it.  (If you are one of those who suggest that IPv4 will always be th=
ere, then do this and embrace your future now.)

2) Use 464xlat or IPv4 as a service, and just realize that not everything=
=20has support for that.  When customers call to complain, don't blame th=
e vendor who won't support your technology of choice.  Place the blame on=
=20those using IPv4 literals, where it belongs, and point out that there =
is a document that states it is wrong to implement IPv4 literals; (becaus=
e IETF took the first step as mentioned above.)

3) Maybe not everything on your network really needs to talk IPv4.  Shift=
=20some of your network to IPv6 only, and move the addresses around, to b=
uy time.  If IPv6-only customers call to complain, place the blame on tho=
se using IPv4 literals, where it belongs, and point out that there is a d=
ocument that states it is wrong to implement IPv4 literals; (because IETF=
=20took the first step as mentioned above.)

4) Ignore the issue, and treat it as insignificant.  When customers call =
to complain, place the blame on those using IPv4 literals, where it belon=
gs, and point out that there is a document that states it is wrong to imp=
lement IPv4 literals; (because IETF took the first step as mentioned abov=
e.)


If however, a WG and the IETF cannot be bothered to make the statement th=
at IPv4 literals are bad, then it follows that IETF really would be sayin=
g that IPv4 literals are not a problem.  It would suggest that IETF is no=
t really committed to IPv6-only, and that the plan is to try to scale IPv=
4 to suit the needs of tomorrow.  My personal opinion is, I think that wo=
uld be irresponsible, but I'm starting to wonder if that's really where t=
hings stand for some.

- Dan Metzler

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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named p=
erson(s).  If you are not the intended recipient, notify the sender immed=
iately, delete this email from your system and do not disclose or use for=
=20any purpose. =20
=20
We may monitor all incoming and outgoing emails in line with current legi=
slation. We have taken steps to ensure that this email and attachments ar=
e free from any virus, but it remains your responsibility to ensure that =
viruses do not adversely affect you.=20

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


From nobody Fri Apr 24 07:38: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 C08D11A0378 for ; Fri, 24 Apr 2015 07:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level: 
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 XA5YD35CPdMj for ; Fri, 24 Apr 2015 07:38:39 -0700 (PDT)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 90A621A8763 for ; Fri, 24 Apr 2015 07:38:11 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,640,1422939600"; d="scan'208";a="242477630"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Apr 2015 10:23:35 -0400
Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 24 Apr 2015 10:38:08 -0400
From: "Howard, Lee" 
To: "Metzler, Dan J" , Ted Lemon , "George, Wes" 
Date: Fri, 24 Apr 2015 10:38:06 -0400
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AdB+nEgjDBnMfMVBQD+eUoXLcl64vQ==
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 14:38:42 -0000

On 4/24/15, 9:33 AM, "Metzler, Dan J"  wrote:

>See below
>
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon
>> Sent: Wednesday, April 22, 2015 9:38 AM
>> To: George, Wes
>> Cc: Bjoern A. Zeeb; IPv6 Ops WG
>> Subject: Re: [v6ops] The need for local-ipv4 socket transition
>>solutions --
>> NAT64/DNS64 remains insufficient
>>
>> On Apr 22, 2015, at 10:33 AM, George, Wes 
>> wrote:
>> > WG] Should we be trying to raise visibility on this issue in other
>>forums?
>> > For instance, IETF has a formal liaison relationship with W3C. Perhaps
>> > an effort there would be useful, even if it doesn't necessarily cover
>> > non-web app developers?
>>
>> I am skeptical that the people who are using IPv4 literals are active
>>in any
>> standards community.   I suppose it's possible, and reaching out and
>>getting
>> e.g. W3C to make a strong statement about this would certainly be good
>>in the
>> sense that it might shorten the long tail, but I don't think it's going
>>to fix the
>> problem soon enough.   I really can't see any way to address this that
>>doesn't
>> look something like 464xlat or IPv4-as-a-service (e.g. softwire
>>MAP/lw4over6).
>
>[DJM]
>I see one common theme in this discussion:  "IPv4 literals are harmful."

I think I read consensus on that statement.
I'm not sure there is consensus that the IETF is the right place to make
such a statement. There might be; I think we need a document to discuss to
see if there is consensus.
Somebody needs to write it for us to discuss it. Hint, hint.


>
>So then what if you don't have the IPv4 address space, or you can't do
>dual stack?  Well you have 4 options, depending on your situation:
>1) Go buy more IPv4 address space.  Ok, maybe that's going to be costly,
>but I think we knew that was going to happen.  If you need it, then you
>need it.  (If you are one of those who suggest that IPv4 will always be
>there, then do this and embrace your future now.)
>
>2) Use 464xlat or IPv4 as a service, and just realize that not everything
>has support for that.  When customers call to complain, don't blame the
>vendor who won't support your technology of choice.  Place the blame on
>those using IPv4 literals, where it belongs, and point out that there is
>a document that states it is wrong to implement IPv4 literals; (because
>IETF took the first step as mentioned above.)
>
>3) Maybe not everything on your network really needs to talk IPv4.  Shift
>some of your network to IPv6 only, and move the addresses around, to buy
>time.  If IPv6-only customers call to complain, place the blame on those
>using IPv4 literals, where it belongs, and point out that there is a
>document that states it is wrong to implement IPv4 literals; (because
>IETF took the first step as mentioned above.)
>
>4) Ignore the issue, and treat it as insignificant.  When customers call
>to complain, place the blame on those using IPv4 literals, where it
>belongs, and point out that there is a document that states it is wrong
>to implement IPv4 literals; (because IETF took the first step as
>mentioned above.)

I don't know whether all of this needs to be in the draft. The note that
one person's use of bad practices means others have to decide whether and
how to deal with it is worthwhile.

>
>
>If however, a WG and the IETF cannot be bothered to make the statement
>that IPv4 literals are bad, then it follows that IETF really would be
>saying that IPv4 literals are not a problem.  It would suggest that IETF
>is not really committed to IPv6-only, and that the plan is to try to
>scale IPv4 to suit the needs of tomorrow.  My personal opinion is, I
>think that would be irresponsible, but I'm starting to wonder if that's
>really where things stand for some.

That's back to the question of whether the IETF is the right place to say
something. It might be that we believe this is more appropriate somewhere
else.

Lee


This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.


From nobody Fri Apr 24 09:09: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 AC5771B30ED for ; Fri, 24 Apr 2015 09:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x3zAKvR2hCo for ; Fri, 24 Apr 2015 09:09:05 -0700 (PDT)
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140471B30E3 for ; Fri, 24 Apr 2015 09:08:51 -0700 (PDT)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 08EB625D3A42 for ; Fri, 24 Apr 2015 16:08:48 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2F151C76FE2 for ; Fri, 24 Apr 2015 16:08:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 4yQlwfjfbjUQ for ; Fri, 24 Apr 2015 16:08:46 +0000 (UTC)
Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A8B4DC76FDE for ; Fri, 24 Apr 2015 16:08:46 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Bjoern A. Zeeb" 
In-Reply-To: 
Date: Fri, 24 Apr 2015 16:08:44 +0000
Content-Transfer-Encoding: 7bit
Message-Id: <8A272B9D-BFF5-4F84-BC9C-52C49B8D231F@lists.zabbadoz.net>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303 E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>  
To: IPv6 Ops WG 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 16:09:06 -0000

> On 24 Apr 2015, at 14:38 , Howard, Lee  wrote:
> 
> 
> 
> On 4/24/15, 9:33 AM, "Metzler, Dan J"  wrote:
> 
>> [DJM]
>> I see one common theme in this discussion:  "IPv4 literals are harmful."
> 
> I think I read consensus on that statement.
> I'm not sure there is consensus that the IETF is the right place to make
> such a statement. There might be; I think we need a document to discuss to
> see if there is consensus.
> Somebody needs to write it for us to discuss it. Hint, hint.

Yeah, sunset4 got as far as that to my understanding:

http://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-07#section-7



From nobody Fri Apr 24 09:14: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 8AF4F1B30E8 for ; Fri, 24 Apr 2015 09:14:09 -0700 (PDT)
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 CaZc9IeWKtre for ; Fri, 24 Apr 2015 09:14:07 -0700 (PDT)
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 6B8BD1ACD7C for ; Fri, 24 Apr 2015 09:14:07 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 39FB960901 for ; Fri, 24 Apr 2015 18:14:05 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F41396029D for ; Fri, 24 Apr 2015 18:14:04 +0200 (CEST)
Received: (qmail 3396 invoked by uid 1007); 24 Apr 2015 18:14:04 +0200
Date: Fri, 24 Apr 2015 18:14:04 +0200
From: Gert Doering 
To: "Howard, Lee" 
Message-ID: <20150424161404.GZ54385@Space.Net>
References: <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.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: IPv6 Ops WG , "Bjoern A. Zeeb" 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 16:14:09 -0000

Hi,

On Fri, Apr 24, 2015 at 10:38:06AM -0400, Howard, Lee wrote:
> >[DJM]
> >I see one common theme in this discussion:  "IPv4 literals are harmful."
> 
> I think I read consensus on that statement.

+1  :)

> I'm not sure there is consensus that the IETF is the right place to make
> such a statement. There might be; I think we need a document to discuss to
> see if there is consensus.
> Somebody needs to write it for us to discuss it. Hint, hint.

I think the IETF is the right place to say so.  We document operational
problems, and we document how to move networks to dual-stack or IPv6-only,
and using IPv4 literal is a very clear operational problem.

As for the document: it could be a very short one ("do not use IPv4 literals
for services that are expected to work over the Internet, which contains
islands that use IPv4/IPv6 translation today, as it risks breaking your
service, or imposes operational costs elsewhere to work around it"), or a
longer one ("application programmers really should... IP agnostic API...
avoid this, avoid that... best practices like ").

I think both documents have merit, but the first one has a much higher chance
of actually getting anywhere in the near future.

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 Apr 24 11:00:37 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 A60D71B3857 for ; Fri, 24 Apr 2015 11:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.664
X-Spam-Level: *
X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 l0MPNM-ayBAg for ; Fri, 24 Apr 2015 11:00:35 -0700 (PDT)
Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id F05881B384B for ; Fri, 24 Apr 2015 11:00:34 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,641,1422939600"; d="scan'208";a="288304242"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Apr 2015 13:51:59 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 24 Apr 2015 14:00:33 -0400
From: "George, Wes" 
To: IPv6 Ops WG 
Date: Fri, 24 Apr 2015 14:00:37 -0400
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AdB+uI9/e9FBnZYsR6KxUZgmal57bg==
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>   <8A272B9D-BFF5-4F84-BC9C-52C49B8D231F@lists.zabbadoz.net>
In-Reply-To: <8A272B9D-BFF5-4F84-BC9C-52C49B8D231F@lists.zabbadoz.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 18:00:36 -0000

T24gNC8yNC8xNSwgMTI6MDggUE0sICJCam9lcm4gQS4gWmVlYiIgPGJ6ZWViLWxpc3RzQGxpc3Rz
LnphYmJhZG96Lm5ldD4NCndyb3RlOg0KDQoNCj4+Pkkgc2VlIG9uZSBjb21tb24gdGhlbWUgaW4g
dGhpcyBkaXNjdXNzaW9uOiAgIklQdjQgbGl0ZXJhbHMgYXJlIGhhcm1mdWwuIg0KPj4NCj4+DQo+
WWVhaCwgc3Vuc2V0NCBnb3QgYXMgZmFyIGFzIHRoYXQgdG8gbXkgdW5kZXJzdGFuZGluZzoNCj4N
Cj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXN1bnNldDQtZ2FwYW5hbHlz
aXMtMDcjc2VjdGlvbi03DQoNCldHXSBRdWVzdGlvbiBmb3IgdGhvc2UgZGlzY3Vzc2luZyB0aGlz
OiBkb2VzIHRoZXJlIG5lZWQgdG8gYmUgbW9yZSB0ZXh0DQp0aGVyZSB0byBjb3ZlciB0aGUgZGlz
Y3Vzc2lvbj8gU2VuZCBjb21tZW50cyB0byBzdW5zZXQ0QGlldGYub3JnIG9yIHRvIHRoZQ0KZHJh
ZnQgYXV0aG9ycy4NCg0KTW9yZSBnZW5lcmFsbHksICpJUCogQWRkcmVzcyBsaXRlcmFscyBhcmUg
aGFybWZ1bCwgYmVjYXVzZSB0aGV5IG1ha2UgYmFkDQphc3N1bXB0aW9ucyBhYm91dCB3aGF0IGFk
ZHJlc3MgZmFtaWx5IGlzIHN1cHBvcnRlZCBvbiB0aGVpciB1c2VycycNCm5ldHdvcmtzLiBJdCdz
IGp1c3QgdGhhdCB3ZSBkb24ndCBoYXZlIGEgcHJvYmxlbSB3aXRoIHBlb3BsZSBicmVha2luZw0K
SVB2NC1vbmx5IHVzZXJzIGJ5IHRyeWluZyB0byB1c2UgSVB2NiBhZGRyZXNzIGxpdGVyYWxzLiBQ
ZXJoYXBzIHRoYXQNCnNob3VsZCBiZSB0aGUgc3RhdGVtZW50IGluIGEgc3RhbmRhbG9uZSBkb2N1
bWVudD8NCg0KV2VzIEdlb3JnZQ0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4g
YWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBv
dmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRh
Y2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1h
dGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNv
cHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGlu
dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g
d2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp
ZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNz
ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxh
dGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz
IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l
ZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkg
b2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg==


From nobody Fri Apr 24 11:06: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 32FB71ACD6E for ; Fri, 24 Apr 2015 11:06:24 -0700 (PDT)
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 jXK-lui--XAG for ; Fri, 24 Apr 2015 11:06:22 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3851ACD45 for ; Fri, 24 Apr 2015 11:06:21 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3BBCD608E5 for ; Fri, 24 Apr 2015 20:06:20 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F3B9D60765 for ; Fri, 24 Apr 2015 20:06:19 +0200 (CEST)
Received: (qmail 25644 invoked by uid 1007); 24 Apr 2015 20:06:19 +0200
Date: Fri, 24 Apr 2015 20:06:19 +0200
From: Gert Doering 
To: "George, Wes" 
Message-ID: <20150424180619.GB54385@Space.Net>
References:  <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>   <8A272B9D-BFF5-4F84-BC9C-52C49B8D231F@lists.zabbadoz.net> 
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: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 18:06:24 -0000

Hi,

On Fri, Apr 24, 2015 at 02:00:37PM -0400, George, Wes wrote:
> More generally, *IP* Address literals are harmful, because they make bad
> assumptions about what address family is supported on their users'
> networks. It's just that we don't have a problem with people breaking
> IPv4-only users by trying to use IPv6 address literals. Perhaps that
> should be the statement in a standalone document?

True, but I would actually emphasize that IPv4 literals are a real problem
today, while nobody is daft enough to put IPv6 literals anywhere (in more
polite words).

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 Apr 24 11:21: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 2BA5F1ACDEA for ; Fri, 24 Apr 2015 11:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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] 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 hERmE2soQ00l for ; Fri, 24 Apr 2015 11:21:21 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 6E9BE1A87BD for ; Fri, 24 Apr 2015 11:21:21 -0700 (PDT)
Received: by widdi4 with SMTP id di4so31649859wid.0 for ; Fri, 24 Apr 2015 11:21:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ozYve75hvPCz8U0+QE83x5wxHvznICIlXQmqkUiZp7g=; b=VpS6VWs6hWYNKeSyDVoOHIHXNIeNTAu21mxSmcWcj8FNyZnsKgi7j3osXkQKLidhcv bj43mn134Q4eYvCn86pV9z6sL6Aqaq0Adrr0TMPkhD2bO08qLVkSck70h2z0tPxpCEfV J9RHHBzB2RrwgDV7vMhBZtw+fD2QvpFKeCcMg=
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=ozYve75hvPCz8U0+QE83x5wxHvznICIlXQmqkUiZp7g=; b=a7OjiO5K4e/3M4Hms4ZBkjoPhKo9NpXUesiy1XbsRec46ZXnaOnXxabSOvFS/uykFN b1B8HDJ2GVwxUraMY6xseyA6JS/1XbomHMvqLkIT+ZYj39GTf39tp5nUZw/OCKXlZVxj B6j8ZAG563b37hvoglq+PPLxs3qs1e9vXeUqajlLRQ80faZ0v+p/j3DWQ2txNYThcYze 0kaZdHbx3xhCT/xSirpvXxb9Itc5Tojg+Ub9HYY/yUuACD99tkGHLvvgQzDMIENaMKsf NyXBvTqVt0PFBhY62sw/HHDvXIJD7Kjsnyuriz7+0+S3bAO2kyZzj5jM97XqFvaNx7oo 1i2Q==
X-Gm-Message-State: ALoCoQngYRxGcUd3Wn4hg3oRtLIQwCkgmHhyefCYz3i6reWopj/3ZdBE+0De1MCj8LlzJ7ayp7OO
MIME-Version: 1.0
X-Received: by 10.194.71.208 with SMTP id x16mr17411593wju.129.1429899680191;  Fri, 24 Apr 2015 11:21:20 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Fri, 24 Apr 2015 11:21:20 -0700 (PDT)
In-Reply-To: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>  
Date: Fri, 24 Apr 2015 11:21:20 -0700
Message-ID: 
From: James Woodyatt 
To: IPv6 Ops WG 
Content-Type: multipart/alternative; boundary=047d7bfcead080aafe05147c7699
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Apr 2015 18:21:23 -0000

--047d7bfcead080aafe05147c7699
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Lorenzo=E2=80=94

Let me put it this way. Until someone [you?] writes this draft and gets it
into the pipeline at 6MAN, this group won't have any real idea of precisely
what is the CLAT that it might consider recommending be implemented in All
The IPv6 Hosts. Maybe you don't want to go through POSIX.1 looking for all
the corner cases when you're writing the draft, but I would recommend you
do that anyway. Someone will, and you can either have the answers ready at
the start, or you can have an endless discussion about the unanswered
questions. I'm sure I can think of lots and lots and lots of questions that
should be easy for someone who has implemented a CLAT to answer.


On Thu, Apr 23, 2015 at 9:00 PM, Lorenzo Colitti  wrote=
:

> On Thu, Apr 23, 2015 at 7:36 AM, James Woodyatt  wrote:
>
>> In particular, I think it's critical to have a clear understanding of
>> precisely what features of the PF_INET interfaces are expected to be
>> handled by the CLAT function. If the IP_PKTINFO socket option, for examp=
le,
>> is expected to be unsupported, then it's important to know that. What
>> does the CLAT do with IPv4 link-local scope addresses? What about the
>> SO_REUSEADDR option? A good place to start would probably be to go throu=
gh
>> the entire POSIX.1 standard, and for all the IPv4 networking interfaces,
>> describe what is and isn't supported by the CLAT function recommended by
>> IETF.
>>
>
> I don't think such a fine-toothed-comb endeavour makes sense. 464xlat is
> just an unnumbered point-to-point link. That directly implies that the
> answers to your questions are "there's no reason not to support IP_PKTINF=
O,
> and no extra work required to do so", "link-local scope addresses are not
> supported because it's an unnumbered point-to-point link", and
> "SO_REUSEADDR means exactly what it means on any other IP address on the
> system".
>
> I suppose we can always write a document saying the above, plus
> recommending that there be a different local clat IP address for every
> interface on the system. Such a document wouldn't be very long, but I
> suppose it might be helpful.
>
> I don't think there is a need to go through POSIX.1. looking for corner
> cases.
>



--=20
james woodyatt 
Nest Labs, Communications Engineering

--047d7bfcead080aafe05147c7699
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Lorenzo=E2=80=94

Let me put it this way=
. Until someone [you?] writes this draft and gets it into the pipeline at 6=
MAN, this group won't have any real idea of precisely what is the CLAT =
that it might consider recommending be implemented in All The IPv6 Hosts. M=
aybe you don't want to go through POSIX.1 looking for all the corner ca=
ses when you're writing the draft, but I would recommend you do that an=
yway. Someone will, and you can either have the answers ready at the start,=
 or you can have an endless discussion about the unanswered questions. I=
9;m sure I can think of lots and lots and lots of questions that should be =
easy for someone who has implemented a CLAT to answer.

=


On Thu, Apr=
 23, 2015 at 9:00 PM, Lorenzo Colitti <lorenzo@google.com> =
wrote:
On Thu, Apr 23, 2015 at 7:36 AM, James=
 Woodyatt <jhw@nestlabs.com> wrote:
In particula=
r, I think it's critical to have a clear understanding of precisely wha=
t features of the PF_INET interfaces<=
span style=3D"color:rgb(0,0,0)">=C2=A0are expected to be handled by the CLA=
T function. If the IP_PKTINFO socket option, for example, is expected to be=
 unsupported, then it's important to know that.=C2=A0What does the CLAT do with IPv4 link-local scope addr=
esses? What about the SO_REUSEADDR option? A good place to start would prob=
ably be to go through the entire POSIX.1 standard, and for all the IPv4 net=
working interfaces, describe what is and isn't supported by the CLAT fu=
nction recommended by IETF.

<=
div>I don't think such a fine-toothed-comb endeavour makes sense. 464xl=
at is just an unnumbered point-to-point link. That directly implies that th=
e answers to your questions are "there's no reason not to support =
IP_PKTINFO, and no extra work required to do so", "link-local sco=
pe addresses are not supported because it's an unnumbered point-to-poin=
t link", and "SO_REUSEADDR means exactly what it means on any oth=
er IP address on the system".

I suppose we ca=
n always write a document saying the above, plus recommending that there be=
 a different local clat IP address for every interface on the system. Such =
a document wouldn't be very long, but I suppose it might be helpful.

I don't think there is a need to go through =
POSIX.1. looking for corner cases.




-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs,=
 Communications Engineering



--047d7bfcead080aafe05147c7699--


From nobody Sat Apr 25 12:43: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 5C2ED1ACD74 for ; Sat, 25 Apr 2015 12:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5Mwe9YTiZfAt for ; Sat, 25 Apr 2015 12:43:27 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858471ACD71 for ; Sat, 25 Apr 2015 12:43:26 -0700 (PDT)
Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) with Microsoft SMTP Server (TLS) id 15.1.136.25; Sat, 25 Apr 2015 19:43:23 +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.0136.026; Sat, 25 Apr 2015 19:43:23 +0000
From: "Metzler, Dan J" 
To: "Heatley, Nick" , Ted Lemon , "George, Wes" 
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYouA3ye9AcRTck+xU68IbGwQo50k3BQAgAB1XgCAADeeAIADZz+AgAFS54CAAVsLAIAAFWiAgAAAioCAAA8DgIAAC2wAgABuQoCAAa/cAIAAFKSAgAD9fgCAAAeaAIAAW2CAgAwMloCAAANjAIAC0b8AgAHh/oCAAPtCAIAAyzkAgAXumQCAA55OgIAMjYoagADohQCAAAWfgIAALsWAgAAgvgCAAAlvAIAAASwAgALroeCAADYfAIAAD0PA
Date: Sat, 25 Apr 2015 19:43:23 +0000
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>  <6536E263028723489CCD5B6821D4B21303E8F236@UK30S005EXS06.EEAD.EEINT.CO.UK>
In-Reply-To: <6536E263028723489CCD5B6821D4B21303E8F236@UK30S005EXS06.EEAD.EEINT.CO.UK>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ee.co.uk; dkim=none (message not signed) header.d=none;
x-originating-ip: [67.55.230.66]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB585;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(38564003)(24454002)(51444003)(2950100001)(46102003)(5001770100001)(92566002)(89122001)(33656002)(2656002)(62966003)(19580405001)(19580395003)(102836002)(106116001)(122556002)(2900100001)(86362001)(5890100001)(66066001)(76176999)(99286002)(15975445007)(74316001)(88552001)(87936001)(40100003)(50986999)(93886004)(566174002)(76576001)(54356999)(77156002)(77096005)(75432002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB585; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:CO2PR04MB585; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB585; 
x-forefront-prvs: 0557CBAD84
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uiowa.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2015 19:43:23.1922 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB585
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Apr 2015 19:43:29 -0000

Nick, see responses inline.

> -----Original Message-----
> From: Heatley, Nick [mailto:nick.heatley@ee.co.uk]
> Sent: Friday, April 24, 2015 9:28 AM
> To: Metzler, Dan J; Ted Lemon; George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: RE: [v6ops] The need for local-ipv4 socket transition solutions =
--
> NAT64/DNS64 remains insufficient
>=20
> Dan, those options are costly, unsustainable in the long term, and drive
> customers away from the network.
[DJM]=20
Can you be more specific?  Which options are costly, and unsustainable?=20
Given that I think I stated every possible option, I recognize that options=
 can be costly, some more than others.  Never-the-less, those are the optio=
ns available to us, so we are all going to pick one or more of them regardl=
ess, right?


> It doesn't matter what helpdesk staff blame it on, what matters is that c=
all has
> cost time and money.
[DJM]=20
I'm more focused on "cause" than on "blame", but not only does it matter, i=
t is critical.  It determines where, and whether, efforts will be focused o=
n actually solving the problem or not.  What matters most is the willingnes=
s to accept and identify the "cause" of the problem.  If there is a refusal=
 to address the cause, then the problem will not get fixed, and will simply=
 become more costly on a broader and broader scale, as everyone else is for=
ced to absorb the cost of workarounds or inaction. =20

That call is going to come into the helpdesk regardless.  Whether that is t=
he last call, or the start of many more, depends entirely on what the respo=
nse is, and whether it includes actions that address the cause of the issue=
 or not.

>=20
>=20
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Metzler, Dan J
> Sent: 24 April 2015 14:33
> To: Ted Lemon; George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions =
--
> NAT64/DNS64 remains insufficient
>=20
> See below
>=20
> > -----Original Message-----
> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon
> > Sent: Wednesday, April 22, 2015 9:38 AM
> > To: George, Wes
> > Cc: Bjoern A. Zeeb; IPv6 Ops WG
> > Subject: Re: [v6ops] The need for local-ipv4 socket transition
> > solutions --
> > NAT64/DNS64 remains insufficient
> >
> > On Apr 22, 2015, at 10:33 AM, George, Wes 
> > wrote:
> > > WG] Should we be trying to raise visibility on this issue in other fo=
rums?
> > > For instance, IETF has a formal liaison relationship with W3C.
> > > Perhaps an effort there would be useful, even if it doesn't
> > > necessarily cover non-web app developers?
> >
> > I am skeptical that the people who are using IPv4 literals are active i=
n any
> > standards community.   I suppose it's possible, and reaching out and ge=
tting
> > e.g. W3C to make a strong statement about this would certainly be good
> > in the sense that it might shorten the long tail, but I don't think it'=
s going to
> fix the
> > problem soon enough.   I really can't see any way to address this that =
doesn't
> > look something like 464xlat or IPv4-as-a-service (e.g. softwire
> MAP/lw4over6).
>=20
> [DJM]
> I see one common theme in this discussion:  "IPv4 literals are harmful."
> If we really want to write a document, that states that IPv4 literals mus=
t not be
> used, shouldn't that be the first step?  Recognize the harm, and make a s=
trong
> statement that IPv4 literals should/must not be used.
> Why dance around these issues?  Seems to me that this is step 1.  The sol=
ution
> is to start by making that strong statement.  If we have tangible informa=
tion
> about who has IPv4 literals, why not make that public?  Let people know
> where the problems are.
> If the IETF can't bring itself to do this, then there is no need for this=
 discussion,
> because it isn't really a problem, and we can all just turn off IPv4 toda=
y, or
> embrace it.
>=20
> Only after addressing the above, (accepting that it is a problem), is it =
time to
> look at what to do in the meantime as a work around.
> Dual stack is a certainly solution if people aren't ready to move to IPv6=
-only.  It
> gets around the IPv4 literal problem by simply maintaining support for IP=
v4
> while it's needed.
>=20
> So then what if you don't have the IPv4 address space, or you can't do du=
al
> stack?  Well you have 4 options, depending on your situation:
> 1) Go buy more IPv4 address space.  Ok, maybe that's going to be costly, =
but I
> think we knew that was going to happen.  If you need it, then you need it=
.  (If
> you are one of those who suggest that IPv4 will always be there, then do =
this
> and embrace your future now.)
>=20
> 2) Use 464xlat or IPv4 as a service, and just realize that not everything=
 has
> support for that.  When customers call to complain, don't blame the vendo=
r
> who won't support your technology of choice.  Place the blame on those us=
ing
> IPv4 literals, where it belongs, and point out that there is a document t=
hat
> states it is wrong to implement IPv4 literals; (because IETF took the fir=
st step as
> mentioned above.)
>=20
> 3) Maybe not everything on your network really needs to talk IPv4.  Shift=
 some
> of your network to IPv6 only, and move the addresses around, to buy time.=
  If
> IPv6-only customers call to complain, place the blame on those using IPv4
> literals, where it belongs, and point out that there is a document that s=
tates it
> is wrong to implement IPv4 literals; (because IETF took the first step as
> mentioned above.)
>=20
> 4) Ignore the issue, and treat it as insignificant.  When customers call =
to
> complain, place the blame on those using IPv4 literals, where it belongs,=
 and
> point out that there is a document that states it is wrong to implement I=
Pv4
> literals; (because IETF took the first step as mentioned above.)
>=20
>=20
> If however, a WG and the IETF cannot be bothered to make the statement th=
at
> IPv4 literals are bad, then it follows that IETF really would be saying t=
hat IPv4
> literals are not a problem.  It would suggest that IETF is not really com=
mitted to
> IPv6-only, and that the plan is to try to scale IPv4 to suit the needs of
> tomorrow.  My personal opinion is, I think that would be irresponsible, b=
ut I'm
> starting to wonder if that's really where things stand for some.
>=20
> - Dan Metzler
>=20
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> NOTICE AND DISCLAIMER
> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or us=
e for
> any purpose.
>=20
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachment=
s are
> free from any virus, but it remains your responsibility to ensure that vi=
ruses do
> not adversely affect you.
>=20
> EE Limited
> Registered in England and Wales
> Company Registered Number: 02382161
> Registered Office Address: Trident Place, Mosquito Way, Hatfield,
> Hertfordshire, AL10 9BW.


From nobody Sun Apr 26 18:37: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 672BE1B2D22 for ; Sun, 26 Apr 2015 18:37:55 -0700 (PDT)
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 86l1uKgRLqGl for ; Sun, 26 Apr 2015 18:37:54 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 3AC7D1B2D1C for ; Sun, 26 Apr 2015 18:37:54 -0700 (PDT)
Received: by igbyr2 with SMTP id yr2so51605227igb.0 for ; Sun, 26 Apr 2015 18:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+qD9RFZmfKWKGbhhuP/LzRwirVrmaHx/LjGXjCI3nK0=; b=bY+MR1JTDMUqPnvshcmfkgHn4exjvjhxe1xpCQSjLHRiI1IhipuYtvVQi+CGNzIxV7 ZrayCI/TC19DtgQwwTtIVNmZgGzLCfMOQeUE6ksipSlGELFbfFssO/8tgE3FE75Y4Ay2 DdidpNuiPi0s8r+378RtN2TrpwIi4aq+krAQDxxBcKjxvR8uK2lh+nZqBcbZNF+0qoGR MRehQYpGXms1ci5KmTVeTvGLuyXfELiFCEPnaa+2jEFk24QGIgPj3cInnY2Zo2VsTtpI ljbT4cz728z1grRrBRKlzrgUSoSdbPnIBo+Z5xFkE+0qqlgNlkaB77Ggq3YjfxwvfkzV DKCg==
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=+qD9RFZmfKWKGbhhuP/LzRwirVrmaHx/LjGXjCI3nK0=; b=X+SUe4t9S8CpXBcEeCOHmuTaLb33PE3Oa467jIGA3FvMr0NF69x9vbhCJIfeornuFz 2jQP9k5dj9nGayxoSZd2SQ/S1U3MjHiUsN0kKqf2pMLEO2ahPsjPXse/I+tiCD5Yjxz5 Xh7anj+27j/2kAjW73fDwqfIDdE0mmLHH5pLibrTaNL0ZivlAF+JtrKvLLvqRpBTqVmy b1m1s/QQPGNI/Yf6MDCpLT7lIIAD6x90dunOXL/gDWjxNWYYl6YTTGvPdec1vCCQmmp/ qGUwmo4hEKal1wzorq7bBDkMJvry7KkimPaUN4GbmI9pzAZhfI22Uv6uTFynqyPVZvDC zh1g==
X-Gm-Message-State: ALoCoQnBmVX7CbmaAqOXGdTIrxpM9QPX7DrxA3hMO+I8gfkJzgxeQChxAEA/XNakR3tJaRyAkOOR
X-Received: by 10.50.137.97 with SMTP id qh1mr10521344igb.39.1430098673597; Sun, 26 Apr 2015 18:37:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.73.2 with HTTP; Sun, 26 Apr 2015 18:37:33 -0700 (PDT)
In-Reply-To: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>   
From: Lorenzo Colitti 
Date: Mon, 27 Apr 2015 10:37:33 +0900
Message-ID: 
To: James Woodyatt 
Content-Type: multipart/alternative; boundary=001a11c3f1f46f20860514aacbaa
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Apr 2015 01:37:55 -0000

--001a11c3f1f46f20860514aacbaa
Content-Type: text/plain; charset=UTF-8

On Sat, Apr 25, 2015 at 3:21 AM, James Woodyatt  wrote:

> Let me put it this way. Until someone [you?] writes this draft and gets it
> into the pipeline at 6MAN, this group won't have any real idea of precisely
> what is the CLAT that it might consider recommending be implemented in All
> The IPv6 Hosts. Maybe you don't want to go through POSIX.1 looking for all
> the corner cases when you're writing the draft, but I would recommend you
> do that anyway. Someone will, and you can either have the answers ready at
> the start, or you can have an endless discussion about the unanswered
> questions. I'm sure I can think of lots and lots and lots of questions that
> should be easy for someone who has implemented a CLAT to answer.
>

A statement that it is necessary to go through all of POSIX.1 looking for
corner cases when defining an IPv6 compatibility method is so surprising to
me that I'm trying hard not to see it as a tactic to stall this
conversation. :-)

So, assuming it isn't... what sort of questions do you see around 464xlat
that cannot be immediately answered by just saying that "464xlat is an
unnumbered IPv4-only point-to-point link"?

--001a11c3f1f46f20860514aacbaa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
at, Apr 25, 2015 at 3:21 AM, James Woodyatt <jhw@nestlabs.com> wrote:
Let me p=
ut it this way. Until someone [you?] writes this draft and gets it into the=
 pipeline at 6MAN, this group won't have any real idea of precisely wha=
t is the CLAT that it might consider recommending be implemented in All The=
 IPv6 Hosts. Maybe you don't want to go through POSIX.1 looking for all=
 the corner cases when you're writing the draft, but I would recommend =
you do that anyway. Someone will, and you can either have the answers ready=
 at the start, or you can have an endless discussion about the unanswered q=
uestions. I'm sure I can think of lots and lots and lots of questions t=
hat should be easy for someone who has implemented a CLAT to answer.
<=
/div>

A statement that it is necessary to g=
o through all of POSIX.1 looking for corner cases when defining an IPv6 com=
patibility method is so surprising to me that I'm trying hard not to se=
e it as a tactic to stall this conversation. :-)

S=
o, assuming it isn't... what sort of questions do you see around 464xla=
t that cannot be immediately answered by just saying that "464xlat is =
an unnumbered IPv4-only point-to-point link"?


--001a11c3f1f46f20860514aacbaa--


From nobody Mon Apr 27 02:09: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 254631B2F5B for ; Mon, 27 Apr 2015 02:09:18 -0700 (PDT)
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 Da15JLnEunJq for ; Mon, 27 Apr 2015 02:09:16 -0700 (PDT)
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 53D5E1B2F56 for ; Mon, 27 Apr 2015 02:09:16 -0700 (PDT)
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 t3R9998l025228 for ; Mon, 27 Apr 2015 11:09:14 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4B36320379B for ; Mon, 27 Apr 2015 11:10:46 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 42AA420379A for ; Mon, 27 Apr 2015 11:10:46 +0200 (CEST)
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 t3R99DXe007859 for ; Mon, 27 Apr 2015 11:09:14 +0200
Message-ID: <553DFCB9.5090103@gmail.com>
Date: Mon, 27 Apr 2015 11:09:13 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: v6ops@ietf.org
References:   <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>    
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Apr 2015 09:09:18 -0000

Le 27/04/2015 03:37, Lorenzo Colitti a écrit :
> On Sat, Apr 25, 2015 at 3:21 AM, James Woodyatt  > wrote:
>
>     Let me put it this way. Until someone [you?] writes this draft and
>     gets it into the pipeline at 6MAN, this group won't have any real
>     idea of precisely what is the CLAT that it might consider
>     recommending be implemented in All The IPv6 Hosts. Maybe you don't
>     want to go through POSIX.1 looking for all the corner cases when
>     you're writing the draft, but I would recommend you do that anyway.
>     Someone will, and you can either have the answers ready at the
>     start, or you can have an endless discussion about the unanswered
>     questions. I'm sure I can think of lots and lots and lots of
>     questions that should be easy for someone who has implemented a CLAT
>     to answer.
>
>
> A statement that it is necessary to go through all of POSIX.1 looking
> for corner cases when defining an IPv6 compatibility method is so
> surprising to me that I'm trying hard not to see it as a tactic to stall
> this conversation. :-)
>
> So, assuming it isn't... what sort of questions do you see around
> 464xlat that cannot be immediately answered by just saying that "464xlat
> is an unnumbered IPv4-only point-to-point link"?

IPv4-only or IPv6-only? (I may have missed something).

Alex

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



From nobody Mon Apr 27 02:18: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 0FBBA1B2F6E for ; Mon, 27 Apr 2015 02:18:22 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UEMBFj1rvxoH for ; Mon, 27 Apr 2015 02:18:18 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D921B2F5C for ; Mon, 27 Apr 2015 02:18:17 -0700 (PDT)
Received: from [85.158.136.35] by server-16.bemta-5.messagelabs.com id 78/66-25453-8DEFD355; Mon, 27 Apr 2015 09:18:16 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-14.tower-125.messagelabs.com!1430126295!37630343!1
X-Originating-IP: [149.254.241.76]
X-StarScan-Received: 
X-StarScan-Version: 6.13.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2325 invoked from network); 27 Apr 2015 09:18:15 -0000
Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-14.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  27 Apr 2015 09:18:15 -0000
Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Mon, 27 Apr 2015 10:18:13 +0100
Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Mon, 27 Apr 2015 10:18:14 +0100
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0195.001; Mon, 27 Apr 2015 10:18:14 +0100
From: "Heatley, Nick" 
To: "Metzler, Dan J" , Ted Lemon , "George, Wes" 
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYtCVneMUqIFM3UWKOHw0TbKROp0lUOcAgAA3nwCAA2c/gIABUuaAgAFbCwCAABVpgIAAAIqAgAAPA4CAAAtsAIAAbkKAgAGv2wCAABSlgIAA/X4AgAAHmQCAAFthgIAL+9OAgAADYgCAAtG/AIAB4f6AgAD7QgCAAMs5AIAF7pkAgAOeT4CADJ5Bd4AA3PKggAAAeoCAADxNoIAAEzYAgAAJbwCAAAEtAIADEpSAgAAVCCCAAeS6gIABsX1Q
Date: Mon, 27 Apr 2015 09:18:14 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303E90298@UK30S005EXS06.EEAD.EEINT.CO.UK>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>  <64D1E18A-036D-426C-A4A9-8202BE66F403@nominum.com>  <6536E263028723489CCD5B6821D4B21303E8F236@UK30S005EXS06.EEAD.EEINT.CO.UK> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Bjoern A. Zeeb" , IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Apr 2015 09:18:22 -0000

In short I am reacting to the premise in option 3 & 4 that things are all=
owed to break for customers. I believe network operators will simply not =
move to the future mode of operation.
I believe the way forward lies somewhere in your option 2, but I question=
=20the assumptions, as your options maintain status quo without consideri=
ng changing the game in our favour.
I certainly don't expect support in every OS (let's call it the the Win95=
=20situation - old OS wither and die, no attempt of retrospective support=
) but I think this community needs a view on the critical success factors=
=20(breadth of support for the future mode of operation in new and emergi=
ng environments), which I think this email thread was about. I think Came=
ron called it a "unified front".

To give a longer answer:
I think Ted is right when he says he is sceptical that the purveyors of I=
P literals are active in any standards community.
Any message given out on "literals as harmful" to these intended recipien=
ts, how is this message any more relevant than the IPv6 message in genera=
l?
I see no more reason to heed the message of "ready content for v6" as for=
=20"purge your app/content of literals".
(For all intents and purposes, readying content for v6 (i.e. dualstacking=
=20content) appears to me to fix the main issue so perhaps there is no ne=
ed to change the message at all
So it is just detail - "ready content for v6, by the way making content p=
rotocol agnostic is the way to go").
Now given the state of content and v6 readiness in general, I don't see w=
e will see any more joy and any faster progress on driving out literals. =
Eradicating literals will be on the same timelines as readying content/ap=
ps for v6. I we already know the chicken/egg situation there.

>From what I have seen of IP literals they are not insignificant. Even if =
well-known apps were healed, and well known hosting sites policed, there =
still appears a long tail of unquantified content.
As an operator I cannot make a value judgement on the quality of this lon=
g tail, and it appears significant.
So I question the premise of option 4. I cannot see an operator moving to=
=20this future mode of operation and allowing the literal problems to occ=
ur. Any customer impacted will see the network as deficient, not the OS, =
not the content. This is not in the interests of the network operator and=
=20if put into practice will drive customers away. It cannot see it happe=
n for paying customer networks.
Back to chicken/egg problem.

While option 1 exists as tactical, I don't think we need to discuss this =
further here.
Within options 2 I think a way forward may exist.
We need a gamechanger to kickstart this move to the future mode of operat=
ion (the final mode of operation) - my personal opinion is that the gamec=
hanger is translation residing in the OS as per 464xlat/MAP-T, and I am e=
ncouraged by the other discussions on this thread. I'd like to think ther=
e is a BCP in the making here.

To those who think not eradicating literals means we never move to the fu=
ture mode of operation, I think we are already in that hole - we are alre=
ady in held in stable equilibrium of "perpetual dualstack". If I was buil=
ding the next wave of Wifi networks in the next few years I would wish to=
=20go IPv6 only because it is simple and cheap. But I'd be unable to do t=
his with the current mode of operation. This is wrong and we need to aim =
to solve this!=20
(However if I was google, and was rolling out the next wave of wifi netwo=
rks, I would definitely go IPv6-only though (probably omit DNS64 as well)=
, safe in the knowledge that my biggest rivals devices would be stuffed o=
n IPv6-only networks! Imagine a free wifi network that ithingies don't fu=
lly work on for until....)

I think the IETF has proved that these gamechangers can be enabled. I rem=
ember in the last decade for a previous telco I ran through a matrix of I=
P address exhaustion options (including all those called "anti-social by =
CB). I remember DS-lite and something called P-NAT being in that matrix, =
and these were *almost* discounted at the time because of the lack of sup=
port in equipment. Now we have major install bases of DS-lite and whole m=
obile network architectures around 464xlat. So the only real barrier to a=
ny gamechanger is time :-)
Regards,
Nick



-----Original Message-----
From: Metzler, Dan J [mailto:dan-metzler@uiowa.edu]=20
Sent: 25 April 2015 20:43
To: Heatley, Nick; Ted Lemon; George, Wes
Cc: Bjoern A. Zeeb; IPv6 Ops WG
Subject: RE: [v6ops] The need for local-ipv4 socket transition solutions =
-- NAT64/DNS64 remains insufficient

Nick, see responses inline.

> -----Original Message-----
> From: Heatley, Nick [mailto:nick.heatley@ee.co.uk]
> Sent: Friday, April 24, 2015 9:28 AM
> To: Metzler, Dan J; Ted Lemon; George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: RE: [v6ops] The need for local-ipv4 socket transition=20
> solutions --
> NAT64/DNS64 remains insufficient
>=20
> Dan, those options are costly, unsustainable in the long term, and=20
> drive customers away from the network.
[DJM]
Can you be more specific?  Which options are costly, and unsustainable?=20
Given that I think I stated every possible option, I recognize that optio=
ns can be costly, some more than others.  Never-the-less, those are the o=
ptions available to us, so we are all going to pick one or more of them r=
egardless, right?


> It doesn't matter what helpdesk staff blame it on, what matters is that=
=20call has
> cost time and money.
[DJM]=20
I'm more focused on "cause" than on "blame", but not only does it matter,=
=20it is critical.  It determines where, and whether, efforts will be foc=
used on actually solving the problem or not.  What matters most is the wi=
llingness to accept and identify the "cause" of the problem.  If there is=
=20a refusal to address the cause, then the problem will not get fixed, a=
nd will simply become more costly on a broader and broader scale, as ever=
yone else is forced to absorb the cost of workarounds or inaction. =20

That call is going to come into the helpdesk regardless.  Whether that is=
=20the last call, or the start of many more, depends entirely on what the=
=20response is, and whether it includes actions that address the cause of=
=20the issue or not.

>=20
>=20
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Metzler, Dan J=

> Sent: 24 April 2015 14:33
> To: Ted Lemon; George, Wes
> Cc: Bjoern A. Zeeb; IPv6 Ops WG
> Subject: Re: [v6ops] The need for local-ipv4 socket transition solution=
s --
> NAT64/DNS64 remains insufficient
>=20
> See below
>=20
> > -----Original Message-----
> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon
> > Sent: Wednesday, April 22, 2015 9:38 AM
> > To: George, Wes
> > Cc: Bjoern A. Zeeb; IPv6 Ops WG
> > Subject: Re: [v6ops] The need for local-ipv4 socket transition
> > solutions --
> > NAT64/DNS64 remains insufficient
> >
> > On Apr 22, 2015, at 10:33 AM, George, Wes =

> > wrote:
> > > WG] Should we be trying to raise visibility on this issue in other =
forums?
> > > For instance, IETF has a formal liaison relationship with W3C.
> > > Perhaps an effort there would be useful, even if it doesn't
> > > necessarily cover non-web app developers?
> >
> > I am skeptical that the people who are using IPv4 literals are active=
=20in any
> > standards community.   I suppose it's possible, and reaching out and =
getting
> > e.g. W3C to make a strong statement about this would certainly be goo=
d
> > in the sense that it might shorten the long tail, but I don't think i=
t's going to
> fix the
> > problem soon enough.   I really can't see any way to address this tha=
t doesn't
> > look something like 464xlat or IPv4-as-a-service (e.g. softwire
> MAP/lw4over6).
>=20
> [DJM]
> I see one common theme in this discussion:  "IPv4 literals are harmful.=
"
> If we really want to write a document, that states that IPv4 literals m=
ust not be
> used, shouldn't that be the first step?  Recognize the harm, and make a=
=20strong
> statement that IPv4 literals should/must not be used.
> Why dance around these issues?  Seems to me that this is step 1.  The s=
olution
> is to start by making that strong statement.  If we have tangible infor=
mation
> about who has IPv4 literals, why not make that public?  Let people know=

> where the problems are.
> If the IETF can't bring itself to do this, then there is no need for th=
is discussion,
> because it isn't really a problem, and we can all just turn off IPv4 to=
day, or
> embrace it.
>=20
> Only after addressing the above, (accepting that it is a problem), is i=
t time to
> look at what to do in the meantime as a work around.
> Dual stack is a certainly solution if people aren't ready to move to IP=
v6-only.  It
> gets around the IPv4 literal problem by simply maintaining support for =
IPv4
> while it's needed.
>=20
> So then what if you don't have the IPv4 address space, or you can't do =
dual
> stack?  Well you have 4 options, depending on your situation:
> 1) Go buy more IPv4 address space.  Ok, maybe that's going to be costly=
, but I
> think we knew that was going to happen.  If you need it, then you need =
it.  (If
> you are one of those who suggest that IPv4 will always be there, then d=
o this
> and embrace your future now.)
>=20
> 2) Use 464xlat or IPv4 as a service, and just realize that not everythi=
ng has
> support for that.  When customers call to complain, don't blame the ven=
dor
> who won't support your technology of choice.  Place the blame on those =
using
> IPv4 literals, where it belongs, and point out that there is a document=
=20that
> states it is wrong to implement IPv4 literals; (because IETF took the f=
irst step as
> mentioned above.)
>=20
> 3) Maybe not everything on your network really needs to talk IPv4.  Shi=
ft some
> of your network to IPv6 only, and move the addresses around, to buy tim=
e.  If
> IPv6-only customers call to complain, place the blame on those using IP=
v4
> literals, where it belongs, and point out that there is a document that=
=20states it
> is wrong to implement IPv4 literals; (because IETF took the first step =
as
> mentioned above.)
>=20
> 4) Ignore the issue, and treat it as insignificant.  When customers cal=
l to
> complain, place the blame on those using IPv4 literals, where it belong=
s, and
> point out that there is a document that states it is wrong to implement=
=20IPv4
> literals; (because IETF took the first step as mentioned above.)
>=20
>=20
> If however, a WG and the IETF cannot be bothered to make the statement =
that
> IPv4 literals are bad, then it follows that IETF really would be saying=
=20that IPv4
> literals are not a problem.  It would suggest that IETF is not really c=
ommitted to
> IPv6-only, and that the plan is to try to scale IPv4 to suit the needs =
of
> tomorrow.  My personal opinion is, I think that would be irresponsible,=
=20but I'm
> starting to wonder if that's really where things stand for some.
>=20
> - Dan Metzler
>=20
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> NOTICE AND DISCLAIMER
> This e-mail (including any attachments) is intended for the above-named=

> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or =
use for
> any purpose.
>=20
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachme=
nts are
> free from any virus, but it remains your responsibility to ensure that =
viruses do
> not adversely affect you.
>=20
> EE Limited
> Registered in England and Wales
> Company Registered Number: 02382161
> Registered Office Address: Trident Place, Mosquito Way, Hatfield,
> Hertfordshire, AL10 9BW.
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named p=
erson(s).  If you are not the intended recipient, notify the sender immed=
iately, delete this email from your system and do not disclose or use for=
=20any purpose. =20
=20
We may monitor all incoming and outgoing emails in line with current legi=
slation. We have taken steps to ensure that this email and attachments ar=
e free from any virus, but it remains your responsibility to ensure that =
viruses do not adversely affect you.=20

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


From nobody Mon Apr 27 04:23: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 39C741B3085 for ; Mon, 27 Apr 2015 04:23:00 -0700 (PDT)
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 QVDorUiTSSeQ for ; Mon, 27 Apr 2015 04:22:59 -0700 (PDT)
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 3EA111B3083 for ; Mon, 27 Apr 2015 04:22:59 -0700 (PDT)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C493ADA0088; Mon, 27 Apr 2015 11:22:58 +0000 (UTC)
Received: from [10.0.20.119] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 27 Apr 2015 04:22:58 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Mon, 27 Apr 2015 07:22:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <1B8ED9D0-AF02-4F3A-BFFB-D14AD0B5E043@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>    
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Apr 2015 11:23:00 -0000

On Apr 26, 2015, at 9:37 PM, Lorenzo Colitti  wrote:
> So, assuming it isn't... what sort of questions do you see around =
464xlat that cannot be immediately answered by just saying that "464xlat =
is an unnumbered IPv4-only point-to-point link"?

You're right, that makes it trivial.   Most applications are used to =
dealing with unnumbered IPv4-only point-to-point tunnels, so there's no =
explanation needed!   ;)

Seriously, I have to say that if I saw that explanation, I would have no =
idea what it meant.   My understanding, having never actually _used_ =
464xlat knowingly, is that you open a socket and send on it and it just =
works, and that since most applications don't try to figure out what =
their source address is this isn't a problem.   But that's not what I =
would take your proposed text to mean.


From nobody Mon Apr 27 04:28:14 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 E61071B3096 for ; Mon, 27 Apr 2015 04:28:13 -0700 (PDT)
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 Whm6TY1Hziad for ; Mon, 27 Apr 2015 04:28:13 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 E5F3B1B3097 for ; Mon, 27 Apr 2015 04:28:12 -0700 (PDT)
Received: by igbhj9 with SMTP id hj9so58891548igb.1 for ; Mon, 27 Apr 2015 04:28:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=J/lQNUl/nY/dbgrH0fQWJ+K1GWEkI4lqjhOwwdIaAgM=; b=JUITObrBZUzR5fBwYmBSn+hSW/jwUdW9plrfbfGEh8l1UoDtFfanqs3v1EkwwJ7e2H +rz+xnbprL37WB0Br9222T8iKFb20GlSAelF64bk+79sxLhkkl8RiXIXFQoK1558DXHR uayYHNPR5KfVaUXepDxnxBkFrQbXNCiaA7Jw/qB0BTy1dhd+livyGtUAqweGHAS9lkBk 04l3Gtoce2gi+1JZLc8x5Tdhqif0fHqmqoiMTlXon5pbrRVjuMceYHmVT9jVTAWKVmY7 W6sKldGty8xp0DTiGmuUDZK9C/P2D+zwuQKxmqy5rxcZr3uEeZtpbIMlnayqbeCn3BeX RIYA==
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=J/lQNUl/nY/dbgrH0fQWJ+K1GWEkI4lqjhOwwdIaAgM=; b=MivmzCU/2GYw9HWXVNAeZey6tK9uZKK0uBfQC0ewJ4WzgOWOAxWq/Vz9+F4QewJUaA jZQXB0O7f7eLB0DZTIWJKWUcm9ft9Tt6u2wu4kDLqWWOpL4mbKFcpl9EUVvkkX3KenaE 9CVlgy/EtqT6woE7xKW8z0JZ4R6E4ZyOPB6M4QTVERafEVd+1qFgEOAxNNxOuRqObwO6 nrz1ffD3WGYmU4n3mxwS5SjdqIf1bznajvUenLn1tL1QtEFBt6WGJOkctx4HDiTgBD10 Eo2hLOCxM78vlsNUIRYwyDEem9nY9/DultKAVXWZ76gAMp8dbmVl9Dj0qB+Ptu3IzWXq nOVQ==
X-Gm-Message-State: ALoCoQkJfXrR86KnnJfjSvTvQMaol56PpdzOTloQOPvNXve7d//m4+yLcRLgwXJr7JlQlQcDAfZW
X-Received: by 10.107.130.145 with SMTP id m17mr12759802ioi.89.1430134092269;  Mon, 27 Apr 2015 04:28:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.73.2 with HTTP; Mon, 27 Apr 2015 04:27:51 -0700 (PDT)
In-Reply-To: <1B8ED9D0-AF02-4F3A-BFFB-D14AD0B5E043@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>     <1B8ED9D0-AF02-4F3A-BFFB-D14AD0B5E043@nominum.com>
From: Lorenzo Colitti 
Date: Mon, 27 Apr 2015 20:27:51 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=001a113ed02a8d35420514b30a4b
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Apr 2015 11:28:14 -0000

--001a113ed02a8d35420514b30a4b
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 27, 2015 at 8:22 PM, Ted Lemon  wrote:

> You're right, that makes it trivial.   Most applications are used to
> dealing with unnumbered IPv4-only point-to-point tunnels, so there's no
> explanation needed!   ;)
>

Yes, they are. One such tunnel is PPPoE.

Seriously: in IP, typical applications don't know and don't care about the
link types they operate on. Your browser neither knows nor cares whether
you're on Ethernet, cellular data, or on an IPv6-in-IPv4 tunnel. They call
the sockets API and stuff works.

Seriously, I have to say that if I saw that explanation, I would have no
> idea what it meant.   My understanding, having never actually _used_
> 464xlat knowingly, is that you open a socket and send on it and it just
> works, and that since most applications don't try to figure out what their
> source address is this isn't a problem.


Yes, it just works. It's not a problem even if they try to figure out what
their source address is, either - it's 192.0.0.4.

--001a113ed02a8d35420514b30a4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Apr 27, 2015 at 8:22 PM, Ted Lemon <Ted.Lemon@nominum.com><=
/span> wrote:
You're right, that make=
s it trivial.=C2=A0 =C2=A0Most applications are used to dealing with unnumb=
ered IPv4-only point-to-point tunnels, so there's no explanation needed=
!=C2=A0 =C2=A0;)

Yes, they are. One suc=
h tunnel is PPPoE.

Seriously: in IP, typical appli=
cations don't know and don't care about the link types they operate=
 on. Your browser neither knows nor cares whether you're on Ethernet, c=
ellular data, or on an IPv6-in-IPv4 tunnel. They call the sockets API and s=
tuff works.

Seriously, I=
 have to say that if I saw that explanation, I would have no idea what it m=
eant.=C2=A0 =C2=A0My understanding, having never actually _used_ 464xlat kn=
owingly, is that you open a socket and send on it and it just works, and th=
at since most applications don't try to figure out what their source ad=
dress is this isn't a problem.

Yes, it =
just works. It's not a problem even if they try to figure out what thei=
r source address is, either - it's 192.0.0.4.


--001a113ed02a8d35420514b30a4b--


From nobody Mon Apr 27 06:01: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 7F6801B316B for ; Mon, 27 Apr 2015 06:01:30 -0700 (PDT)
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 3agearXYmfN7 for ; Mon, 27 Apr 2015 06:01:27 -0700 (PDT)
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 C8D431B316A for ; Mon, 27 Apr 2015 06:01:27 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4FCD3DA0072; Mon, 27 Apr 2015 13:01:27 +0000 (UTC)
Received: from [10.0.20.123] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 27 Apr 2015 06:01:27 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Mon, 27 Apr 2015 09:01:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>     <1B8ED9D0-AF02-4F3A-BFFB-D14AD0B5E043@nominum.com> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Apr 2015 13:01:30 -0000

> On Apr 27, 2015, at 7:27 AM, Lorenzo Colitti  =
wrote:
>> Seriously, I have to say that if I saw that explanation, I would have =
no idea what it meant.   My understanding, having never actually _used_ =
464xlat knowingly, is that you open a socket and send on it and it just =
works, and that since most applications don't try to figure out what =
their source address is this isn't a problem.
>=20
> Yes, it just works. It's not a problem even if they try to figure out =
what their source address is, either - it's 192.0.0.4.

Well and good, but I think you missed my point, which is simply that =
your explanation isn't going to help the people we need to help.   If =
indeed there is no API extension required, that's great, but I think the =
base of James' request was simply to have the IETF say what needs to be =
done to make 464XLAT work.   Either we've already said that, and James =
doesn't know what document to read, or we haven't, and there's a problem =
we could solve.   If the document is only a page, that makes solving the =
problem pretty easy.


From nobody Mon Apr 27 06:11: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 C65121A00B7 for ; Mon, 27 Apr 2015 06:11:10 -0700 (PDT)
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 BnaPm-sK22b0 for ; Mon, 27 Apr 2015 06:11:09 -0700 (PDT)
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 0335B1A0095 for ; Mon, 27 Apr 2015 06:11:09 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id EA766DA0088; Mon, 27 Apr 2015 13:11:08 +0000 (UTC)
Received: from [10.0.20.123] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 27 Apr 2015 06:11:02 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Mon, 27 Apr 2015 09:10:59 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <3B7386A5-B0A7-4AC6-98F0-476D5A73095C@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>     <1B8ED9D0-AF02-4F3A-BFFB-D14AD0B5E043@nominum.com>  
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Apr 2015 13:11:11 -0000

On Apr 27, 2015, at 9:01 AM, Ted Lemon  wrote:
> I think the base of James' request was simply to have the IETF say =
what needs to be done to make 464XLAT work.

That is, what needs to be done by operating system vendors.


From nobody Mon Apr 27 11: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 9FA021A90C0 for ; Mon, 27 Apr 2015 11:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 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] 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 9Lt-4FstFaZA for ; Mon, 27 Apr 2015 11:21:21 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 614471A90BF for ; Mon, 27 Apr 2015 11:21:21 -0700 (PDT)
Received: by wizk4 with SMTP id k4so110323850wiz.1 for ; Mon, 27 Apr 2015 11:21:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j83H1lrXsSB4AXYXB/qbfLmsp/EEp/vKuZZZW9Sx2qs=; b=WoPmnaLqmj5umaOhzi9MdC4bEm0ILvyZN3cfIgZ4GAZ4eH3AJJC8STYgxIZ16cSIQ7 SRQvKOiXWEp3F8geyBmi91qDMh0b+cy2jjS81Dl2nkB9UIw+TkIT2VR18euDtWhu9+Tk ANuBuZoGpby8pL7UNeDHcHoevD3BsEf24iOKQ=
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=j83H1lrXsSB4AXYXB/qbfLmsp/EEp/vKuZZZW9Sx2qs=; b=hB68KdmYTNAr6xatUE6xStV5ZeHC603XI7i/0daCf1yxlEJoZ3ssTkzvp3rNG6rGu5 qTpSq18I5C2Q6Me/44jERB8gMm3spRCMr/pb02jABZKUBX6JHVDBqnjAe2bCS8/k4J+J Nuqy5aMPsTc2A9+TzsIjSSR64Bz4TCtfIXwNX0a08+giaiEjkVIOS5i6xPveL5HZZ7zN CMdSFDhUZzq/jy8DwQ9WvD3L/Dm0Y+y6vDhr/tiQgcolJFAweEvaEiDKL5N0orRL4SV2 dGuRacEKWwe23WZo0Jbhc5KZ9FMCyaOCXtjkbF/O0c8HD6m+fBgLweXYTMXqkm1jwc/Z JaYw==
X-Gm-Message-State: ALoCoQlTZ9S9VM0SQW0F7oaPRnGDjtcevzMZqOggeRpSckWHKW7DsTaMNi+DKtNM//4+y/ArS2/e
MIME-Version: 1.0
X-Received: by 10.194.52.10 with SMTP id p10mr24013224wjo.98.1430158880061; Mon, 27 Apr 2015 11:21:20 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Mon, 27 Apr 2015 11:21:19 -0700 (PDT)
In-Reply-To: <1B8ED9D0-AF02-4F3A-BFFB-D14AD0B5E043@nominum.com>
References:           <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn>  <55290E26.8080500@cernet.edu.cn>  <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>   <54AE4471-B568-4A92-B12D-137AD5950B60@nominum.com>     <1B8ED9D0-AF02-4F3A-BFFB-D14AD0B5E043@nominum.com>
Date: Mon, 27 Apr 2015 11:21:19 -0700
Message-ID: 
From: James Woodyatt 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=047d7bae428604d3c40514b8d038
Archived-At: 
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Apr 2015 18:21:23 -0000

--047d7bae428604d3c40514b8d038
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 27, 2015 at 4:22 AM, Ted Lemon  wrote:

> On Apr 26, 2015, at 9:37 PM, Lorenzo Colitti  wrote:
> > So, assuming it isn't... what sort of questions do you see around
> 464xlat that cannot be immediately answered by just saying that "464xlat is
> an unnumbered IPv4-only point-to-point link"?
>

I'll provide the beginning of an answer to Lorenzo's specific question
below, but I think the topic would be better handled at the IETF 93 meeting.

Also, I'm not trying to stall the conversation. I'm actually trying to
provoke what I think would be a reasonable way to keep the conversation
going in a productive direction: by improving the situation for application
programmers and host operating systems maintainers who will be forced to
live with 464XLAT for the foreseeable future if the recommendation in this
proposed BCP is widely adopted.

You're right, that makes it trivial.   Most applications are used to
> dealing with unnumbered IPv4-only point-to-point tunnels, so there's no
> explanation needed!   ;)
>
> Seriously, I have to say that if I saw that explanation, I would have no
> idea what it meant.   My understanding, having never actually _used_
> 464xlat knowingly, is that you open a socket and send on it and it just
> works, and that since most applications don't try to figure out what their
> source address is this isn't a problem.   But that's not what I would take
> your proposed text to mean.
>

Most applications don't even really want to know they are using TCP/IP,
much less which version of it. The whole point of 464XLAT is to cover the
special category of applications that do not make the usual assumptions and
use the corner cases of the IPv4-only application programming interfaces in
the host operating system. There are a lot of corner cases. So, here are
some example questions.

1. What about MIF? It's not sufficient to simply say put an IPv4 address on
the point-to-network pseudo-link for each provider. How does an application
that cares about which interface it's using know which IPv4 address belongs
to which interface? Does the getifaddrs() [not POSIX, but commonly
implemented] return results showing them all on the same interface? Or
different interfaces? How does an application sending a packet from a UDP
socket without a source address bound use IP_PKTINFO to specify which
source interface to use if ipi_spec_dst is zero? What about dual-stack
applications that care about which IP addresses are attached at which
interfaces over time? How do they know what IPv4 addresses are associated
with which interface if all the CLAT IPv4 addresses are attached to a
point-to-network pseudo-link instead of the interface where the CLAT IPv6
address is attached?

2. Consider the interaction an IPv6 listener and an IPv4 listener binding
to the same UDP port without using either SO_REUSEADDR option [or the
non-standard SO_REUSEPORT option], where the IPv6 socket is binding to the
same interface address that the CLAT will translate for the interface
address bound by the IPv4 socket? Does only the first socket() call succeed
while the second one fails? Or is there a different semantic? If so, what
is it?

3. Suppose instead the applications in the example above (2) do use
SO_REUSEADDR [and SO_REUSEPORT], and there are now two sockets bound to the
same IPv6 address and port, one of them translated by the CLAT and the
other not. Can these two applications communicate over interface loopback
through the CLAT?

Just saying that the CLAT is "an unnumbered IPv4-only point-to-point link"
tells us nothing about what application programmers can expect in these
sorts of weird corner cases, but the whole point of 464XLAT is to support
applications that don't use the protocol-independent interfaces.

I can understand why one might not want to document the answers to these
questions. Doing so might expose precisely how 464XLAT doesn't actually
deliver IPv4-only equivalence to applications on IPv6-only networks, but I
contend it's important to describe precisely what the CLAT does and doesn't
enable. Explaining what remains broken even after deploying a CLAT in every
host operating system will go a long way toward retaining a sensible
argument for application developers to migrate away from IPv4-only
programming interfaces.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--047d7bae428604d3c40514b8d038
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Apr 27, 2015 at 4:22 AM, Ted Lemon <Ted.Lemon@nominum.com><=
/span> wrote:
On Apr 26, 2015, at 9:37=
 PM, Lorenzo Colitti <lorenzo@goog=
le.com> wrote:

> So, assuming it isn't... what sort of questions do you see around =
464xlat that cannot be immediately answered by just saying that "464xl=
at is an unnumbered IPv4-only point-to-point link"?

I'll provide the beginning of an answer to Lor=
enzo's specific question below, but I think the topic would be better h=
andled at the IETF 93 meeting.

Also, I'm not t=
rying to stall the conversation. I'm actually trying to provoke what I =
think would be a reasonable way to keep the conversation going in a product=
ive direction: by improving the situation for application programmers and h=
ost operating systems maintainers who will be forced to live with 464XLAT f=
or the foreseeable future if the recommendation in this proposed BCP is wid=
ely adopted.


You're right, that makes it trivial.=C2=A0 =C2=A0Most applicatio=
ns are used to dealing with unnumbered IPv4-only point-to-point tunnels, so=
 there's no explanation needed!=C2=A0 =C2=A0;)



Seriously, I have to say that if I saw that explanation, I would have no id=
ea what it meant.=C2=A0 =C2=A0My understanding, having never actually _used=
_ 464xlat knowingly, is that you open a socket and send on it and it just w=
orks, and that since most applications don't try to figure out what the=
ir source address is this isn't a problem.=C2=A0 =C2=A0But that's n=
ot what I would take your proposed text to mean.



Most applications don't even really want to know=
 they are using TCP/IP, much less which version of it. The whole point of 4=
64XLAT is to cover the special category of applications that do not make th=
e usual assumptions and use the corner cases of the IPv4-only application p=
rogramming interfaces in the host operating system. There are a lot of corn=
er cases. So, here are some example questions.

1. What about MIF? It's not su=
fficient to simply say put an IPv4 address on the point-to-network pseudo-l=
ink for each provider. How does an application that cares about which inter=
face it's using know which IPv4 address belongs to which interface? Doe=
s the getifaddrs() [not POSIX, but commonly implemented] return results sho=
wing them all on the same interface? Or different interfaces? How does an a=
pplication sending a packet from a UDP socket without a source address boun=
d use IP_PKTINFO to specify which source interface to use if ipi_spec_dst i=
s zero? What about dual-stack applications that care about which IP address=
es are attached at which interfaces over time? How do they know what IPv4 a=
ddresses are associated with which interface if all the CLAT IPv4 addresses=
 are attached to a point-to-network pseudo-link instead of the interface wh=
ere the CLAT IPv6 address is attached?

=

2. Consider the interaction an IPv6 listen=
er and an IPv4 listener binding to the same UDP port without using either S=
O_REUSEADDR option [or the non-standard SO_REUSEPORT option], where the IPv=
6 socket is binding to the same interface address that the CLAT will transl=
ate for the interface address bound by the IPv4 socket? Does only the first=
 socket() call succeed while the second one fails? Or is there a different =
semantic? If so, what is it?

3. Suppose instead the applications=C2=A0in the exam=
ple above (2)=C2=A0do use SO_REUSEADDR [and SO_REUSEPORT], and there are no=
w two sockets bound to the same IPv6 address and port, one of them translat=
ed by the CLAT and the other not. Can these two applications communicate ov=
er interface loopback through the CLAT?
Just saying that the CLAT is "an unn=
umbered IPv4-only point-to-point link" tells us nothing about what app=
lication programmers can expect in these sorts of weird corner cases, but t=
he whole point of 464XLAT is to support applications that don't use the=
 protocol-independent interfaces.

I can understand why one might not want to docu=
ment the answers to these questions. Doing so might expose precisely how 46=
4XLAT doesn't actually deliver IPv4-only equivalence to applications on=
 IPv6-only networks, but I contend it's important to describe precisely=
 what the CLAT does and doesn't enable. Explaining what remains broken =
even after deploying a CLAT in every host operating system will go a long w=
ay toward retaining a sensible argument for application developers to migra=
te away from IPv4-only programming interfaces.

-- 
james woodya=
tt <jhw@nestlabs.c=
om>
Nest Labs, Communications Engineering




--047d7bae428604d3c40514b8d038--