From nobody Sat Aug 1 02:33:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C021B2C8E; Sat, 1 Aug 2015 02:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_44=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 Nog6FqVETm5b; Sat, 1 Aug 2015 02:33: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 8B5F01A002A; Sat, 1 Aug 2015 02:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2922; q=dns/txt; s=iport; t=1438421585; x=1439631185; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=cCWEUVpOr1hzipzqO37Hixb+FO300IRjweHZNqcCYY0=; b=jrrKPJlDtVcNwaEnF9/mqRCC+dglmdRRXkCZvQ1F2NNQyOQ+7FzJooXP IPW1PTLlPz6DpQ9SQHh4i2JzB8wLOvqmNkaztc+x88ljD/7BIZPd1VDsR RSZVijSJ1KyC/GswtmdnYUhLvq6MCaBob3ILn6bxdZtv72phf9y/GpawF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjAwAlkbxV/4sNJK1RChkBAQGCflRpvEMJggiFdQKBIjgUAQEBAQEBAYEKhCMBAQEBAgEnEz8FCwsYCSUPBUmIOQgNyDUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0+EK10HgxiBFAWNQYQ2gwKMSgKBR4Qgk2EmhB0eMYJMAQEB X-IronPort-AV: E=Sophos;i="5.15,591,1432598400"; d="scan'208";a="174442543" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP; 01 Aug 2015 09:33:04 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t719X4kA025682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2015 09:33:04 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t719X3hG005688; Sat, 1 Aug 2015 02:33:03 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t719X3ei005687; Sat, 1 Aug 2015 02:33:03 -0700 Date: Sat, 1 Aug 2015 02:33:03 -0700 From: Toerless Eckert To: Tore Anderson Message-ID: <20150801093303.GA4585@cisco.com> References: <20150730205806.GI1667@cisco.com> <55BBA7C1.3000502@gmail.com> <20150731174421.GA9032@cisco.com> <20150731221716.5729154a@envy.fud.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150731221716.5729154a@envy.fud.no> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Aug 2015 09:33:07 -0000 On Fri, Jul 31, 2015 at 10:17:16PM +0200, Tore Anderson wrote: > Yep, but be aware that with SIIT you will need to identify all > the IPv6 endpoints you want the IPv4-only NOC folks to be able to > access. These endpoints need either to be provisioned with an > IPv4-translatable IPv6 address (traditional SIIT), or get an IPv4 > mapping provisioned on the protocol translator (SIIT-DC style > deployment with EAMs). The autonomic addressing plan proposed so far is that we'd have very few eg; /112 prefixes (eg: one per so-called registrar), and then eg: 16 bit of serial number. So you can see how easy this would map with siit-eam. > You could also use Stateful NAT64 (RFC6146) > with statically configured BIB entries to accomplish pretty much the > same thing as the SIIT-DC approach, but you do get a lot of superfluous > baggage that way (all the stateful connection/session tracking stuff). Is there a Yang model for 4146 so i can beter understand what the intended operator experience is ? ;-)) Yes, it does mention "static configured mapping" in three places in the text, and i see in Cisco IOS implementation also the ability to configure 1:1 IPv4<->IPv6 mappings, and i therefore guess that these are the "static configured mappings" of 4146, but what i can't find is any explanation why the operations of such entries would have to be stateful at all. What would those 4146 entries do different than stateless siit-eam /32 <-> /128 entries, and whats the "benefit" ? But obviously, in a network with 50,000 IPv6 nodes with ULAs, i wouldn't want to set up an orchestration to configure 50,000 1:1 entries, even stateless, but rather a single /16 <-> /112 (or a few similar slightly longer prefixes). > BTW you asked about traceroute, and I don't think anyone answered, so: > ICMPv6 packets originated by IPv6 hops behind the translator (that are > not provisioned with an IPv4-translatable IPv6 address) will appear as > originating from a "random" IPv4 address (which could repeat multiple > times in the path). Thanks. > That could possibly be confusing to NOC staff, so > I'd suggest giving the RFC6791 addresses descriptive PTR records in DNS > ("this-apparent-ipv4-hop-really-represents-an-ipv6-router-in-the-autonomic-network-see-rfc6791.example.com"). Yepp. Haven't gotten around to all DNS recommendations, but given how i am trying to see that full stateless mapping will suffice i hopefully won't run intot hese problems. > Let me know if you want some help or pointers on how to set up a > stateless translator for testing purposes. Or you could use one of > mine, as it works just as well over the public internet too (as long as > the IPv6 endpoints you want to manage are numbered with globally > reachable addresses). I'd be happy to assist. Sure, please send me pointers offline, i'll take a look! Cheers Toerless From nobody Sat Aug 1 04:47: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 304A21B2FBC for ; Sat, 1 Aug 2015 04:47:05 -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 uL4FwqssPapA for ; Sat, 1 Aug 2015 04:47:04 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF161ACE9C for ; Sat, 1 Aug 2015 04:47:03 -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=1438429624; x=1439639224; h=date:from:message-id:to:subject:cc; bh=a8MOXNQawjaYAJAqQTAe2OHLecWYhH8Je6K58pf+JGA=; b=clTivKgmlSBBTCpA2hA6EGwlWQp1a8RmgW/ueYbn46KkjpvmshrxaTsE 1uapsUSVcMv1fSnLJSBvI+qWN6QW/ASXEyMIfE8kaLkDAW8Z9TyZbmlGz TtaNEaP4iWt3Fh26XaLgRbmDspsTYRN1vb9Ggn65yPfPe1sGVDWQCOAks Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoCADbsLxV/4oNJK1bGQEBAYJ+VGqsdQGPTQmCBIVwCYEkOBQBAQEBAQEBgQpBA4NifTw0iQ4BDcgyAQEBBwEBAQEBHYtPhQgehBUFjUGHOIR7iRhGg1qTYSaEHYMbAQEB X-IronPort-AV: E=Sophos;i="5.15,591,1432598400"; d="scan'208";a="174555315" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 01 Aug 2015 11:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t71Bl29N018990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2015 11:47:02 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t71Bl2i5020992; Sat, 1 Aug 2015 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t71Bl2xr020991; Sat, 1 Aug 2015 04:47:02 -0700 Date: Sat, 1 Aug 2015 04:47:02 -0700 From: fred@cisco.com Message-Id: <201508011147.t71Bl2xr020991@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-host-addr-availability@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Aug 2015 11:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. Please take a look at it and comment. From nobody Sun Aug 2 08:25: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 C54341AC3C2; Sun, 2 Aug 2015 08:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_44=1, 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 D6NrUTZdJkw1; Sun, 2 Aug 2015 08:25:01 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572331AC3B5; Sun, 2 Aug 2015 08:25:01 -0700 (PDT) Received: from [2a01:79d:4fcf:67e4:b6b6:76ff:fe17:2e83] (port=57027 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZLv8D-00025E-Ir; Sun, 02 Aug 2015 17:24:57 +0200 Date: Sun, 2 Aug 2015 17:24:56 +0200 From: Tore Anderson To: Toerless Eckert Message-ID: <20150802172456.39635936@envy.fud.no> In-Reply-To: <20150801093303.GA4585@cisco.com> References: <20150730205806.GI1667@cisco.com> <55BBA7C1.3000502@gmail.com> <20150731174421.GA9032@cisco.com> <20150731221716.5729154a@envy.fud.no> <20150801093303.GA4585@cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Aug 2015 15:25:02 -0000 * Toerless Eckert > On Fri, Jul 31, 2015 at 10:17:16PM +0200, Tore Anderson wrote: > > You could also use Stateful NAT64 (RFC6146) > > with statically configured BIB entries to accomplish pretty much the > > same thing as the SIIT-DC approach, but you do get a lot of superfluous > > baggage that way (all the stateful connection/session tracking stuff). > > Is there a Yang model for 4146 so i can beter understand what the > intended operator experience is ? ;-)) > > Yes, it does mention "static configured mapping" in three places in the > text, and i see in Cisco IOS implementation also the ability to > configure 1:1 IPv4<->IPv6 mappings, and i therefore guess that these > are the "static configured mappings" of 4146, but what i can't find > is any explanation why the operations of such entries would have > to be stateful at all. What would those 4146 entries do different than > stateless siit-eam /32 <-> /128 entries, and whats the "benefit" ? Well, one implementation I tested (Cisco ASR1K) allowed these 1:1 IPv4<->IPv6 mappings in Stateful NAT64 mode. However I noticed that it did install session table entries for every connection made towards the statically mapped IPv4 address. Not sure if those session table entries were ever used for anything though. Another implementation (Jool) would allows adding static BIB entries in Stateful NAT64 mode, but it requires you to also include the ports used - so if you wanted to do a full 1:1 mapping between an IPv4 address and an IPv6 address you'd have to add 64k static BIB entries in order to make traffic to arbitrary ports work... > But obviously, in a network with 50,000 IPv6 nodes with ULAs, > i wouldn't want to set up an orchestration to configure 50,000 > 1:1 entries, even stateless, but rather a single /16 <-> /112 > (or a few similar slightly longer prefixes). Indeed, if the IPv6 destinations are nicely aggregatable in a small prefix like a /112 SIIT with an EAM sounds like exactly what you want. I'll follow up off-list. Tore From nobody Sun Aug 2 11:00: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 804AE1A1BE0 for ; Sun, 2 Aug 2015 11:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.112 X-Spam-Level: X-Spam-Status: No, score=-111.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IXHASH_X1=1.5, 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 KqOgrY1O37nX for ; Sun, 2 Aug 2015 11:00:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204351A1BD4 for ; Sun, 2 Aug 2015 11:00:04 -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=1438538405; x=1439748005; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=MrfPOPgYaYDzcExUYEuBxPwLwO5Ly508jlQcbGWXAQRdpAt5saicwWbg XRNtfeJZJJUpzyQSwf1P8A34VOZndBndGQ3RPJryHUDRJkpChj6OQ3Wmu 9dQftQZthiZs7Lq2vIT4q1RqQfsUuWPRPh1+hdL0Wj5KXVH28Pt3e8Dec g=; X-IronPort-AV: E=Sophos;i="5.15,595,1432598400"; d="scan'208";a="20813220" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP; 02 Aug 2015 18:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t72I02EN020210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Aug 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 t72I02HZ025936; Sun, 2 Aug 2015 11:00:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t72I029v025935; Sun, 2 Aug 2015 11:00:02 -0700 Date: Sun, 2 Aug 2015 11:00:02 -0700 From: fred@cisco.com Message-Id: <201508021800.t72I029v025935@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-siit-dc 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, 02 Aug 2015 18:00:05 -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 Tue Aug 4 10:47: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 639171A8A6A; Tue, 4 Aug 2015 10:47:42 -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 mgj_KSLl-3eV; Tue, 4 Aug 2015 10:47:40 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9B21A8A65; Tue, 4 Aug 2015 10:47:40 -0700 (PDT) Received: from [128.9.184.236] ([128.9.184.236]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t74Hl7Eg029392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Aug 2015 10:47:08 -0700 (PDT) To: Mark Smith References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> <55BC16EB.8060007@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55C0FA9A.1020001@isi.edu> Date: Tue, 4 Aug 2015 10:47:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t74Hl7Eg029392 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "behave@ietf.org" , v6ops list Subject: Re: [v6ops] protocols without need for ALG ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Aug 2015 17:47:42 -0000 Hi, Mark, On 7/31/2015 7:50 PM, Mark Smith wrote: ... > If I recall correctly, FTP uses TCP port 20 on one of the ends of the > file transfer, so that's the fixed port you can match on if you need > to. FTP has two modes. Active mode uses a fixed server port (21) for commands and a fixed client port (20) for each data transfer. Passive mode uses a fixed server port (21) and let's the server tell the client the server's port for each subsequent transfer. Passive mode won't work when the client is behind a NAT because the server can't call the client on a known port. In passive mode, the ports are sent back from the server in-band. It works when the client is on the private side of a NAT because the client still calls the server. In-band port numbers are used only in passive mode. You'd think that would mean that passive mode would require translation, but it's because of the direction of the use of the ports that translation isn't required. >>> I think a server could choose to continue to use 69 as its TID for the >>> full transfer, however in my case it didn't. ... > I haven't thought much about it, however I was thinking that the > combination of client address and TID would uniquely identify the file > transfer, so the server could still use TID 69 if it chose to. Yes, it *could*, and that'd be a decision totally up to the server. However, the server code would need to know when it can 'reuse' that number. By the current spec, the TIDs are not reused (for some time period) regardless of address, which simplifies servers state. Note that there might be another reason for this. Booting might occur from a temporary address or even a shared address, so there might be a benefit to not needing to avoid reuse of that one port to that one address. ... >>> So if in Toerless's scenario it is stateless 1:1 translation between >>> IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. >>> However, if the translation is stateful because translation between >>> IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a >>> mapping of some form. >> >> So first let me backtrack - TFTP requires an ALG to work through a NAT >> even when the client is on the private side. The return traffic content >> needs to be inspected to be able to update the private:public >> translation entry. >> >> I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an >> ALG. I can't imagine how to make sense of it safely in a non-1:1 case. >> > > I was thinking that stateless 1:1 translation between IPv4 and IPv6 > addresses in the IP headers would work without an TFTP ALG, as long as > the UDP Ports/TIDs could be ignored, as there are no IP addresses in > the TFTP packets that would need to be translated. I really don't think you want to run TFTP through anything that isn't local (see below). ... >> Note that the whole point of TFTP is to be used on a LAN only. It has >> zero security, and it's easily possible that the translation entry could >> inadvertently affect some other UDP translation entry. > > For many years it was the only way to upload firmware and > configuration into a certain vendor's routers, and usually they were > remote! People used to leave their front doors unlocked too, but those days are over. IMO, TFTP ought to be blocked through anything that indicates "off-lan" access. (even though TFTP is still widely used, e.g., in UEFI) Joe From nobody Wed Aug 5 01:13: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 D4E091B2D50 for ; Wed, 5 Aug 2015 01:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=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 bh8eN5j6sJMe for ; Wed, 5 Aug 2015 01:13:33 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 82B161B2D91 for ; Wed, 5 Aug 2015 01:13:25 -0700 (PDT) Received: by ykoo205 with SMTP id o205so29364867yko.0 for ; Wed, 05 Aug 2015 01:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ArXXsOIv+mvP2r2GKtbv031fLliKj2ibTq6wGSDiAaY=; b=QGJB39/1UMccLI1uUkhOBqPF0RxNExPwBjvaPSLTazTqpYRuy45jLHgWAMOhePyI6v MvrXIIa2A8ip8C+nKLjH2W6agN6MOf04yK+fElOBCKTxNRPrqNUpOH6LpkLW7Avnd6Ob sDZyH0H/GTQy7j41OJYVkWFOoToqULgTlc3oSdmR1XnEp2YFf7yfS3p0rdCy1ANQj8yg APzf5TqL1AereGxBxP4CW0qXDZRrMLE97miZWFB+uP2pwPKk25c1pZ9le3DUjDcVguhi p972l9MuZWU8e58AtSAcFS4/toO/rnAa/OP53REquPpWRfUB8lG8zInV1RjYfUpXexAW etdw== 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=ArXXsOIv+mvP2r2GKtbv031fLliKj2ibTq6wGSDiAaY=; b=DeI6r84w0MqTRVRWZNmVrVo1HVkZ/y/Sc5Z2icYboxzDdHabn6EObVPj1aKDrIPfpI 5CKT9M/XP+uQVpROcVso4s24Bl4Xxu7qXLMeHB5edjIqQW4xTq2c+hWkVYSU/edY7wnw w39W7HnsPGgMWY5h31q3DVajjwRyoFy6yiZZf0XOYEOq46Bwz2tJQKSSQF0uCUNz4pR0 cs6ik3zurhMKFhNS0c695NTeF3E9GIFSVcRw1MePiV1qLxnJfNNxEanpWDIIz3QQOAjJ VfC16H1poyOtmVqGiHJhngeffKs7mSRGdN7P1tQAR34EGXZa+PDyLlUrSb4w/DSIzt43 IPbQ== X-Gm-Message-State: ALoCoQmOEheuH5+saBI9v2mFD6vsduJFPU148syITw8RiE/bQ313Hf9yfJcXzc9PNvQBHmFwmARR X-Received: by 10.170.153.85 with SMTP id u82mr8265959ykc.53.1438762404713; Wed, 05 Aug 2015 01:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 5 Aug 2015 01:13:04 -0700 (PDT) In-Reply-To: References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Wed, 5 Aug 2015 17:13:04 +0900 Message-ID: To: "George, Wes" Content-Type: multipart/alternative; boundary=001a113b396e0d1f8f051c8bfab6 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Aug 2015 08:13:35 -0000 --001a113b396e0d1f8f051c8bfab6 Content-Type: text/plain; charset=UTF-8 Wes, many of these comments will be addressed in a respin, so I'm picking only one to answer here. Section 5 - I think we need to cut this section down to a bare minimum or > eliminate it. Waving the NAT boogeyman isn't really the argument to lead > with, unless the authors or other OS manufacturers actually see this as a > credible alternative and are willing to implement it instead of other > options. Otherwise it's just FUD. It's more accurate at this point to say > that NAT doesn't exist for IPv6, because the IETF document is experimental > (IIRC, I'm writing this on a plane and can't check) and no implementations > really exist in the wild, so another solution is required. We've already > written plenty about why NATs are bad elsewhere. > Unfortunately NAT66 *is* a credible alternative, and implementations definitely do exist. I know for sure that Juniper ships a fully-stateful NAT implementation on the SRX (and I don't mean NPTv6, I mean fully-stateful NAT44-style address+port NAT), and I think I head that Cisco does too. That said, this document is about general-purpose hosts, so let's take Android as an example. Linux has had a fully-stateful NAT66 implementation since late 2012 - http://mirrors.bieringer.de/Linux+IPv6-HOWTO/nat-netfilter6..html - and members of the Android community have proposed enabled it multiple times, for example: https://android-review.googlesource.com/#/c/88648/ https://android-review.googlesource.com/#/c/88657/ These changes ended up not being included in the OS, but I think part of the motivation is that they would not have added any useful functionality that could not be obtained in a better way. The VPN code was rewritten in 5.0 to use per-app routing instead of in-device NAT (which fixed a series of IPv4 bugs as well), and that brought IPv6 support without needing to use NAT66. And even though stock Android does not yet support IPv6 tethering, NAT66 would not have provided any benefit because Android doesn't support networks that require explicit requests to obtain IPv6 addresses (i.e., DHCPv6-only networks) and thus can use ND proxying for tethering with no loss of functionality. On the other hand, for a device that supports DHCPv6-only networks that provide only one address, NAT66 *would* provide useful functionality: it would make it possible to provide IPv6 tethering and other functions that require more than one address on those networks. --001a113b396e0d1f8f051c8bfab6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wes,=

many = of these comments will be addressed in a respin, so I'm picking only on= e to answer here.

Section 5 - I think we need to c= ut this section down to a bare minimum or
eliminate it. Waving the NAT boogeyman isn't really the argument to lea= d
with, unless the authors or other OS manufacturers actually see this as a credible alternative and are willing to implement it instead of other
options. Otherwise it's just FUD. It's more accurate at this point = to say
that NAT doesn't exist for IPv6, because the IETF document is experimen= tal
(IIRC, I'm writing this on a plane and can't check) and no implemen= tations
really exist in the wild, so another solution is required. We've alread= y
written plenty about why NATs are bad elsewhere.

<= /div>
Unfortunately NAT66 *is* a credible alternative, and implementati= ons definitely do exist. I know for sure that Juniper ships a fully-statefu= l NAT implementation on the SRX (and I don't mean NPTv6, I mean fully-s= tateful NAT44-style address+port NAT), and I think I head that Cisco does t= oo.

That said, this document is about general-purp= ose hosts, so let's take Android as an example. Linux has had a fully-s= tateful NAT66 implementation since late 2012 - http://mirrors.bieringer.= de/Linux+IPv6-HOWTO/nat-netfilter6..html - and members of the Android c= ommunity have proposed enabled it multiple times, for example:

These changes ended up not being included in the OS, but I think part of= the motivation is that they would not have added any useful functionality = that could not be obtained in a better way. The VPN code was rewritten in 5= .0 to use per-app routing instead of in-device NAT (which fixed a series of= IPv4 bugs as well), and that brought IPv6 support without needing to use N= AT66. And even though stock Android does not yet support IPv6 tethering, NA= T66 would not have provided any benefit because Android doesn't support= networks that require explicit requests to obtain IPv6 addresses (i.e., DH= CPv6-only networks) and thus can use ND proxying for tethering with no loss= of functionality.

On the other hand, for a device= that supports DHCPv6-only networks that provide only one address, NAT66 *w= ould* provide useful functionality: it would make it possible to provide IP= v6 tethering and other functions that require more than one address on thos= e networks.
--001a113b396e0d1f8f051c8bfab6-- From nobody Wed Aug 5 01:36: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 3AB221B2DBF; Wed, 5 Aug 2015 01:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=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 C81mBelT2qIi; Wed, 5 Aug 2015 01:36: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 CA6CE1B2DBD; Wed, 5 Aug 2015 01:36: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 D41071FCB9D; Wed, 5 Aug 2015 08:36:38 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5681D16007F; Wed, 5 Aug 2015 08:37:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1A87716006F; Wed, 5 Aug 2015 08:37:42 +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 zVFYXlnPYlcJ; Wed, 5 Aug 2015 08:37:42 +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 7DEC6160042; Wed, 5 Aug 2015 08:37:41 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4CF0C3429549; Wed, 5 Aug 2015 18:36:34 +1000 (EST) To: Joe Touch From: Mark Andrews References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> <55BC16EB.8060007@isi.edu> In-reply-to: Your message of "Fri, 31 Jul 2015 17:46:35 -0700." <55BC16EB.8060007@isi.edu> Date: Wed, 05 Aug 2015 18:36:34 +1000 Message-Id: <20150805083634.4CF0C3429549@rock.dv.isc.org> Archived-At: Cc: v6ops list , "behave@ietf.org" Subject: Re: [v6ops] protocols without need for ALG ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Aug 2015 08:36:44 -0000 In message <55BC16EB.8060007@isi.edu>, Joe Touch writes: > Hi, Mark, > > On 7/31/2015 4:45 PM, Mark Smith wrote: > > On 31 July 2015 at 23:21, Joe Touch wrote: > >> TFTP servers are typically reached at UDP port 69. > >> > >> It does not use ports or addresses in-band and thus should not need an ALG. > > > > Hmm, to my mind, an "ALG" is necessary if something about the protocol > > needs to be understood e.g., look for/change in-band ports or > > addresses, and possibly set up corresponding state or temporary access > > list/firewall permissions for related traffic. > > > > In the case of TFTP, it is the "TID"s: > > > > "The transfer identifiers (TID's) used by > > TFTP are passed to the Datagram layer to be used as ports; therefore > > they must be between 0 and 65,535. The initialization of TID's is > > discussed in the section on initial connection protocol." > > > > " A > > requesting host chooses its source TID as described above, and sends > > its initial request to the known TID 69 decimal (105 octal) on the > > serving host. The response to the request, under normal operation, > > uses a TID chosen by the server as its source TID and the TID chosen > > for the previous message by the requestor as its destination TID. > > The two chosen TID's are then used for the remainder of the transfer." > > Ahh, right - I forgot that TFTP doesn't stick to the same UDP port pair. > It works a bit like FTP in that it "hands off" the transfer to the > server port indicated by the server-side TID after the initial request. > > > I think a server could choose to continue to use 69 as its TID for the > > full transfer, however in my case it didn't. > > It never will. The first packet is supposed to have a destination TID of > 69 but the rest of the session uses TIDs chosen by each end. > > client sends sTID=X, dTID=69 on UDP sPORT=X dPORT=69 > > server replies with sTID=Y, dTID=X on UDP sPORT=Y dPORT=X, > which is where the rest of the transfer stays until a new TID > is selected. > > > I still remember it today > > because I was only able to get around the unpredictable TID selection > > on both ends by using just host IP addresses, which had some risks > > because it was a very coarse way of selecting "interesting" > > dial-on-demand traffic to hold the link up. > > I'm not sure what you were doing; "using just host IP addresses" doesn't > fix the issue because TFTP still wants to pick TIDs, and the UDP ports > vary when the TIDs do. > > > So if in Toerless's scenario it is stateless 1:1 translation between > > IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. > > However, if the translation is stateful because translation between > > IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a > > mapping of some form. > > So first let me backtrack - TFTP requires an ALG to work through a NAT > even when the client is on the private side. The return traffic content > needs to be inspected to be able to update the private:public > translation entry. > > I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an > ALG. I can't imagine how to make sense of it safely in a non-1:1 case. > > Note that the whole point of TFTP is to be used on a LAN only. It has > zero security, and it's easily possible that the translation entry could > inadvertently affect some other UDP translation entry. Actually it is to provide a *Trivial* File Transfer Protocol that works over UDP. If it was LAN only it would be LFTP. TFTP works fine over inter-continental links. Been there, done that. > Joe > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Aug 5 02:31: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 7D08A1B2E40 for ; Wed, 5 Aug 2015 02:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.91 X-Spam-Level: X-Spam-Status: No, score=-113.91 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, J_CHICKENPOX_74=0.6, 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 pwJhB3o4IKXR for ; Wed, 5 Aug 2015 02:31:29 -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 D53361B2E39 for ; Wed, 5 Aug 2015 02:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3484; q=dns/txt; s=iport; t=1438767088; x=1439976688; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OZi6/DUCBvQBwOvy9Q/zId+NehqIddkahitGwjLW4sw=; b=ID7TkpCiJ9lGZq/DuFT4B0ij6btGMYjfQhv7VaUZDCldsfCnSy3H4+pe 1Frks+wcQsc1XY90T5GPD1KbGfR0pV+0E4Ip6PivO4SdlyuJPLfUB4S+W hhJDOhqsCVv1Rk/UxqzEz9sAiapwFsjOgRg0Q6twOZYyjjk8Z0DA9+N/5 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BjAwBs18FV/5ldJa1bgk5NgT0GvHEJh30CgT44FAEBAQEBAQGBCoQjAQEBAwF5BQsCAQgEARMuMiUCBA4FDogYCMpKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tPhQgHgxiBFAEElH0BgjmBW4g/mV8mg31vgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,615,1432598400"; d="asc'?scan'208,217";a="175696545" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 05 Aug 2015 09:31:28 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t759VSaZ026632 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2015 09:31:28 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 5 Aug 2015 04:31:27 -0500 Received: from xhc-rcd-x11.cisco.com (173.37.183.85) by xch-rcd-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 5 Aug 2015 04:31:27 -0500 Received: from xmb-rcd-x09.cisco.com ([169.254.9.173]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0248.002; Wed, 5 Aug 2015 04:31:27 -0500 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AQHQz2GAVCXvIiHBekyI47eTl5Er2g== Date: Wed, 5 Aug 2015 09:31:26 +0000 Message-ID: <134E3A1A-CC0D-4129-A0D8-0C5C3179E6C5@cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.16] Content-Type: multipart/signed; boundary="Apple-Mail=_12CABB1B-2B61-428F-8335-53750C7A8C6F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Aug 2015 09:31:30 -0000 --Apple-Mail=_12CABB1B-2B61-428F-8335-53750C7A8C6F Content-Type: multipart/alternative; boundary="Apple-Mail=_A5FE6A86-AF4E-4663-B962-E29462251AC1" --Apple-Mail=_A5FE6A86-AF4E-4663-B962-E29462251AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 5, 2015, at 1:13 AM, Lorenzo Colitti = wrote: >=20 > Unfortunately NAT66 *is* a credible alternative, and implementations = definitely do exist. I know for sure that Juniper ships a fully-stateful = NAT implementation on the SRX (and I don't mean NPTv6, I mean = fully-stateful NAT44-style address+port NAT), and I think I heard that = Cisco does too. We actually have a couple of implementations, in the ASA firewall = product, and the ASR. --Apple-Mail=_A5FE6A86-AF4E-4663-B962-E29462251AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Aug 5, 2015, at 1:13 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:

Unfortunately NAT66 = *is* a credible alternative, and implementations definitely do exist. I = know for sure that Juniper ships a fully-stateful NAT implementation on = the SRX (and I don't mean NPTv6, I mean fully-stateful NAT44-style = address+port NAT), and I think I heard that Cisco does = too.

We actually have = a couple of implementations, in the ASA firewall product, and the = ASR.
= --Apple-Mail=_A5FE6A86-AF4E-4663-B962-E29462251AC1-- --Apple-Mail=_12CABB1B-2B61-428F-8335-53750C7A8C6F 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 iQIVAwUBVcHX7kayAOS/EQ8MAQJEaQ//SZBr5mPnQFYeiAnkNbK6m//iZOv1NeEw +tV7K3JWKK9MKld2+fLrOyFQteBOZbEe7/ucgmyeipJXGTOWa65jFIJmTVbvfywH e9V48v/fJzezkotlOmgWX+9Rx8VuktjIpTw6voq7uQDolQYFW3EHBHtwGjyAxB4/ yYTxGbUX1yml61cFQhrEa8UJuzUnF8rjf6fHGyEqmh7Eqo5fILk4CPUJCUB7hwQD BnFnYXwg/Kg00ebnHgc8o6KPN3UfeaW4COU6GtBs+hMQLOesWq7nOAMxGNJzTznO AYT3obA9rdiAR258gElmmRae9SztbStx01vEdRX+awq07cFqo6EE+elmbeRYU7yv M2PteQDNTifsr07btkiQ7ZDB5KsorVRL0yl9DAc6vSSl3zTFQyuGQtNU92vJQbcu gXBL706E+0CXO9clujth1+45qVEGA3BfYci6WHNt+ejSW1SOqtRGxTnKHZfzL1Ho pp9OM5rxYCNOp1ZM8nw9oYKKrgUkxsFFjfXWG4G0poS0lMJy6CJxr///ZLcQAuoI sSmilnL7F/ApYO7zlfxboGBbkjhoVBRQiUpaFmCHnFCib4JnEHUBiKSVSQhzn8ky wKUe2kCrIPPxeJwYtgf3l7R932WHya3sbTrR5pI3L21NeEUk8fgQ506S08rYcES9 +G+fiI7vtJI= =1W5r -----END PGP SIGNATURE----- --Apple-Mail=_12CABB1B-2B61-428F-8335-53750C7A8C6F-- From nobody Wed Aug 5 09:59: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 0A9821A854D; Wed, 5 Aug 2015 09:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, 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 EiVs-PTwLqus; Wed, 5 Aug 2015 09:59:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4FC1A6FE7; Wed, 5 Aug 2015 09:59:19 -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 t75GvHDp022626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Aug 2015 09:57:19 -0700 (PDT) To: Mark Andrews References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> <55BC16EB.8060007@isi.edu> <20150805083634.4CF0C3429549@rock.dv.isc.org> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55C2406D.8000706@isi.edu> Date: Wed, 5 Aug 2015 09:57:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150805083634.4CF0C3429549@rock.dv.isc.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: Cc: v6ops list , "behave@ietf.org" Subject: Re: [v6ops] protocols without need for ALG ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Aug 2015 16:59:21 -0000 On 8/5/2015 1:36 AM, Mark Andrews wrote: > In message <55BC16EB.8060007@isi.edu>, Joe Touch writes: >> Hi, Mark, >> >> On 7/31/2015 4:45 PM, Mark Smith wrote: >>> On 31 July 2015 at 23:21, Joe Touch wrote: >>>> TFTP servers are typically reached at UDP port 69. >>>> >>>> It does not use ports or addresses in-band and thus should not need an ALG. >>> >>> Hmm, to my mind, an "ALG" is necessary if something about the protocol >>> needs to be understood e.g., look for/change in-band ports or >>> addresses, and possibly set up corresponding state or temporary access >>> list/firewall permissions for related traffic. >>> >>> In the case of TFTP, it is the "TID"s: >>> >>> "The transfer identifiers (TID's) used by >>> TFTP are passed to the Datagram layer to be used as ports; therefore >>> they must be between 0 and 65,535. The initialization of TID's is >>> discussed in the section on initial connection protocol." >>> >>> " A >>> requesting host chooses its source TID as described above, and sends >>> its initial request to the known TID 69 decimal (105 octal) on the >>> serving host. The response to the request, under normal operation, >>> uses a TID chosen by the server as its source TID and the TID chosen >>> for the previous message by the requestor as its destination TID. >>> The two chosen TID's are then used for the remainder of the transfer." >> >> Ahh, right - I forgot that TFTP doesn't stick to the same UDP port pair. >> It works a bit like FTP in that it "hands off" the transfer to the >> server port indicated by the server-side TID after the initial request. >> >>> I think a server could choose to continue to use 69 as its TID for the >>> full transfer, however in my case it didn't. >> >> It never will. The first packet is supposed to have a destination TID of >> 69 but the rest of the session uses TIDs chosen by each end. >> >> client sends sTID=X, dTID=69 on UDP sPORT=X dPORT=69 >> >> server replies with sTID=Y, dTID=X on UDP sPORT=Y dPORT=X, >> which is where the rest of the transfer stays until a new TID >> is selected. >> >>> I still remember it today >>> because I was only able to get around the unpredictable TID selection >>> on both ends by using just host IP addresses, which had some risks >>> because it was a very coarse way of selecting "interesting" >>> dial-on-demand traffic to hold the link up. >> >> I'm not sure what you were doing; "using just host IP addresses" doesn't >> fix the issue because TFTP still wants to pick TIDs, and the UDP ports >> vary when the TIDs do. >> >>> So if in Toerless's scenario it is stateless 1:1 translation between >>> IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. >>> However, if the translation is stateful because translation between >>> IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a >>> mapping of some form. >> >> So first let me backtrack - TFTP requires an ALG to work through a NAT >> even when the client is on the private side. The return traffic content >> needs to be inspected to be able to update the private:public >> translation entry. >> >> I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an >> ALG. I can't imagine how to make sense of it safely in a non-1:1 case. >> >> Note that the whole point of TFTP is to be used on a LAN only. It has >> zero security, and it's easily possible that the translation entry could >> inadvertently affect some other UDP translation entry. > > Actually it is to provide a *Trivial* File Transfer Protocol that > works over UDP. If it was LAN only it would be LFTP. TFTP works > fine over inter-continental links. Been there, done that. It *can* work anywhere, but its lack of security and congestion control are good reasons not to use it outside protected environments. Further, it was "trivial" back when TCP was thought to be comparatively huge; reasonable implementations of TCP are very small and memory isn't anywhere near as limited. Joe From nobody Wed Aug 5 16:56: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 A81211B34F2; Wed, 5 Aug 2015 16:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Lh6aDgC_CC; Wed, 5 Aug 2015 16:56:43 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219751B34F5; Wed, 5 Aug 2015 16:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9077; q=dns/txt; s=iport; t=1438819002; x=1440028602; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=yLfmpw+YNfKgYjpckg3UJ+aOtB1uxNDVzNrH+Y8VZk8=; b=lKq1bJ0Ama6trs3SG2qSHyUCC16C++NPgmfJL/8xFFnP+GYqXHJjVE51 GDUnrtn1M1XCKtM1BwnJTvha7SnvuWCyvNUrvOC/pj3J13V/KVd4gfhEO nEmfi58PbyoBG33n/tydENHNNJKh4oYHwTUKE6DDAWt5hBaEkm8CV6fMY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CiBAC9oMJV/xbLJq1bg29pgyO7a4V3AoIeAQEBAQEBgQuEJAEBBCMEPhMBEAkjFgsCAgkDAgECAUUTCAEBiCoNmTedG5ZOAQEBAQEBAQMBAQEBAQEBFwSQDUsHgmmBQwEElH+Ef4JkhHOBR4cVIo0Eg2Qmg388MQEBgkoBAQE X-IronPort-AV: E=Sophos;i="5.15,620,1432598400"; d="scan'208,217";a="592403467" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 05 Aug 2015 23:56:40 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t75Nudfn022723; Wed, 5 Aug 2015 23:56:40 GMT References: <55C20D5A.6070409@cisco.com> To: draft-ietf-v6ops-pmtud-ecmp-problem@ietf.org From: Benoit Claise X-Forwarded-Message-Id: <55C20D5A.6070409@cisco.com> Message-ID: <55C2A2B7.3050304@cisco.com> Date: Thu, 6 Aug 2015 01:56:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55C20D5A.6070409@cisco.com> Content-Type: multipart/alternative; boundary="------------010809040108040203080701" Archived-At: Cc: "" Subject: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem-03: AD review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Aug 2015 23:56:45 -0000 This is a multi-part message in MIME format. --------------010809040108040203080701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Joel, being a document author, asked me to look into this draft Here is my feedback. I don't have any background on this draft. So a fresh pair of eyes. 1. It took me a little bit of time to grasp the problem behind this draft. From the abstract, I(wrongly) assumed a PTB packet sent from the server back to the source. It's only in section 2 that I found my answer (well, the second time I read it) An ICMPv6 type 2 PTB message generated on an intermediate device_for a packet sent from a server_ And the figure 1 was not too helpful, as, obviously I was wondering about the ptb direction... What would have made it crystal-clear is a figure 1 such as: Topology client -...-- router -- load balancer 1 --- server 1 \\-- load balancer 2 --- server 2 \-- load balancer N --- server N Sequence 1: packet from source to server client -> ... -> router ecmp -> nexthop L4/L7 load balancer -> server (*) Sequence 2: reply from server to source .... <- router ecmp <- nexthop L4/L7 load balancer <- server (*) Sequence 3: ptb sent back to the server ptb -> router ecmp -> nexthop L4/L7 load balancer -> server (**) Note: As (*) and (**) are unlikely the same instance, so the ptb could be mis-delivered 2. Confused about the order 3 . Mitigation . . . . . . . . . . . . . . . . . . . . . . . . .4 3.1 . Alternatives . . . . . . . . . . . . . . . . . . . . . .5 3.2 . Implementation . . . . . . . . . . . . . . . . . . . . .5 3.2.1 . Alternatives . . . . . . . . . . . . . . . . . . . .6 3.2 is the implementation of what? The intro in section 3? So why do you insert alternatives 3.1 (which you don't recommend) in between? And 3.2.1 is the alternative to what? the implementation in section 3.2 3. 1. Filter-based-forwarding matches next-header ICMPv6 type-2 and matches a next-hop on a particular subnet directly attached to both border routers. The filter is policed to reasonable limits (we chose 1000pps, more conservative rates might be required in other implementations). border router? make it consistent with the terminology in figure 1 2. Filter is applied on input side of all external interfaces Make it clear that you speak about router in figure 1 4. Anycast servers receive the PTB error and process packet as needed. "anycast server" make it consistent with the terminology is figure 1 4. Section 3.2.1 "ECMP hop could distribute the proxy onto the end systems" Not sure what it means. 5. section 4. Improvements to what? The implementation or the potential specification. I guess the "specification", but then, how is this different that the mitigation section? Your improvement point 1 is the same as the "mitigation" section paragraph 1 Your improvement point 2 is the same as the "mitigation" section paragraph 2 nits: implmentation -> implementation Regards, Benoit --------------010809040108040203080701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Joel, being a document author, asked me to look into this draft
Here is my feedback. I don't have any background on this draft. So a fresh pair of eyes.

1. It took me a little bit of time to grasp the problem behind this draft.
From the abstract, I(wrongly) assumed a PTB packet sent from the server back to the source.
It's only in section 2 that I found my answer (well, the second time I read it)
  An ICMPv6 type 2 PTB message generated
   on an intermediate device for a packet sent from a server
And the figure 1 was not too helpful, as, obviously I was wondering about the ptb direction...

What would have made it crystal-clear is a figure 1 such as:

   Topology
   client -...-- router -- load balancer 1 --- server 1
                      \\-- load balancer 2 --- server 2
                       \-- load balancer N --- server N

    Sequence 1: packet from source to server
        client -> ... -> router ecmp -> nexthop L4/L7 load balancer  -> server (*)
   
    Sequence 2: reply from server to source
                     .... <- router ecmp <- nexthop L4/L7 load balancer  <- server (*)

    Sequence 3: ptb sent back to the server
                    ptb -> router ecmp -> nexthop L4/L7 load balancer -> server (**)

    Note: As (*) and (**) are unlikely the same instance, so the ptb could be mis-delivered


2.
Confused about the order
 3.  Mitigation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Alternatives  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Implementation  . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Alternatives  . . . . . . . . . . . . . . . . . . . .   6
 3.2 is the implementation of what? The intro in section 3?
So why do you insert alternatives 3.1 (which you don't recommend) in between?
And 3.2.1 is the alternative to what? the implementation in section 3.2


3.
    1. Filter-based-forwarding matches next-header ICMPv6 type-2 and
       matches a next-hop on a particular subnet directly attached to
       both border routers.  The filter is policed to reasonable limits
       (we chose 1000pps, more conservative rates might be required in
       other implementations).

border router? make it consistent with the terminology in figure 1

   2.  Filter is applied on input side of all external interfaces

Make it clear that you speak about router in figure 1

   4.  Anycast servers receive the PTB error and process packet as
       needed.

"anycast server" make it consistent with the terminology is figure 1


4.
Section 3.2.1 
"ECMP hop could distribute the proxy onto the end systems"
Not sure what it means.

 5.
section 4. Improvements to what? The implementation or the potential specification.
I guess the "specification", but then, how is this different that the mitigation section?
Your improvement point 1 is the same as the "mitigation" section paragraph 1
Your improvement point 2 is the same as the "mitigation" section paragraph 2


nits: 
implmentation -> implementation 

Regards, Benoit



--------------010809040108040203080701-- From nobody Thu Aug 6 08:53: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 BA4781B2E0E; Thu, 6 Aug 2015 08:53: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 ysdS9SDtHcys; Thu, 6 Aug 2015 08:53:15 -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 A89751B2CF6; Thu, 6 Aug 2015 08:53:15 -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 t76FrCYV087262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Aug 2015 15:53:12 GMT (envelope-from joelja@bogus.com) To: Benoit Claise , draft-ietf-v6ops-pmtud-ecmp-problem@ietf.org References: <55C20D5A.6070409@cisco.com> <55C2A2B7.3050304@cisco.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <55C382E1.8070406@bogus.com> Date: Thu, 6 Aug 2015 08:53:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: <55C2A2B7.3050304@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rxg0KjxnueOkx7mDXu9vMRhJVA6VERIxn" Archived-At: Cc: "" Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem-03: AD review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Aug 2015 15:53:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Rxg0KjxnueOkx7mDXu9vMRhJVA6VERIxn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/5/15 4:56 PM, Benoit Claise wrote: > Dear all, >=20 > Joel, being a document author, asked me to look into this draft > Here is my feedback. I don't have any background on this draft. So a > fresh pair of eyes. >=20 > 1. It took me a little bit of time to grasp the problem behind this dra= ft. > From the abstract, I(wrongly) assumed a PTB packet sent from the server= > back to the source. yup it's the one from the client. let me see if we can tweak this slightl= y. > It's only in section 2 that I found my answer (well, the second time I > read it) >=20 > An ICMPv6 type 2 PTB message generated > on an intermediate device _for a packet sent from a server_ >=20 > And the figure 1 was not too helpful, as, obviously I was wondering > about the ptb direction... figure 1 contains ptb -> router ecmp -> nexthop L4/L7 load balancer -> destination the limitations of ascii art may be a limitation here, but it's not really a state flow since it could be emitted by any device in the path. at any time. but I think if we address item 1 the problem of directionality is no doubt clear. > What would have made it crystal-clear is a figure 1 such as: >=20 > Topology >=20 > client -...-- router -- load balancer 1 --- server 1 > \\-- load balancer 2 --- server 2 > \-- load balancer N --- server N >=20 >=20 > Sequence 1: packet from source to server > client -> ... -> router ecmp -> nexthop L4/L7 load balancer ->= > server (*) > =20 > Sequence 2: reply from server to source > .... <- router ecmp <- nexthop L4/L7 load balancer= =20 > <- server (*) >=20 > Sequence 3: ptb sent back to the server > ptb -> router ecmp -> nexthop L4/L7 load balancer -= > > server (**) >=20 > Note: As (*) and (**) are unlikely the same instance, so the ptb > could be mis-delivered >=20 >=20 > 2. > Confused about the order >=20 > 3 > . Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . = 4 > > 3.1 > . Alternatives . . . . . . . . . . . . . . . . . . . . . . 5= > 3.1 can be changed to Alternative mitigations it's important that clamping the mss doesn't get lost in all if this because both the ietf considers that minimum best effort (everything has to carry 1280 right) and because people do it. > 3.2 > . Implementation . . . . . . . . . . . . . . . . . . . . . 5= > > 3.2.1 > . Alternatives . . . . . . . . . . . . . . . . . . . . 6 > >=20 > 3.2 is the implementation of what? The intro in section 3? 3.2 yes is an example mitigiation based on 3 paragraph 2 > So why do you insert alternatives 3.1 (which you don't recommend) in > between? > And 3.2.1 is the alternative to what? the implementation in section 3.2= 3.2.1 yes. the point being there's more than one way to solve the problem. operationally one approach may be more desirable the the other, in point of fact when I asked the cloudflare guys came up with their's so I added it. > > 3. >=20 > 1. Filter-based-forwarding matches next-header ICMPv6 type-2 and > matches a next-hop on a particular subnet directly attached to > both border routers. The filter is policed to reasonable limits= > (we chose 1000pps, more conservative rates might be required in > other implementations). >=20 > border router? make it consistent with the terminology in figure 1 ok routers > 2. Filter is applied on input side of all external interfaces >=20 > Make it clear that you speak about router in figure 1 external routers > 4. Anycast servers receive the PTB error and process packet as > needed. >=20 > "anycast server" make it consistent with the terminology is figure 1 figure 1 is bounded by width limitations for ascii art otherwise the label would be longer, the fact that it is naycast is brought up in section 2. we can probably arrange to us server more freely in the text prior to this. >=20 > 4. > Section 3.2.1=20 > "ECMP hop could distribute the proxy onto the end systems" Alternatively, network designs in which a common layer 2 network exists on the ECMP hop could distribute the proxy onto the end systems, eliminating the need for policy routing. Proxy in this case refers to the mitigiation proposed in section 3 paragraph 2 of which this is a sub section. The excerpt is missing a preposition ( exists on the ECMP hop) and I agree it's hard to parse without that. > Not sure what it means. >=20 > 5. > section 4. Improvements to what? The implementation or the potential sp= ecification. These are improvements on the mitigation. they are not specification changes rfc 4821 already exists it's just not widely (at all afaik) used.= > I guess the "specification", but then, how is this different that the m= itigation section? > Your improvement point 1 is the same as the "mitigation" section paragr= aph 1 Right but no asic or at least microcode exists today can actually do that= =2E > Your improvement point 2 is the same as the "mitigation" section paragr= aph 2 no it isn't. in the mitigitation it was necessary to build a proxy to flood them by rewritting the L2 nexthop. that's rather different than getting router to forward a unicast packet to say 16 destinations if somebody gives me a knob for the latter then all this proxy junk is done.= >=20 > nits:=20 > implmentation -> implementation=20 >=20 > Regards, Benoit >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Rxg0KjxnueOkx7mDXu9vMRhJVA6VERIxn 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 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXDguIACgkQ8AA1q7Z/VrKDqwCffaj6gO0jY3w/su1sgiUWG9MX SDgAnjzSHhQf4ojFMENx8Oq47FeGJMuu =pgQC -----END PGP SIGNATURE----- --Rxg0KjxnueOkx7mDXu9vMRhJVA6VERIxn-- From nobody Thu Aug 6 10:46: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 E7E6E1ACF08 for ; Tue, 4 Aug 2015 14:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_BACKHAIR_37=1, 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 IOkfUCQnw--s for ; Tue, 4 Aug 2015 14:58:22 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4131ACF16 for ; Tue, 4 Aug 2015 14:58:19 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-05v.sys.comcast.net with comcast id 0lxx1r00D4tLnxL01lyKwl; Tue, 04 Aug 2015 21:58:19 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-po-02v.sys.comcast.net with comcast id 0lyJ1r00B2yZEBF01lyJLG; Tue, 04 Aug 2015 21:58:19 +0000 From: "ietfdbh" To: "'Toerless Eckert'" , , References: <20150730205806.GI1667@cisco.com> In-Reply-To: <20150730205806.GI1667@cisco.com> Date: Tue, 4 Aug 2015 17:58:17 -0400 Message-ID: <006d01d0cf00$ac05b830$04112890$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOIOzxA//lU3Ej5GL/YVhvfDRm9p0Bvn7A Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1438725499; bh=Hum09xIitN2sp1vBiPjV/9XECw4jqMZOSXH/TMxJ2KQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=nvUAKd0CMH51ezG6mSMKXJWn/U30YviPVeMan51+U+h661RAI2E+kGY1IXZ46Co3n DOpkSsMaR/cJvqYb3OIPFkagvk9d5Whqj8lQZtPcqlqpTURCxe2KcRQ7O8CgSw2UK0 W7Q3lFvK8EnKWtHeHDN/IkJC5b47QWNVZFIY38unmRgFLqyUiOvMn/DHm8Rr5akn3/ C1CVi5XthMT9QP1q3TNB0FmpjLR3QyvCCRSjAqKynJGIlezOJpO0eX24cQJnJC7Jhm EZsGza9Ls8I0PSXTH/5FDxdu7Qv1yVrHjiCmBL+Gfq4nJA6sq2DgVM8IjwL47OpRNi JiU2jjyQqcw1A== Archived-At: X-Mailman-Approved-At: Thu, 06 Aug 2015 10:46:16 -0700 Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Aug 2015 21:58:23 -0000 RFC2962 includes a detailed description of the requirements and limitations for an implementation of an SNMP Application Level Gateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Behave [mailto:behave-bounces@ietf.org] On Behalf Of Toerless > Eckert > Sent: Thursday, July 30, 2015 4:58 PM > To: v6ops@ietf.org; behave@ietf.org > Subject: [BEHAVE] protocols without need for ALG ? > > For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 > for initial > autonomic connectivity, and the question of connecting this (at least initially) > to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems > to be still > weak on a range of commonly used NOC tools. > > If i understand the NAT RFCs and behave output correctly, we primaerily > want ALGs to go the way of the dodo, so i was wondering if there might be > any crucial protocols between typical NOC equipment and network devices > that > would require ALGs. And better of course:knowing which protocols would be > fine > without ALG. > > Are there any lists about this (eg: what requires ALG ?) > > Wrt to what seems to be important between NOC and network devices: > > FTP - NOK (requires ALG) - IMHO not a problem > traceroute - ?? (initiated from v4 NOC) ?? > telnet - OK > ping - OK ? > SSH/SCP - OK > syslog - OK > TFTP - OK ? > radius - OK ? (i ran some tests, seemed to be fine) > diameter/tacacs+ - OK ? > NTP - OK ??? > > For the following, that have extensible data-models (MIBs/OIDs, XML > schema etc.), > i can see that some NOC tools relying on them might not support data- > models > with IPv6, but that would be "fine" (aka: can't manage everything from such > tools, > but transport stack works): > > netconf - OK ? > SNMP - OK ? > > Whats the next most important NOC<->network management protocols... ? > > Thanks! > Toerless > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Sun Aug 9 11:00:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23801AD49D for ; Sun, 9 Aug 2015 11:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.111 X-Spam-Level: X-Spam-Status: No, score=-113.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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 rDZl5EiJIBU7 for ; Sun, 9 Aug 2015 11:00:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A93C1AD369 for ; Sun, 9 Aug 2015 11:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=627; q=dns/txt; s=iport; t=1439143207; x=1440352807; h=date:from:message-id:to:subject:cc; bh=85GuhqFgKyVc2dEIBXun554QHcjdwzjCMQYc6+IK1zE=; b=M7kSVVozIBmEq2zT2SO3SgjNGb2kFtPXJJcgDDZGFffa0Dq/Kx4+e9sG gKnSGpFGXPKEmzCue7mwmoaQjrDGJYXGWXfWvOf4zwQQlM+g4Rk6r9KFg ZmiFVolfI7s31Q4l+7psiFFkcbdeCjpZmJn8c4x78E8WVoT1YRYeSAFE0 k=; X-IronPort-AV: E=Sophos;i="5.15,640,1432598400"; d="scan'208";a="22736790" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 09 Aug 2015 18:00:06 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t79I05Nu013641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2015 18:00:05 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t79I04cw018075; Sun, 9 Aug 2015 11:00:05 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t79I03pI018073; Sun, 9 Aug 2015 11:00:03 -0700 Date: Sun, 9 Aug 2015 11:00:03 -0700 From: fred@cisco.com Message-Id: <201508091800.t79I03pI018073@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-siit-dc-2xlat 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, 09 Aug 2015 18:00:09 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-2xlat. 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 Aug 10 10:59:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52EE1B2D45; Mon, 10 Aug 2015 10:59:07 -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 G9WqWRAwTU8l; Mon, 10 Aug 2015 10:59:06 -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 EEF221B2AD3; Mon, 10 Aug 2015 10:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2272; q=dns/txt; s=iport; t=1439229545; x=1440439145; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HBmnTs9/QwQEGbOEoit8bHHo9iJdGarui+yKVx00Mlw=; b=Y6UYvW05VbFOSkGGIA/i80ojMOKrAi/5UAQ5MS+WMalT9n5U0ZTtoNyv dak2UuaVuKnNYWUR1hWfS8G4a4ckqxiIRG8OBJOq9SeQosIqig7Dm0+Uk QY0xwpKR5zzdGPKmiU7q9yxFmv5jtn9cOKYcvFzgRKq0HnRkNNX9EImE3 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApAwDG5chV/4wNJK1dgxuBPQa9MQmHfgKBNTgUAQEBAQEBAYEKhCMBAQEDAXkFCwIBCBguMiUCBA4FDogYCM9cAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tRhQkHgxiBFAEEhxyFOYg2AYI8gVyISoFJhCWJBIsLJoN+cYFIgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="asc'?scan'208";a="17438303" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2015 17:59:05 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t7AHx5H1011853 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2015 17:59:05 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 10 Aug 2015 12:59:04 -0500 Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-aln-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 10 Aug 2015 12:59:04 -0500 Received: from xmb-rcd-x09.cisco.com ([169.254.9.173]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Mon, 10 Aug 2015 12:59:03 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: v6ops - New Meeting Session Request for IETF 94 Thread-Index: AQHQ05Y9HV+Rw0Sf4Ui0HZmXAiXoEQ== Date: Mon, 10 Aug 2015 17:59:03 +0000 Message-ID: <10E8DDCE-CA12-45A7-AC55-75B101089ACA@cisco.com> References: <20150810175332.8711.24717.idtracker@ietfa.amsl.com> In-Reply-To: <20150810175332.8711.24717.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.30] Content-Type: multipart/signed; boundary="Apple-Mail=_33134943-DD7B-4A8D-A08D-D9B322AC9735"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops-ads@ietf.org" Subject: Re: [v6ops] v6ops - New Meeting Session Request for IETF 94 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Aug 2015 17:59:08 -0000 --Apple-Mail=_33134943-DD7B-4A8D-A08D-D9B322AC9735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, I have requested meeting slots as follows at the next meeting. I = can change it if I need to - please advise. > On Aug 10, 2015, at 10:53 AM, IETF Meeting Session Request Tool = wrote: >=20 >=20 >=20 > A new meeting session request has just been submitted by Fred Baker, a = Chair of the v6ops working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker >=20 > Number of Sessions: 2 > Length of Session(s): 2 Hours, 2 Hours > Number of Attendees: 150 > Conflicts to Avoid: > First Priority: opsec softwire homenet pcp 6man aqm dclcrg sunset4 = tsvwg > Second Priority: tsvarea intarea mif lmap > Third Priority: rtgwg opsawg >=20 >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 --Apple-Mail=_33134943-DD7B-4A8D-A08D-D9B322AC9735 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 iQIVAwUBVcjmZkayAOS/EQ8MAQLtWRAAo+zAp6269vuZeZDMpCuQ0IMbvy7EcARI 5fximgywZ/3z1YjQjy8mHaa7Uj6g2mlh85kfA6YNpoLU4lEJ9AE1TKCxdfcGvo+X vlDQPjs41y8JA5DanTAyp6Hexajst3IetrZEC3iovaG5CGQggVCxTOND9wrvBEfj dprQGYqZzxNj0/nOAM6/FlVtRaev9y89WwOJLm2zCoyhhJWc7SzGqevMzGout61r OFVGqrY42iuCd1qSXwc/bUie4ltk+4CAYmDkhqcy/iG/NMBSrp5dj1tKv04u1nYk O5NF8AX4qQskfAKlnRus8nA1ZKc6suYqYXyWT/fnTg8M/FO6u2202mAhbE8oAswL KV9s2MBpq2mZpTLekS1YxHvI2bKWl6+ZlbqSXvtj63GVnJSuXJURzVScFBdTnRTn UvmiiW6kaqMIP5iffKMbzBUQqedHD9lHPR8WYbzYoXkxu8kGfx0cGShGlkxBsIUb c7urdBRXzvlkLH4Sr/Hu0JC+yRWT398qg3e/kyRgP8W+ymQsdkoSl5oXVRjc+XWx /j34HopsHEas64oV3qTZvt8IRg6BUvvxB/y46JH3Jlg8hmzwfOsNDxRBE6O5f+bi X+WOheHdKur/YaQQQ569guBnyX7DNurVQHReXhvTj0egxH/5JZN+0gn+3KU2QaVC NvCcvdQXXuE= =eI+C -----END PGP SIGNATURE----- --Apple-Mail=_33134943-DD7B-4A8D-A08D-D9B322AC9735-- From nobody Mon Aug 10 13:31: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 9FD7A1B3DD7; Mon, 10 Aug 2015 13:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.424 X-Spam-Level: * X-Spam-Status: No, score=1.424 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ueCJQb03wx9x; Mon, 10 Aug 2015 13:31:11 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5D43A1B3DB5; Mon, 10 Aug 2015 13:31:02 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,647,1432612800"; d="rtf'212?scan'212,208,212";a="926109999" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 10 Aug 2015 16:22:34 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 10 Aug 2015 16:30:57 -0400 From: "Howard, Lee" To: 'IPv6 Operations' Date: Mon, 10 Aug 2015 16:30:55 -0400 Thread-Topic: minutes from v6ops IETF93 Thread-Index: AdDTq3XfyytHVFRrQFKb3W0xU3q/AQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_D1EE823FBE734LeeHowardtwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "sunset4-chairs@ietf.org" Subject: [v6ops] minutes from v6ops IETF93 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Aug 2015 20:31:15 -0000 --_002_D1EE823FBE734LeeHowardtwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My co-chair pointed out that minutes had not been posted to the WG site. I uploaded them on July 25, and again on August 7 and again just now, and still do not see them posted. For your convenience, while I troubleshoot, I have attached them. 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. --_002_D1EE823FBE734LeeHowardtwcablecom_ Content-Type: text/rtf; name="v6ops-sunset4.rtf" Content-Description: v6ops-sunset4.rtf Content-Disposition: attachment; filename="v6ops-sunset4.rtf"; size=19635; creation-date="Mon, 10 Aug 2015 20:30:56 GMT"; modification-date="Mon, 10 Aug 2015 20:30:56 GMT" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcY29jb2FydGYxMzQ3XGNvY29hc3VicnRmNTcwCntcZm9u dHRibFxmMFxmbmlsXGZjaGFyc2V0MCBDYW1icmlhO30Ke1xjb2xvcnRibDtccmVkMjU1XGdyZWVu MjU1XGJsdWUyNTU7XHJlZDBcZ3JlZW4wXGJsdWUyNTU7XHJlZDBcZ3JlZW4wXGJsdWUyMzM7XHJl ZDI2XGdyZWVuMjZcYmx1ZTI2Owp9ClxtYXJnbDE0NDBcbWFyZ3IxNDQwXHZpZXd3MTQyMjBcdmll d2gxMjE4MFx2aWV3a2luZDAKXHBhcmRcdHg3MjBcdHgxNDQwXHR4MjE2MFx0eDI4ODBcdHgzNjAw XHR4NDMyMFx0eDUwNDBcdHg1NzYwXHR4NjQ4MFx0eDcyMDBcdHg3OTIwXHR4ODY0MFxwYXJkaXJu YXR1cmFsCgpcZjBcZnMyNCBcY2YwIElQdjZPcHMvU3Vuc2V0NCBKb2ludCBNZWV0aW5nIE1pbnV0 ZXMgZm9yIFR1ZXNkYXkgSnVseSAyMXN0XAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PVwK TWludXRlczogSmFzb24gV2VpbFwKSmFiYmVyOiBPbGUgVHJvYW5cClJlY29yZGluZyBhdCAge1xm aWVsZHtcKlxmbGRpbnN0e0hZUEVSTElOSyAiaHR0cDovL2lldGY5My5jb25mLm1lZXRlY2hvLmNv bS9pbmRleC5waHAvUmVjb3JkZWRfU2Vzc2lvbnMjVjZPUFMifX17XGZsZHJzbHQgXGNmMiBcdWwg XHVsYzMgaHR0cDovL2lldGY5My5jb25mLm1lZXRlY2hvLmNvbS9pbmRleC5waHAvUmVjb3JkZWRf U2Vzc2lvbnMjVjZPUFN9fVxjZjMgXHVsIFx1bGMzIFwKXHBhcmRcdHg3MjBcdHgxNDQwXHR4MjE2 MFx0eDI4ODBcdHgzNjAwXHR4NDMyMFx0eDUwNDBcdHg1NzYwXHR4NjQ4MFx0eDcyMDBcdHg3OTIw XHR4ODY0MFxwYXJkaXJuYXR1cmFsClxjZjAgXHVsbm9uZSBTbGlkZXMgYXQgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzkzL21hdGVyaWFscy5odG1sXApcCk9wZW5pbmcgcmVt YXJrcyBieSBGcmVkXApMb3RzIG9mIGRyYWZ0cyBzaG93ZWQgdXAgb24gSnVseSA2dGggd2hpY2gg aXMgYSBwcm9ibGVtIGJlY2F1c2UgdGhlcmUgaXMgYSBydWxlIHRoYXQgeW91IG5lZWQgdG8gZGlz Y3VzcyBvbiBtYWlsaW5nIGxpc3QgYmVmb3JlIHlvdSBjYW4gYmUgYWRkZWQgdG8gYWdlbmRhIC0g c28gc3VibWl0IGVhcmxpZXIgYW5kIGludHJvZHVjZSB5b3VyIGRyYWZ0IGlmIHlvdSB3YW50IHRv IGdldCBvbiB0aGUgYWdlbmRhXApcClxwYXJkXHR4NzIwXHR4MTQ0MFx0eDIxNjBcdHgyODgwXHR4 MzYwMFx0eDQzMjBcdHg1MDQwXHR4NTc2MFx0eDY0ODBcdHg3MjAwXHR4NzkyMFx0eDg2NDBccGFy ZGlybmF0dXJhbAoKXGIgXGNmMCBHYXAgQW5hbHlzaXMgZm9yIElQdjQgU3Vuc2V0IGRyYWZ0XApc cGFyZFxwYXJkZWZ0YWI3MjBccmk3MjAKClxiMCBcY2YwIEFkZGVkIGxlZ2FjeSBJUHY0LW9ubHkg QVBJcywgc29tZSBlZGl0b3JpYWwgY2hhbmdlc1wKSGF2ZW5cJzkydCBhZGRlZCBESENQNG82LCBm b3IgdjZvIGNsaWVudHMgcmVxdWlyaW5nIERIQ1AodjQpIGNvbmZpZ3VyYXRpb24gb3B0aW9ucy4g QmVjYXVzZSBpdFwnOTJzIG5vdCBhIGdlbmVyYWwtcHVycG9zZSB1c2U7IGNsaWVudCBtdXN0IHN1 cHBvcnQgREhDUDRvNi5cCklhbiBGYXJyZWxsOiBcJzkzeWV0XCc5ND8gXApQZW5nOiBObywgZG9u XCc5MnQgcGxhbiB0byBpbmNvcnBvcmF0ZVwKSWFuOiBUaGVyZVwnOTJzIGEgbWVjaGFuaXNtIHRv IGRvIGl0IG92ZXIgREhDUHY2LCBkb25cJzkydCBuZWVkIGl0IGluIHRoZSBkb2MuIFwKXHBhcmRc dHg3MjBcdHgxNDQwXHR4MjE2MFx0eDI4ODBcdHgzNjAwXHR4NDMyMFx0eDUwNDBcdHg1NzYwXHR4 NjQ4MFx0eDcyMDBcdHg3OTIwXHR4ODY0MFxwYXJkaXJuYXR1cmFsClxjZjAgIC1JYW5GIC0gdGhl cmUgaXMgYWxyZWFkeSB3YXlzIHRvIGRpc2FibGUgREhDUHY0XAogLW5lZWRzIGEgcmV2aWV3ZXIg b3IgdHdvIC0gbm8gdm9sdW50ZWVycyBpbiB0aGUgcm9vbVwKXApccGFyZFxwYXJkZWZ0YWI3MjBc cmk3MjAKXGNmMCBBbHNvIG5lZWQgbW9yZSByZXZpZXcgb2YgIHtcZmllbGR7XCpcZmxkaW5zdHtI WVBFUkxJTksgImh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXN1bnNldDQt bmF0NjQtcG9ydC1hbGxvY2F0aW9uIn19e1xmbGRyc2x0IApcYiBcY2YyIFx1bCBcdWxjMiBBbmFs eXNpcyBvZiBOQVQ2NCBQb3J0IEFsbG9jYXRpb24gTWV0aG9kcyBmb3IgU2hhcmVkIElQdjQgQWRk cmVzc2VzfX1cClxwYXJkXHR4NzIwXHR4MTQ0MFx0eDIxNjBcdHgyODgwXHR4MzYwMFx0eDQzMjBc dHg1MDQwXHR4NTc2MFx0eDY0ODBcdHg3MjAwXHR4NzkyMFx0eDg2NDBccGFyZGlybmF0dXJhbApc Y2YwIFwKXApccGFyZFx0eDcyMFx0eDE0NDBcdHgyMTYwXHR4Mjg4MFx0eDM2MDBcdHg0MzIwXHR4 NTA0MFx0eDU3NjBcdHg2NDgwXHR4NzIwMFx0eDc5MjBcdHg4NjQwXHBhcmRpcm5hdHVyYWwKClxi IFxjZjAgSVB2NiBEZXNpZ24gQ2hvaWNlcyBkcmFmdFwKXHBhcmRcdHg3MjBcdHgxNDQwXHR4MjE2 MFx0eDI4ODBcdHgzNjAwXHR4NDMyMFx0eDUwNDBcdHg1NzYwXHR4NjQ4MFx0eDcyMDBcdHg3OTIw XHR4ODY0MFxwYXJkaXJuYXR1cmFsCgpcYjAgXGNmMCBWaWN0b3IgcHJlc2VudGluZ1wKRGlkIFdH TEMsIGhhZCBjb21tZW50c1wKTW9yZSBjbGVhbnVwIHN0aWxsIG5lZWRlZC4gXAogT3ZlcnZpZXcg b2YgRGlmZnNcClE6IERvZXMgV0cgYWdyZWUgb24gaW5jbHVzaW9uIG9mIEVudGVycHJpc2UgYW5k L29yIEVJR1JQP1wKIEphbiBab3J6IC0geWVzIHRvIGVudGVycHJpc2UgaW5jbHVzaW9uIGFuZCBu byBjb21tZW50IG9uIEVJR1JQXAogQWxhaW4gRHVyYW5kIC0gd291bGQgYmUgZ29vZCB0byBoYXZl IGluZm8gb24gZW50ZXJwcmlzZSBidXQgbWF5IGJlIGJldHRlciB0byBoYXZlIHNlcGFyYXRlIGRv Y3VtZW50IGZvciB0aGF0IGluc3RlYWQgb2YgaW5jbHVkaW5nIGluIHRoaXMgZG9jXApccGFyZFxw YXJkZWZ0YWI3MjBccmk3MjAKXGNmMCBWaWN0b3IgS3VhcnNpbmdoOiBXZSB0cmllZCB0byBrZWVw IGl0IGhpZ2ggbGV2ZWwgc28gaXQgYXBwbGllcyB0byBib3RoLlwKQWxhaW46IFRha2UgaXQgb25l IGxldmVsIGRvd24sIHNvIGl0XCc5MmxsIGJlIG1vcmUgdXNlZnVsLlwKUTogU2hvdWxkIHdlIGlu Y2x1ZGUgZGlzY3Vzc2lvbiBvZiBOQVQgYW5kIE5QVHY2PyBTb21lIGhhZCBvYmplY3RlZCBvbiBs aXN0LlwKXHBhcmRcdHg3MjBcdHgxNDQwXHR4MjE2MFx0eDI4ODBcdHgzNjAwXHR4NDMyMFx0eDUw NDBcdHg1NzYwXHR4NjQ4MFx0eDcyMDBcdHg3OTIwXHR4ODY0MFxwYXJkaXJuYXR1cmFsClxjZjAg IEJyaWFuIENhcnBlbnRlciAtIFdlIHNob3VsZCBpbmNsdWRlIGRpc2N1c3Npb24uIEJ1dCB5b3Ug ZG9uXCc5MnQgcG9pbnQgb3V0IHRoYXQgVUxBIHVzdWFsbHkgcnVucyB3aXRoIEdVQSwgTlBUIGlz IG9kZCwgZXRjLiBSZXdyaXRlIFVMQSB0ZXh0IHBlciBoaXMgY29tbWVudHMgb24gbGlzdCBcCiBB bGFpbiAtIGtub3dzIE5BVCBpcyBjdXJzZWQgYnV0IE5BVHY2IGNvbWVzIHVwIGluIGV2ZXJ5IG9u ZSBvZiBoaXMgZGlzY3Vzc2lvbnMgd2l0aCB0aGUgZW50ZXJwcmlzZSBcCiBFcmlrIEtsaW5lIC0g d2hhdCBpcyB0aGUgc3RhdHVzIG9mIFVMQSBVc2FnZSBkb2N1bWVudCAtIGlmIG1vdmluZyBhbG9u ZyBjb3VsZCBiZSBwb2ludGVkIHRvIGZvciB0aGUgVUxBIHBvcnRpb24gb2YgdGhpcyBkcmFmdCAo VmljdG9yIC0gbmVlZCBzb21lIGRpc2N1c3Npb24gaW4gdGhpcyBkcmFmdClcCkZyZWQgQmFrZXIg LSBJdCBrZWVwcyBnZXR0aW5nIGZpbGlidXN0ZXJlZC5cCkVyaWsgLSBMZXRcJzkycyBicmluZyBp dCBiYWNrLlwKIExvcmVuem8gQ29saXR0aSAtIE5QVHY2IGFuZCBOQVQgYXJlIHByZXNlbnRlZCB0 b2dldGhlciBhbmQgdGhleSBhcmUgdmVyeSBkaWZmZXJlbnQgLSBtb3N0IGxhcmdlIGVudGVycHJp c2VzIGFyZSBub3QgZG9pbmcgTlBUdjYgKFZpY3RvciBhZ3JlZXMgZWRpdHMgbmVlZCB0byBiZSBt YWRlIHRoZXJlKVwKIEVyaWsgVnluY2tlIC0gYW4gRW50ZXJwcmlzZSBHdWlkZWxpbmVzIGRvY3Vt ZW50IGhhcyBiZWVuIHdyaXR0ZW4gZGVhbGluZyB3aXRoIHRoZXNlIGlzc3VlcyBcClRpbSBDaG93 biByZWl0ZXJhdGVzIEVyaWtcJzkycyBjb21tZW50XAogTGVlIC0gVGhlIFdHIHdvdWxkIGxpa2Ug dG8gaGVhciBmcm9tIEVudGVycHJpc2VzIGFib3V0IHRoZWlyIGRlcGxveW1lbnRzIFwKTG9yZW56 byAtIExpa2UgR29vZ2xlXCc5MnMgZW50ZXJwcmlzZT9cCiBKb2huIEJyem96b3dza2kgLSBDb21j YXN0IGNhbiBzaGFyZSB3aGF0IHRoZXkgZGlkIGlmIGludGVyZXN0ZWQgXAogVGltQyAtIHNvbWUg VW5pdmVyc2l0eSBjYW1wdXNlcyBtYXkgaGF2ZSBsb29rZWQgYXQgTlBUdjYuIE5vdCBtdWx0aW1v ZGUsIHRlbmQgdG8gdHJ1c3QgdGhlIE5SRU4uXApEaXNwb3NpdGlvbjogV2FpdCBmb3IgLTA5IGRy YWZ0LCB0aGVuIG5lZWQgc29tZSBnb29kIHJldmlld3MuXApccGFyZFxwYXJkZWZ0YWI3MjBccmk3 MjAKXGNmMCAgIENvbW1pdHRlZCByZXZpZXdlcnM6IFRpbSBDaG93biwgSmFuIFpvcnpcClxwYXJk XHR4NzIwXHR4MTQ0MFx0eDIxNjBcdHgyODgwXHR4MzYwMFx0eDQzMjBcdHg1MDQwXHR4NTc2MFx0 eDY0ODBcdHg3MjAwXHR4NzkyMFx0eDg2NDBccGFyZGlybmF0dXJhbApcY2YwIFwKXApccGFyZFx0 eDcyMFx0eDE0NDBcdHgyMTYwXHR4Mjg4MFx0eDM2MDBcdHg0MzIwXHR4NTA0MFx0eDU3NjBcdHg2 NDgwXHR4NzIwMFx0eDc5MjBcdHg4NjQwXHBhcmRpcm5hdHVyYWwKClxiIFxjZjAgdjZvcHMtc2lp dC1kYy9zaWl0LWRjLTJ4bGF0XApccGFyZFx0eDcyMFx0eDE0NDBcdHgyMTYwXHR4Mjg4MFx0eDM2 MDBcdHg0MzIwXHR4NTA0MFx0eDU3NjBcdHg2NDgwXHR4NzIwMFx0eDc5MjBcdHg4NjQwXHBhcmRp cm5hdHVyYWwKClxiMCBcY2YwIFRvcmUgcHJlc2VudGluZ1wKXHBhcmRccGFyZGVmdGFiNzIwXHJp NzIwClxjZjAgRG9jdW1lbnRzIHJlZmVyIHRvIGRlcHJlY2F0ZS1hdG9taWMtZnJhZ21lbnRzLCB3 aGljaCBoYXMgYmVlbiBtb3ZlZCB0byByZmM2MTQ1LWJpcywgc28gSSBuZWVkIHRvIHVwZGF0ZSB0 aGUgZG9jcy5cClxwYXJkXHR4NzIwXHR4MTQ0MFx0eDIxNjBcdHgyODgwXHR4MzYwMFx0eDQzMjBc dHg1MDQwXHR4NTc2MFx0eDY0ODBcdHg3MjAwXHR4NzkyMFx0eDg2NDBccGFyZGlybmF0dXJhbApc Y2YwICBUaW1DIC0gZ29vZCB3b3JrIGFuZCB0aGFua3MgZm9yIHByZXNlbnRpbmdcCiBUdXZvPyBm cm9tIENodW5naHdhIFRlbGVjb20gLSB2aXJ0dWFsIG1hY2hpbmUgcXVlc3Rpb24gb24gcm91dGlu ZyAtIG5vIHNwZWNpYWwgY29uc2lkZXJhdGlvbiBuZWVkZWQgLSBzaG91bGQgYmUgY29uc2lzdGVu dCB3aXRoIHZpcnR1YWxpemVkIGRhdGFjZW50ZXIgYXJjaGl0ZWN0dXJlIC0gcHJlc2VudGVyIG5v dCBzdXJlIHdoYXQgdGhlIHByb2JsZW0gaXMgdGhlcmVcCiAgSkpCIC0gbG9va2luZyBhdCB0aGlz IGZvciB0aGVpciBkYXRhY2VudGVycyAtIFdlXCc5MnJlIHRyeWluZyB0byBtYWtlIHN1cmUgd2Ug ZG9uXCc5MnQgcmVxdWlyZSBwcm92aXNpb25pbmcgSVB2NCBhZGRyZXNzZXMuICAgd291bGQgbGlr ZSB0byBzZWUgdGhpcyBnbyBpbiB0aGUgZGlyZWN0aW9uIG9mIE9wZW5TdGFjayAtIGFncmVlcyB0 aGlzIGlzIHVzZWZ1bCB3b3JrIFwKIEZyZWQgLSBnb2luZyB0byBzdGFydCBXR0xDIG9uIGF0IGxl YXN0IG9uZSBvZiB0aGVzZSBvbiBTdW5kYXksIDItd2VlayBXR0xDIG9uIG9uZSBmb2xsb3dlZCBi eSAyLXdlZWsgV0dMQyBvbiB0aGUgb3RoZXIuXApcClxwYXJkXHR4NzIwXHR4MTQ0MFx0eDIxNjBc dHgyODgwXHR4MzYwMFx0eDQzMjBcdHg1MDQwXHR4NTc2MFx0eDY0ODBcdHg3MjAwXHR4NzkyMFx0 eDg2NDBccGFyZGlybmF0dXJhbAoKXGIgXGNmMCBJUHY2LU9ubHkgZm9yIFdpcmVkIFRoaW4tQ2xp ZW50cyBcClxwYXJkXHR4NzIwXHR4MTQ0MFx0eDIxNjBcdHgyODgwXHR4MzYwMFx0eDQzMjBcdHg1 MDQwXHR4NTc2MFx0eDY0ODBcdHg3MjAwXHR4NzkyMFx0eDg2NDBccGFyZGlybmF0dXJhbAoKXGIw IFxjZjAgRXJpayBWeW5rZSBwcmVzZW50aW5nXAogZW50ZXJwcmlzZSBkZXNrdG9wIGlzc3VlcyB3 aGVuIHRyeWluZyB0byBkZXBsb3kgd2l0aCB2Ni1vbmx5IFwKIC1XYWtlLU9uIExBTiAtIHVzZXMg bWFnaWMgZXRoZXIgdHlwZSBwYWNrZXQgXAogLU9uZSB3YXkgaW4gSVB2NiBpcyB0byBzZW5kIGEg Z2xvYmFsIElQdjYgYWRkeSBzdGF0aWNhbGx5IG1hcHBlZCB0byBmZi1mZi1mZlwnODVcCiBBbGV4 IFBldHJlc2N1IC0gbWFueSBzb2x1dGlvbnMgLSBzb21lIG9ubHkgRXRoZXJuZXQgb3RoZXJzIElQ IC0gd2hhdCBzb2x1dGlvbiBkbyB5b3UgbmVlZD8gZHJhd2JhY2tzIHNvbWUgY2FyZHMgZG9uXCc5 MnQgc3VwcG9ydCB0aGUgZmZmZlwnODVcCiBFcmlrIC0gb3BlblwKIERhdmUgVGhhbGVyIC0gRGVm YXVsdCB3YXMgY2hhbmdlZCBpbiBJUHY0LCBhcyB5b3Ugc2FpZCwgZm9yIHNlY3VyaXR5IHJlYXNv bnMsIHNvIGxldFwnOTJzIG5vdCB0cnkgdG8gY3JlYXRlIGl0IGZvciBJUHY2LiBJbiBNUyBlbnRl cnByaXNlLCBldmVuIHdoZW4gdGhlIG1hY2hpbmUgaXMgYXNsZWVwLCB0aGUgY2FyZCBzdGF5cyBh d2FrZSwgaXMgcmVzcG9uc2libGUgdG8gbG9vayBmb3IgQVJQL05ELiBUaGF0XCc5MnMgZW5vdWdo IHRvIGdldCBtYWdpYyBwYWNrZXQgdG8gd29yay4gXCc5M05EIG9mZmxvYWQuXCc5NCBXaWRlbHkg aW1wbGVtZW50ZWRcJzk3YWxsIGNhcmRzIGluc3RhbGxlZCBpbiBtYWNoaW5lcyB3aXRoIFdpbmRv d3MgcHJlLWluc3RhbGxlZCBzaW5jZSBXaW43IHN1cHBvcnQgdGhpcy4gLSBpZiB5b3UgY2FuIGdl dCBjYXJkIHRvIHJlc3BvbmQgdG8gYXJwIGFuZCBORCB0aGVuIG11Y2ggYmV0dGVyIHNvbHV0aW9u IChORCBPZmZsb2FkIHNlZW1zIHRvIGJlIGZhaXJseSB3ZWxsIGltcGxlbWVudGVkIHBlciBEYXZl KVwKLUxvcmVuem8gLSBob3cgZG9lcyB0aGlzIGdldCBhZHZlcnRpc2VkIC0gRXJpayAtIHBlciBW TEFOXAotQmFyYmFyYSAtIHNvbHV0aW9uIGZvciBpbiB0aGUgaG9tZSBtYXkgYmUgbXVjaCBkaWZm ZXJlbnQgLSBuZWVkZWQgZm9yIHBvd2VyIHNhdmluZyBkZXZpY2VzIGJ1dCBpbnRlcmVzdGluZyBw cm9ibGVtIFwKLUJlbmVkaWt0IFMgLSBjb3VsZCBhbHNvIGRvIHdpdGggYSByYXNwYmVycnkgcGlc CiAtU3R1YXJ0IENoZXNoaXJlIC0gQm9uam91ciBTbGVlcCBQcm94eSBkb2VzIHNvbWV0aGluZyBz aW1pbGFyIGNpcmNhIDIwMDkgLSBOSUMgbGlzdGVucyB0byBORCBhbmQgQVJQIGFuZCBsb29rcyBm b3IgbWFnaWMgcGFja2V0XAogLVN0aWcgVmVuYWFzIC0gbXVsdGljYXN0IGNvdWxkIGJlIHVzZWQg YnV0IGNvdWxkIGJlIHNvbWUgc2VjdXJpdHkgaXNzdWVzXAogLUphbWVzIFdvb2R5YXR0IC0gcHV0 IHRob3VnaHQgaW50byBjb25zdHJhaW5lZCBkZXZpY2VzIFwKIFByZSBCb290IEV4ZWN1dGlvbiAo UFhFKSBFbnZpcm9ubWVudCBcCiAgLVJGQzU5NzAgbm90IHdpZGVseSBzdXBwb3J0ZWQgKG5lZWRl ZCB0byBzdXBwb3J0IERIQ1B2NilcCiAgLVVFRkkgd2lsbCBmaXggYnV0IG5vdCBhdmFpbGFibGUg eWV0ICh3YWl0PylcCiAtV2VzIC0gc2hvdWxkIGJlIGNhcHR1cmVkIGluIHRoZSBnYXAgYW5hbHlz aXMgLSBpZiBpbXBvcnRhbnQgdGhlbiBzaG91bGQgZ2V0IHBlb3BsZSB0byB3b3JrIG9uIGl0XApE aXNwb3NpdGlvbjogdW5jbGVhclwKXApccGFyZFx0eDcyMFx0eDE0NDBcdHgyMTYwXHR4Mjg4MFx0 eDM2MDBcdHg0MzIwXHR4NTA0MFx0eDU3NjBcdHg2NDgwXHR4NzIwMFx0eDc5MjBcdHg4NjQwXHBh cmRpcm5hdHVyYWwKClxiIFxjZjAgdjZvcHMtc29saWNpdGVkLXJhLXVuaWNhc3QgZHJhZnQgXApc cGFyZFx0eDcyMFx0eDE0NDBcdHgyMTYwXHR4Mjg4MFx0eDM2MDBcdHg0MzIwXHR4NTA0MFx0eDU3 NjBcdHg2NDgwXHR4NzIwMFx0eDc5MjBcdHg4NjQwXHBhcmRpcm5hdHVyYWwKClxiMCBcY2YwIExv cmVuem8gQ29saXR0aSBwcmVzZW50aW5nXAogbmV0d29yayB3aXRoIHRob3VzYW5kcyBvZiBub2Rl cyAtIHNlbmQgUlMgYW5kIGFsbCBkZXZpY2VzIHdha2UgdXAgLSByYXRlLWxpbWl0ZWQgdG8gb25j ZSBldmVyeSAzIHNlY3NcCiAgLXNvbWUgZXhwZXJpZW5jZSBiYWQgYmF0dGVyeSwgZHJvcCBJUHY2 IHBhY2tldHMgb3IganVzdCBtdWx0aWNhc3QgdjYgcGFja2V0cyBcCiAgLVVuaWNhc3QgUkFzIGFy ZSBhbiBvcHRpb24gLSB0aGlzIGRyYWZ0IGFza3MgZm9yIGEga25vYiB0byBjb25maWd1cmUgUkEg cmVzcG9uc2UgdG8gUlNcCiBKSkIgLSB3aGF0IGRvIHlvdSBkbyBmb3Igc29saWNpdGVkIG5vZGUg bXVsdGljYXN0IC0gc29saWNpdGVkIG5vZGUgbXVsdGljYXN0IHNjYWxlcyB3aXRoIHNpemUgb2Yg bmV0d29yayBzbyBub3QgbWFueSBjb2xsaXNpb25zIC0gMyBzZWNzIHVuZGVzaXJhYmxlIC0gXAog LUFuZHJldyBZb3VydGNoZW5rbyAtIHNvbGljaXRlZCBub2RlIG11bHRpY2FzdCBjYW4gYmUgZml4 ZWQgYnkgaW5jcmVhc2VkIHRpbWVycyAtIFJBcyBjYW5cJzkydFwKIC1GcmVkIFRlbXBsaW4gLSBJ U0FUQVAgaGFzIGJlZW4gZG9pbmcgdW5pY2FzdCBSUy9SQSBmb3IgeWVhcnMgLSBcCiAtT2xlIFRy b2FuIC0gSnVzdCBhbiBvcGVyYXRpb25hbCBjb25maWd1cmFibGUgb3B0aW9uLCB0aGF0IHdvdWxk blwnOTJ0IGNoYW5nZSB0aGUgc3BlYywgb3IgdXBkYXRlIHRoZSBhbGdvcml0aG0/IGkuZS4sIGRv ZXMgdGhpcyBnbyB0byA2bWFuIG9yIFwKbm90XApMb3JlbnpvIC0gY29uZmlndXJhdGlvbiBvcHRp b247IDZtYW4gd29uXCc5MnQgcGFzcyBpdC5cCkt5bGUgUm9zZSAoamFiYmVyKSBEcm9wIEJveCBM QU4gaGFzIHRoZSBzYW1lIGVmZmVjdCAtIG1pZ2h0IGJlIGEgd2luZG93IGluIDQ4NjFiaXMgLSBM b3JlbnpvIHNheXMgY291bGQgYWRkIHRleHQgXApBbmRyZXcgLSBtYXliZSBkbyAyIGRvY3MgLSBv bmUgaW4gb3BzIGFuZCBhbm90aGVyIGluIDZtYW4gXApTdXJlc2ggLSBhZGQgcmVhc29uIGZvciB3 aHkgYW5kIHBvaW50IHRvIDQ4NjEgd29yZGluZyBcCk1pa2FlbCAtIHJlZmVyZW5jZSBFcmlrViBk b2N1bWVudCBmcm9tIHR3byBJRVRGcyBhZ28gdGhhdCBoYXMgYSByZWNvbW1lbmRhdGlvbiByZWxl dmFudCB0byB0aGlzXApNYXJrIFRvd25zbGV5IC0gcHJlc2VudGVkIHRoZSBmaW5kaW5ncyBvZiB0 aGUgcHJvYmxlbSAyLTQgSUVURnMgYWdvIC0gdGhpcyBpcyByZWNvbW1lbmRhdGlvbiBmb3Iga25v YiB0byBmaXggaXQgXAogLUFsZXhQIC0gXCc5M05ldHdvcmtzIHNlcnZpbmcgbG90cyBvZiBkZXZp Y2VzIFNIT1VMRFwnOTQgaXMgdG9vIHN0cm9uZy4gRS5nLiwgaWYgZG9pbmcgRE5BLiBTbywgc3Bl Y2lmeSB3aGVuIFNIT1VMRCBkb2VzIGFuZCBkb2VzblwnOTJ0IGFwcGx5XApMb3JlbnpvOiBETkEg aGFzIHJlY29tbWVuZGF0aW9uIG9uIEFsZXhcJzkycyB1c2UgY2FzZSAoSSBiZWxpZXZlKSBcCiAg IC1xdWFsaWZpZWQgd2l0aCAyIHRoaW5ncyAtIGZhc3QgbW92aW5nIG1vYmlsZXMgdGhhdCBkb25c JzkydCBkbyBETkEgYW5kIG90aGVyIGlzIFN1cmVzaFwnOTJzIChsaWtlIHdpdGggODAyLjExcCBu ZXR3b3JrcylcCiBDaHJpc3RpYW4gSHVpdGVtYSAtIFdpRmkgaGFzIGEgc29sdXRpb24gLSBmb3Ig V2lGaSBkZXZpY2UgaXMgYWx3YXlzIHBvbGxpbmcgc28gd2h5IHNob3VsZCBhIG1vYmlsZSB3YWl0 IGZvciBhIFJBXApUaW1DIC0gaW4gVW5pdiBuZXR3b3JrcyBoYXZlIG11bHRpcGxlIFZMQU5zIHdp dGggbXVsdGlwbGUgc3VibmV0cyAtIHZlbmRvcnMgaW1wbGVtZW50ZWQgYSBicm9hZGNhc3QgdHlw ZSBzZXJ2aWNlIHRoYXQgbWFkZSB0aGlzIHdvcnNlIC0gVkxBTiBwb29saW5nIGZpeGVzIHRoaXMg aW4gc29tZSBjYXNlcyBvbiBXaUZpIHRvbyAtIFRpbSBzdWdnZXN0aW5nIHNvbWUgdGV4dCB0byBh ZGRyZXNzIHRoaXMgc2ltaWxhciBwcm9ibGVtIFwKIFRpbSBXaW50ZXJzIC0gYXJlIHBlb3BsZSBu b3QgaW5jbHVkaW5nIGxpbmsgbGF5ZXIgb3B0aW9ucyAtIFwKVmljdG9yIC0gc3BvcnRzIHdvcmtp bmcgb24gdGhpcyBcCkplbiBMaW5rb3ZhIC0ga2VlcCBib3RoIFNob3VsZHMgXApQaGlsaXAgSG9t YnVyZyAtIG5vdCBzdXJlIHdoYXQgaGUgd2FzIHN1Z2dlc3RpbmcgXApTdGV2ZW4gQmFydGggLSBz aG91bGQgd2UgYWxzbyBtYWtlIHJlY29tbWVuZGF0aW9ucyBvbiBpbnRlcnZhbCBhcyB3ZWxsIC0g bWF5YmUgd29yZGluZyBsaWtlIG5ldHdvcmtzIHRoYXQgc3VwcG9ydCBtb2JpbGUgZGV2aWNlcyBz aG91bGQgaW5jcmVhc2UgdGhlaXIgaW50ZXJ2YWwgbGVuZ3RoIHRvIGltcHJvdmUgYmF0dGVyeSBs aWZlIFwKU3R1YXJ0QyAtIEJvbmpvdXIgbm93IGRvZXMgc29tZXRoaW5nIHNpbWlsYXIgLSBhZGRl ZCBjYXBhYmlsaXR5IHRoYXQgc2F5cyByZXBseSB3aXRoIHVuaWNhc3QgZm9yIGV4YW1wbGUgd2hl biBsYXB0b3BzIHdha2UgdXBcCioqQ2FsbCBmb3IgSHVtcyBzaG93ZWQgd2VyZSBhbGwgZm9yIG1h a2luZyB0aGlzIGEgV0cgRG9jdW1lbnQgXApEaXNwb3NpdGlvbjogUmVzdWJtaXQgYXMgV0cgZG9j XApcClwKXApGcmlkYXlcClxwYXJkXHBhcmRlZnRhYjcyMFxyaTcyMFxzYjIwMAoKXGIgXGNmNCBD aGFydGVyIGRpc2N1c3Npb25cClxwYXJkXHBhcmRlZnRhYjcyMFxyaTcyMAoKXGIwIFxjZjAgSm9i IDE6IEZpbmQgb3BlcmF0b3JzXCc5MiBpc3N1ZXMgYW5kIHdvcmthcm91bmRzXApXZXM6IENoYW5n ZSBcJzkzSXB2NC9JcHY2IEludGVybmV0XCc5NCB0byBcJzkzSVB2NiBJbnRlcm5ldFwnOTRcCkpv ZWw6IFdlIGRvblwnOTJ0IGhhdmUgdG8gcHVibGlzaCBldmVyeXRoaW5nLiBTb21ldGltZXMganVz dCBhIGRyYWZ0IGFuZCByZWxhdGVkIGRpc2N1c3Npb24gaXMgdXNlZnVsLiBBbGxvdyBkaXNjdXNz aW9uIHRvIG9jY3VyIGhlcmUgZXZlbiBpZiBpdCBkb2VzblwnOTJ0IHJlc3VsdCBpbiBwdWJsaWNh dGlvbi5cClRvcmU6IEkgaGF2ZSBhbiBvcGVyYXRpb25hbCBpc3N1ZSB0aGF0IHJlcXVpcmVzIGEg cHJvdG9jb2wgY2hhbmdlLCBidXQgdGhlIHJpZ2h0IFdHIG5vIGxvbmdlciBleGlzdHMuIFwKSm9i IDI6XApWaWN0b3I6IENhbiB3ZSBicmluZyBpbiB3b3JrIGZyb20gTk9HcyBhbmQgb3RoZXIgZ3Jv dXBzPyBJXCc5MmQgbGlrZSB0byBmb2N1cyBvbiB2Nm8sIGJ1dCB0b28gbXVjaCBvZiB0aGUgZ2x1 ZSBvZiB2NiBpcyBpbiBJUHY0LlwKRGF2ZSBUaGFsZXI6IERpc2N1c3MgdGhpbmdzIG5lY2Vzc2Fy eSB0byBmYWNpbGl0YXRlIGRlcGxveW1lbnQgb2YgSVB2Ni4gVGhhdCB3b3VsZCBpbmNsdWRlIElQ djQtcmVsYXRlZCBJUHY2IGlzc3VlcyAob3IgdmljZSB2ZXJzYSkuXApMb3JlbnpvOiBSZW1vdmUg SVB2NC4gXApEYXZlOiBcJzkzV2l0aCBJUHY2IEludGVybmV0LCBpbmNsdWRpbmcgb3BlcmF0aW9u YWwgaXNzdWVzIGRlcGVuZGluZyBvbiBJUHY0LlwnOTRcCkxvcmVuem86ICBBIHY0byB0b3BpYyBp cyBvZmYgdG9waWMuIEFncmVlIHdpdGggIzIuXApEYXZlIEFwcGxlOiB2NCBpcyBvdXQgb2Ygc2Nv cGUuIER1YWwtc3RhY2sgaXMgaW4gc2NvcGUuXApGcmVkOiBTbyBtYXliZSByZW1vdmUgSVB2NCwg YW5kIGFkZCBhIHN1Yi1idWxsZXQgc2F5aW5nLCBcJzkzSXNzdWVzIGluIHRoZSBpbnRlcmFjdGlv biBiZXR3ZWVuIElQdjQgYW5kIElQdjZcJzk0XAoJU29tZSBub2RkaW5nIGFuZCB0aHVtYnMgdXAg aW4gdGhlIHJvb20uXApNaWthaWwgQWJyYWhhbWFzc29uOiBXaGF0IEkgd2FudCB0byBhdm9pZCBp cyB0aGF0IGFueSBwcm9ibGVtIEkgaGF2ZSBpcyBvdXQgb2YgY2hhcnRlciBmb3IgYm90aCB2Nm9w cyBhbmQgc3Vuc2V0NC5cCkZyZWQ6IElmIGl0XCc5MnMgYW4gSXB2NC1zcGVjaWZpYyBwcm9ibGVt LCBzdW5zZXQ0LiBJZiBJUHY2LSwgdjZvcHMuIElmIGJvdGgsIHY2b3BzLlwKTWFyYzogSWYgaXRc JzkycyBpbiBzY29wZSBmb3IgSUVURiwgSUVURiBzaG91bGQgZmluZCBhIHBsYWNlIHRvIGRpc2N1 c3MuIEJ1dCBJIGRpc2FncmVlIHdpdGggXCc5M2lmIHRoaXMgaXMgSVB2NCwgZ28gdG8gc3Vuc2V0 NC5cJzk0XApNaWtoYWlsOiBJXCc5Mm0gb2theSB3aXRoIHY2b3BzIGJlaW5nIHY2bywgYnV0IGl0 IG1lYW5zIGV4cGFuZGluZyBzdW5zZXQ0IGNoYXJ0ZXIuXApWaWN0b3I6IE9wZXJhdG9ycyBkb25c JzkydCB3YW50IHRvIHJ1biBhcm91bmQgdG8gbXVsdGlwbGUgd29ya2luZyBncm91cHMuIE5lZWQg YSBkZWZhdWx0IHJvdXRlIGJldHdlZW4gV0dzLlwKSkpCOiBPbiB0aGUgY3VzcCBvZiB2Nm8uIERv aW5nIG1vcmUgd2l0aCB2NiB0aGFuIHY0LCB0YWxraW5nIGFib3V0IGhvdyB0byB0cnVuIGRvd24g d2l0aCB2NC5cCkRhbiBZb3JrOiBZZXMsIGtlZXAgIzEuIExvdHMgb2YgQkNQcyBhdCBOT0dzLCBl dGMuXApcCkpvYiAzOiBEZXNjcmliZSByb2FkbWFwIHRvIHR1cm4gb2ZmIElQdjRcCldlczogVGhp cyBvdmVybGFwcyBzdW5zZXQ0IHNpZ25pZmljYW50bHkuICBUaGVyZVwnOTJzIG5vdCBlbm91Z2gg d29yayBmb3IgdHdvIFdHcy4gSXMgdGhpcyB3b3JrIGltcG9ydGFudCwgYW5kIHdoZXJlIGRvZXMg aXQgYmVsb25nPyAgVGhlcmUgbWF5IGJlIHByb3RvY29sIHdvcmsgYW5kIGludGVyZXN0aW5nIGRp c2N1c3Npb24sIGFuZCB3ZSBkb25cJzkydCB3YW50IHRvIHNwbGl0IHBhcnRpY2lwYW50cy4gV2Vc JzkycmUgZ29pbmcgdG8gdHJ5IHRvIGNvbXBsZXRlIG91ciBleGlzdGluZyBkb2N1bWVudHMsIHRo ZW4gZ28gZG9ybWFudCAoc3Vuc2V0NCkuIFRoYXQgbWlnaHQgaW5mb3JtIHdoYXQgd2UgZG8gYW5k IHdoZXJlIHdlIHB1dCB0aGluZ3MuIFNvLCB5ZXMsIHdlIHNob3VsZCB3b3JrIG9uIGhvdyB0byBt YWtlIHY2byB3b3JrLiBcCkRhdmUgVGhhbGVyOiBXZXMgYW5zd2VyZWQgc29tZSBvZiBteSBxdWVz dGlvbi4gVjZvcHMgaGFzIGJlZW4gaG93IHRvIGdldCBmcm9tIHY0byB0byBkdWFsLXN0YWNrLCBh bmQgc3Vuc2V0NFwnOTJzIGpvYiB3YXMgdG8gZ28gZnJvbSBEUyB0byB2Nm8uIFRoaXMgYnVsbGV0 IGxvb2tzIGxpa2Ugd2VcJzkycmUgZ29pbmcgdG8gY29tYmluZSB0aGF0IGludG8gb25lIGRvY3Vt ZW50LlwKTG9yZW56bzogSSBkb25cJzkydCBsaWtlIHRoaXMgYnVsbGV0LiBJIHRoaW5rIHdlIHNo b3VsZCBkbyBpdC4gV2UgZG9uXCc5MnQgbmVlZCB0byBkZXNjcmliZSBhIHJvYWRtYXAsIHBlciBz ZSwgYnV0IGRvIGJ1bGxldCAjMSB3aXRoIHRoZSBudW1lcm91cyB0cmFuc2l0aW9uIHRlY2hub2xv Z2llcyBhbHJlYWR5IGRlZmluZWQuIFRoaXMgaXMganVzdCBhIHNwZWNpYWwgY2FzZSBvZiAjMS5c CkpKQjogXCc5M3doZW4gSVB2NCBpcyB0dXJuZWQgb2ZmXCc5NCBpcyBub3csIGluIHNvbWUgY2Fz ZXMuIFNvb25lciB0aGFuIDUtMTAgeWVhcnMgc29tZSB0aGluay4gIElmIHN1bnNldDQgaXMgZ29p bmcgdG8gY2xvc2UgZm9yIGxhY2sgb2YgaW50ZXJlc3QsIHRoYXQgY29uY2VybnMgbWUuXApEYW4g WW9yazogWWVzLCB3ZSBuZWVkIHRoaXMga2luZCBvZiBkb2N1bWVudC4gV2VcJzkydmUgd3JpdHRl biBzb21lIG9mIHRoZXNlIGFscmVhZHk7IG1heWJlIHdlIGNvdWxkIHN1bW1hcml6ZS4gSSBnZXQg cXVlc3Rpb25zIGZyb20gcGVvcGxlIHdhbnRpbmcgdG8gbW92ZSB0byB2Nm8gbm93LCBuZWVkIG1v cmUgb2YgdGhhdC4gSSB0aGluayB0aGUgSUVURiBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gZG8gaXQ7 IFJGQ3MgYXJlIGNhbm9uaWNhbCBhbmQgZWFzaWx5IGNvbnN1bWVkLlwKTWlraGFpbDogSWYgc3Vu c2V0NCBpcyBnb2luZyBkb3JtYW50LCBJIHRoaW5rIGl0XCc5MnMgYSBnb29kIGlkZWEgdG8ganVz dCBtZXJnZSB0aGVzZS4gVjZvcHMgaGFzIGVuZXJneSBzdW5zZXQ0IG5ldmVyIGdvdCBpdC4gUGVv cGxlIGhlcmUgaGF2ZSBiZWNvbWUgaW50ZXJlc3RlZCBpbiB0dXJuaW5nIG9mZiB2NC5cCk1hdHQ6 IEJyaWxsaWFudCB0byBoYXZlIDIgV0dzIGFuZCBoYXZlIHRoZW0gYWx3YXlzIG1lZXQgam9pbnRs eS4gSG93IHBlb3BsZSB0aGluayBvZiB0aGUgcHJvYmxlbSBhbHRlcnMgaG93IHRoZXkgZW50ZXIg dGhlIHByb2Nlc3MuXApUc2lhIGZyb20gQ2hpbmEgVGVsZWNvbTogIHY2by4gSVwnOTJ2ZSB1c2Vk IHRoZSB0ZXJtLCBidXQgaXRcJzkycyBjb25mdXNpbmcsIGlzIGl0IGFjY2VzcywgYmFja2JvbmUs IG9yIGRhdGEgY2VudGVyPyAgSXRcJzkycyBiZXR0ZXIgdG8gZGVzaWduIHNldmVyYWwgbWV0cmlj cyB0byBtZWFzdXJlIElwdjYgZGV2ZWxvcG1lbnQuIElwdjYgcGVuZXRyYXRpb24sIHRyYWZmaWMs IHRob3NlIG1ldHJpY3Mgd291bGQgYmUgdXNlZnVsLiBCZXR0ZXIgdG8ga2VlcCB2NCBhbmQgdjYg dG9nZXRoZXIgZm9yIGRpc2N1c3Npb24uXApCcmlhbiBIYWJlcm1hbjogVGVycnkgY291bGRuXCc5 MnQgYmUgaGVyZS4gV2hhdCBNYXR0IHNhaWQgYWJvdXQgam9pbnQgbWVldGluZ3MgbWFrZXMgc2Vu c2UuIFRoZW4gaWYgdGhlcmVcJzkycyBwcm90b2NvbCB3b3JrLCBzdW5zZXQ0IGlzIGFscmVhZHkg aGVyZS5cCkplbiBMaW5rb3ZhOiBJXCc5Mm0gZXhjaXRlZC4gTmVlZCB2b2x1bnRlZXJzIHRvIGhl bHAgZG9jdW1lbnQgdjZvIGRlcGxveW1lbnQuXApGcmVkOiBPa2F5LCB3ZVwnOTJsbCBzZW5kIHVw ZGF0ZWQgZHJhZnQgY2hhcnRlciBhbmQgc2VuZCB0byBsaXN0LiBQbGVhc2Ugc2VuZCBzdWdnZXN0 ZWQgd29yZGluZyBjaGFuZ2VzLlwKXApccGFyZFxwYXJkZWZ0YWI3MjBccmk3MjBcc2IyMDAKClxi XGZzMjYgXGNmNCBBcHBsZSBSZXBvcnRcClxwYXJkXHBhcmRlZnRhYjcyMFxyaTcyMAoKXGIwXGZz MjQgXGNmMCBTdHVhcnQgQ2hlc2hpcmVcClF1ZXN0aW9uOiBpbiB0aGUgTkFUNjQgaW4gTWFjT1Mg Zm9yIGRldmVsb3BlcnMgdG8gdXNlLCB3ZSBhc3NpZ24gMjAwMTo6LzY0LiBXaGF0IHNob3VsZCB3 ZSB1c2U/ICAyMDAxOjI6YTpiYjFlOjovNjRcCkt1cnQgV2FybmVyPyAgUmUgNDY0eGxhdCB2cyBO QVQ2NC4gIElmIHlvdSBkbyBOQVQ2NCBpdCBjb21lcyBETlM2NC4gNDY0eGxhdCBkb2VzblwnOTJ0 IG5lZWQgRE5TNjQsIHdoaWNoIGlzIGltcG9ydGFudCBpZiB5b3Ugd2FudCB0byBkbyBETlNTRUMg bG9jYWwgdmFsaWRhdGlvbi4gXApKYW1lcyBXb29keWF0dDogb25seSBmb3IgQSByZWNvcmRzXAoJ W2xhdWdodGVyXVwKU3R1YXJ0OiBJZiB0aGV5XCc5MnJlIG5ldmVyIHJ1bm5pbmcgTkFUNjQsIHRo ZXJlIHdpbGwgbmV2ZXIgYmUgYSByZWNvcmQgc3ludGhlc2l6ZWQuIEl0XCc5MnMganVzdCB3aGVy ZSBpbiB0aGUgc3RhY2sgeW91XCc5MnJlIGx5aW5nIHRvIHRoZSBhcHAuXApNaWtoYWlsIFttaXNz ZWQgaXRdXApTdHVhcnQ6IFllcywgaWYgeW91IHVzZSBsaXRlcmFscywgd2UgZG8gdGhlIHN5bnRo ZXNpcyBsb2NhbGx5LiBZb3UgY2FuIGRvIGJ1bXAgaW4gdGhlIHN0YWNrIG9yIGJ1bXAgaW4gdGhl IEFQSS4gV2UgZG8gaXQgaW4gdGhlIEFQSS5cCk1hcmM6IEEgZmV3IG1haW5zdHJlYW0gYXBwcyBh cmUgdjRvLlwKRGF2ZSBUaGFsZXI6IElFVEYgTkFUNjQgaGFzIGJlZW4gd29ya2luZyBiZXR0ZXIg dGhhbiBJRVRGIFNTSUQgdGhpcyB3ZWVrLiBZZXMsdXNlIHRoZSBuZXcgcHJlZml4LiAgMjAwMToy OjogaXMgdGhlIGJlbmNobWFya2luZyBwcmVmaXgsIGFzayBCTVdHIGlmIGl0XCc5MnMgb2theSB3 aXRoIHRoZW0uXApGcmVkOiByZmM2MDUyIGdpdmVzIGEgcHJlZml4IGZvciB0aGlzIHB1cnBvc2Uu IFNlY3Rpb24gMi4xXApMb3JlbnpvOiA2NDpmOTliPyAgU29tZSB0aGluZ3Mgc2F5IHlvdSBjYW5c JzkydCB1c2UgdGhhdCB3aXRoIGFueSBwcml2YXRlIGFkZHJlc3Nlcy5cClN0dWFydDogV2UgY2xl YXJseSB3YW50IHRvIG1ha2Ugc3VyZSB0aGUgc29mdHdhcmUgZG9lc25cJzkydCByZWNvZ25pemUg aXQgYXMgYSBzcGVjaWFsIGFkZHJlc3MuXApMb3JlbnpvOiBXaXRoIDQ2NHhsYXQsIHRoZXJlXCc5 MnMgYSB2NiBjbGllbnQgYXMgd2VsbC4gSXRcJzkycyByZXF1aXJlZC4gSXRcJzkycyBhIHdheSB0 byBwcm92aWRlIHY0IHdoZW4geW91IGFscmVhZHkgaGF2ZSB2Ni4gU3RpbGwsIEkgYWdyZWUgTkFU NjQgaXMgYmV0dGVyIGlmIHlvdSBjYW4gbWFrZSBpdCBzdGljaywgYW5kIEkgaG9wZSB5b3UgY2Fu LlwKU3R1YXJ0OiBZZXMuIFdlIHdhbnQgZGV2ZWxvcGVycyB0byBkbyB2NiBhcHBzLCBhbmQgd2Ug ZG9uXCc5MnQgdGhpbmsgaXRcJzkycyBoYXJkLlwKSmFtZXMgV29vZHlhdHQ6IFdoeSBpbiAyMDE1 IHVzaW5nIGlvcyA4LjEgSSBzdGlsbCBjYW5cJzkydCBjb25maWd1cmUgaXQgb24gVG1vIG9yIE9y YW5nZSBvciBhbnkgRXVyb3BlYW4gY2FycmllciB3aXRoIElQdjYgb3IgTkFUNjQuIEkgd2FudCB0 byB0ZXN0IG9uIGEgcmVhbCBuZXR3b3JrLiBcClN0dWFydDogU29tZSBjYXJyaWVycyB3aWxsIGxl dCB5b3UgZG8gdGhhdC5cCkFuZHJldyBZb3VydGNoZW5rbzogVGhhbmtzIGZvciBtYWtpbmcgbXkg am9iIGVhc2llci4gSSB3YXMgdHJ5aW5nIHRvIGNvbnZpbmNlIGRldmVsb3BlcnMgdG8gZG8gdjYs IGFuZCBvbmUgb2YgdGhlbSBzYWlkIHRoZXlcJzkyZCBzdGFydGVkIGJlY2F1c2Ugb2YgQXBwbGUu IFdoZW4geW91IGNhbiBlbnN1cmUgYXBwIGhhcyBJUHY2LCB5b3VcJzkycmUgaW4gYSBiZXR0ZXIg cG9zaXRpb24uIFdlIGRvIHY2bytOQVQ2NCBhcyBkZWZhdWx0LCBhbmQganVzdCBsZXNzIHRoYW4g NDAlIG9mIGNsaWVudHMgc3RpY2sgdG8gdGhhdCBvbmUuIElQdjQgbmF0aXZlIGlzIGNhbGxlZCBc JzkzLWxlZ2FjeVwnOTQuIFwKVG9yZSBBbmRyZXNvbjogQ2hhbmdlIHByZWZpeCBmcm9tIC82NCB0 byAvOTYuIFdvdWxkIGxldCB5b3UgdGVzdCBJUHY0LWVtYmVkZGVkLiBTZWUgcmM2MDUyLlwKRGF2 aWQ6IEl0XCc5MnMgbm90IHRoZSBhZHJlcyBvZiB0aGUgTkFUNjQgc2VydmVyLCBpdFwnOTJzIHRo ZSBOQVQ2NCBwcmVmaXguXApUb3JlOiBBc3NpZ24gYSBwcmVmaXgsIGRvY3VtZW50IGl0IGluIFdI T0lTLiAgXAoJSm9lbCBhcHBsYXVkc1wKRWR3aW4gUHJvdGVnbzogVXNpbmcgVGVyZWRvIG9yIDZv NCBwcmVmaXggd2lsbCBtZXNzIHVwIGVudGVycHJpc2VzIHdobyBmaWx0ZXIgaXQuIFwKU3R1YXJ0 OiBUaGVzZSB3aWxsIG5ldmVyIGJlIGluIGVudGVycHJpc2UgbmV0d29yaywgaXRcJzkycyBvbmUg aG9wLCBiZXR3ZWVuIHlvdXIgcGhvbmUgYW5kIHlvdXIgTWFjLiBOb2JvZHkgZWxzZSBpbiB0aGUg d29ybGQgd2lsbCBldmVyIHNlZSB0aGVzZSBhZGRyZXNzLiAgQWdyZWUtYXNrIElBTkEgdG8gYXNz aWduIGFuIGFkZHJlc3MuXApcClxwYXJkXHBhcmRlZnRhYjcyMFxyaTcyMFxzYjIwMAoKXGIgXGNm NCBJUHY2IERlcGxveW1lbnQgYXQgT1RFXApccGFyZFxwYXJkZWZ0YWI3MjBccmk3MjAKClxiMCBc Y2YwIFlhbm5pcyBOaWtvbG9wb3Vsb3NcCjEuM00gRFNMIHN1YnMsIDM4MGsgVFYgKElQL1NBVClc Ck5vIGlzc3VlcyB3aXRoIEJSQVNcdWMwXHU4MjMyIEJ1Z3MgaW4gQk5HIGFuZCBpbiBDUEVcCkxv dHMgb2YgYnVncyBpbiBDUEVcCkRlZmF1bHQgc2VjdXJpdHkgcG9saWN5IGlzIFwnOTNkZWZhdWx0 IGRlbnksXCc5NCBidXQgd2lsbCBhbGxvdyB1c2VycyB0byBvcHQgZm9yIFwnOTNkZWZhdWx0IHBl cm1pdFwnOTRcCklQdjYgYnVncyBnbyB1bm5vdGljZWQgaW4gZHVhbC1zdGFjayBlbnZpcm9ubWVu dFwKQ2hvc2UgTFc0bzYsIGxhdW5jaGluZyBRMS0yMDE2XApTdGlsbCBuZXJ2b3VzIHRoYXQgdGhl aXIgSVB2NCBleGhhdXN0aW9uIG1heSBoYXBwZW4gYmVmb3JlIHRoZWlyIHY2byBzZXJ2aWNlXAoy MCUgb2YgdXNlcnMgaGF2ZSBJUHY2LiAxMCUgb2YgdHJhZmZpYy5cClwKXHBhcmRccGFyZGVmdGFi NzIwXHJpNzIwXHNiMjAwCgpcYlxmczI2IFxjZjQgSG9zdCBhZGRyZXNzIGF2YWlsYWJpbGl0eVwK XHBhcmRccGFyZGVmdGFiNzIwXHJpNzIwCgpcYjBcZnMyNCBcY2YwIExvcmVuem8gQ29saXR0aVwK MjAtMzAgcHBsIGhhdmUgcmVhZCBpdFwKU2hpbiBNaXlha2F3YTogU3VwcG9ydC4gIENvbnNpZGVy IE5BUFQ2NiB2cyBOUFQ2Ni4gUHJlZml4IE5BVCBtaWdodCBiYXR0ZXJ5LlwKTG9yZW56bzogRGlk blwnOTJ0IGluY2x1ZGUgTlBUIGJlY2F1c2UgaG9zdCBpc25cJzkydCBnZXR0aW5nIGEgcHJlZml4 LiBXZVwnOTJsbCBhZGQgdGhhdCB0byB0aGUgZG9jLlwKU2hpbjogVk1zIG5lZWQgbW9yZSBhZGRy ZXNzZXMgdGhhbiB5b3Ugc2F5LlwKV2VzOiBHb29kLCBpbXBvcnRhbnQgZG9jdW1lbnQuIFRoaXMg bmVlZCB3YXMgbmV3IGluZm9ybWF0aW9uIHRvIG1lLiAgTGltaXRhdGlvbnMgb2YgYXNraW5nIGZv ciBtb3JlIG9uIHRoZSBmbHkgc2VjdGlvbiBpcyB2YWd1ZS4gTG90cyBvZiB0aGluZ3MgcmVxdWly ZSB3YWl0aW5nIGZvciBzb21ldGhpbmcgdG8gaGFwcGVuLiBMb3RzIG9mIGNhc2VzIHdoZXJlIHlv dSBrbm93IGFoZWFkIG9mIHRpbWUgeW91XCc5MmxsIG5lZWQgbW9yZSB0aGFuIG9uZS4gTGF1bmNo aW5nIGEgVk0gd2lsbCByZXF1aXJlIG9uIHRoZSBmbHksIGJ1dCBlbnVtZXJhdGUgdGhlc2UgY2Fz ZXMgYmV0dGVyLiBJXCc5MmxsIHNlbmQgbm90ZXMgdG8gdGhlIGxpc3QuIE5vIHBvaW50IGRlYmF0 aW5nIGhvdyBtYW55IGlzIFwnOTNlbm91Z2gsXCc5NCB3ZVwnOTJsbCBuZXZlciBnZXQgY29uc2Vu c3VzLiBEaXNjdXNzIGJ5IHdheSBvZiBleGFtcGxlLCBidXQgbm90IHRvIGxpbWl0IHRoZSBwcm9i bGVtLiBcCkZyZWQgQmFrZXI6IE5lZWQgdG8gY3V0IHRoaXMgc2hvcnRcJzk3b3V0IG9mIHRpbWUu XApGcmVkIFRlbXBsaW46IC1QRC4gSXRcJzkycyBpbiBBRVJPLiBHZXQgUEQgb3ZlciB3aXJlbGVz cywgYXNzaWduIHRvIHZpcnR1YWwgaW50ZXJmYWNlLiBcClRvcmU6IElmIGVhY2ggZW5kcG9pbnQg Z2V0cyBhIC82NCwgZnJvbSBhIC81Niwgbm90IGVub3VnaCBzcGFjZS5cCkxvcmVuem86IFRob3Nl IG5ldHdvcmtzIGFyZW5cJzkydCBvbmVzIHRoYXQgbmVlZCBhZG1pbmlzdHJhdG9yIGludGVyZmVy ZW5jZS4gSW4gYSBob21lLCB5b3UgY2FuIHVzZSBTTEFBQy5cCkFkb3B0IGFzIGEgV0cgaXRlbT8g IFN0cm9uZyBodW0geWVzLCBzaWxlbnQgbm8uXApEaXNwb3NpdGlvbjogQWRvcHQgYXMgV0cgaXRl bVwKXHBhcmRccGFyZGVmdGFiNzIwXHJpNzIwXHNiMjAwCgpcYlxmczI2IFxjZjQgSVAvSUNNUCBU cmFuc2xhdGlvbiBBbGdvcml0aG0gKFNJSVQpIChyZmM2MTQ1YmlzKVwKXHBhcmRccGFyZGVmdGFi NzIwXHJpNzIwCgpcYjBcZnMyNCBcY2YwIFhpbmcgTGlcCldoZXJlIHRvIGRpc2N1c3M/XApCRUhB VkUgZG9lc25cJzkydCBleGlzdC5cCkRpc2N1c3MgaW4gc3Vuc2V0ND8gVjZvcHM/IFwKSm9lbCBo YXMgYWdyZWVkIHRvIGxldCB1cyBkaXNjdXNzIG9uIHY2b3BzLCBhbmQgdGhlbiB0YWtlIGFzIGFu IEFELXNwb25zb3JlZCBkcmFmdC5cCkZyZWQgaGFkIHRob3VnaHQgdG8gZm9sZCB0aGUgRUFNIGRy YWZ0IGludG8gdGhpcywgYnV0IGR1ZSB0byB0aGUgaGFpcnBpbm5pbmcgcXVlc3Rpb24sIGl0IHNo b3VsZCBiZSBzZXBhcmF0ZS4gV2VcJzkybGwgcHVibGlzaCB0aGUgRUFNIGRyYWZ0LCBhbmQgdGhp cyBvbmUgY2FuIHJlZmVyIHRvIGl0LlwKRGlzcG9zaXRpb246IERpc2N1c3MsIHRoZSBzZW5kIGFz IEFELXNwb25zb3JlZCBkcmFmdC5cClwKXApccGFyZFx0eDcyMFx0eDE0NDBcdHgyMTYwXHR4Mjg4 MFx0eDM2MDBcdHg0MzIwXHR4NTA0MFx0eDU3NjBcdHg2NDgwXHR4NzIwMFx0eDc5MjBcdHg4NjQw XHBhcmRpcm5hdHVyYWwKXGNmMCBcClwKXAp9 --_002_D1EE823FBE734LeeHowardtwcablecom_-- From nobody Mon Aug 10 23:55:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526D21A0A6A; Mon, 10 Aug 2015 23:55:07 -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 eFdlHEJoClGZ; Mon, 10 Aug 2015 23:55:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C96A1A19E4; Mon, 10 Aug 2015 23:55:03 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150811065503.31630.64234.idtracker@ietfa.amsl.com> Date: Mon, 10 Aug 2015 23:55:03 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-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, 11 Aug 2015 06:55:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments Author : Tore Anderson Filename : draft-ietf-v6ops-siit-dc-02.txt Pages : 23 Date : 2015-08-10 Abstract: This document describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-siit-dc-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 Tue Aug 11 05:40: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 9A4CD1A897E; Tue, 11 Aug 2015 05:40:09 -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_40=-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 82ElyqxzaV2d; Tue, 11 Aug 2015 05:40:07 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF5E1A8984; Tue, 11 Aug 2015 05:40:00 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,652,1432612800"; d="scan'208,217";a="346460152" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 11 Aug 2015 08:36:02 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 11 Aug 2015 08:39:59 -0400 From: "George, Wes" To: Ca By , Toerless Eckert Date: Tue, 11 Aug 2015 08:40:01 -0400 Thread-Topic: New features in Legacy IPv4 (was Re: [v6ops] protocols without need for ALG ?) Thread-Index: AdDUMtYCTafPteQlTg6ZsHzf3Ap4Ow== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1EF60F2643E2wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Aug 2015 12:40:09 -0000 --_000_D1EF60F2643E2wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYm91bmNl c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBDYSBCeSA8Y2IubGlzdDZAZ21haWwuY29tPG1haWx0 bzpjYi5saXN0NkBnbWFpbC5jb20+Pg0KRGF0ZTogRnJpZGF5LCBKdWx5IDMxLCAyMDE1IGF0IDk6 MzcgQU0NCg0KT24gVGh1cnNkYXksIEp1bHkgMzAsIDIwMTUsIFRvZXJsZXNzIEVja2VydCA8ZWNr ZXJ0QGNpc2NvLmNvbTxtYWlsdG86ZWNrZXJ0QGNpc2NvLmNvbT4+IHdyb3RlOg0KRm9yIGF1dG9u b21pYyBuZXR3b3JraW5nIChBTklNQSBXRyksIHdlIGFyZSBwbGFubmluZyB0byByZWx5IG9ubHkg b24gSVB2NiBmb3IgaW5pdGlhbA0KYXV0b25vbWljIGNvbm5lY3Rpdml0eSwgYW5kIHRoZSBxdWVz dGlvbiBvZiBjb25uZWN0aW5nIHRoaXMgKGF0IGxlYXN0IGluaXRpYWxseSkNCnRvIElQdjQgb25s eSBOT0MgZXF1aXBtZW50IGNhbWUgdXAuIEFsYXMsIElQdjYgc3VwcG9ydCBpbiB0cmFuc3BvcnQg c2VlbXMgdG8gYmUgc3RpbGwNCndlYWsgb24gYSByYW5nZSBvZiBjb21tb25seSB1c2VkIE5PQyB0 b29scy4NCg0KRm9yIHNvbWV0aGluZyBhcyBmb3J3YXJkIGxvb2tpbmcgYXMgYW5pbWEgLCBpdCBp cyB1bmZvcnR1bmF0ZSB0aGF0IHlvdSBiZWxpZXZlIHlvdSB3aWxsIG5lZWQgdG8gYnJpbmcgdGhp cyB0ZWNobmljYWwgZGVidCB3aXRoIHlvdS4NCg0KTXkgc3VnZ2VhdGlvbiBpcyB0aGF0IHlvdSBy ZXF1aXJlIGlwdjYgZm9yIHRoaXMgY2FzZS4gSWYgeW91IGRvIG5vdCBzaGVkIHRoaXMgcmVxdWly ZW1lbnQgbm93LCB5b3Ugd2lsbCBjYXJyeSBpdCB3aXRoIHlvdSBmb3JldmVyLg0KDQpUaGUgaXBo b25lIGNhbiByZXF1aXJlIGlwdjYgYXBwcywgc28gY2FuIGFuaW1hLg0KDQpXR10gKzEuIEZ1cnRo ZXIsIEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IHdoZW4gY29uc2lkZXJpbmcgZnV0dXJlIG5ldHdv cmsgbWFuYWdlbWVudCBtb2RlbHMsIHRoZSBtYW5hZ2VtZW50IG92ZXJoZWFkIG9mIG1haW50YWlu aW5nIGR1YWwtc3RhY2sgaW5kZWZpbml0ZWx5IGlzIGZhaXJseSBoaWdoLCBhbmQgaW4gYXJlYXMg d2hlcmUgYW4gb3BlcmF0b3IgY29udHJvbHMgYm90aCBzaWRlcyBvZiB0aGUgZXF1aXBtZW50LCBh IHRhcmdldGVkIG1vdmUgdG8gSVB2Ni1vbmx5IGlzIGZhciBtb3JlIGZlYXNpYmxlIGFuZCBsaWtl bHkuIFRoaXMgaXMgaG93IHdlIGFuZCBvdGhlcnMgaGF2ZSBkZXBsb3llZCBJUHY2LW9ubHkgYXBw bGljYXRpb25zIG9uIG91ciBuZXR3b3JrcyB0b2RheSDigJMgd2UncmUgbm90IGFibGUgdG8gdHVy biBvZmYgSVB2NCBpbiB0aGUgY29yZSBhbnl0aW1lIHNvb24sIGJ1dCB3ZSdyZSBjZXJ0YWlubHkg YWJsZSB0byBmb3JjZSBuZXcgYXBwbGljYXRpb25zIHRoYXQgb3BlcmF0ZSBvbmx5IGJldHdlZW4g ZXF1aXBtZW50IHRoYXQgd2Ugb3duIGFuZCBtYW5hZ2UgdG8gdXNlIG9ubHkgSVB2NiB0byBwcmV2 ZW50IHVzIGZyb20gaGF2aW5nIHRvIGZpbmQgSVB2NCBhZGRyZXNzZXMgdG8gbWFuYWdlIHRoZSBl bGVtZW50cyBpbnZvbHZlZCwgZXNwZWNpYWxseSBhdCBsYXJnZSBzY2FsZS4gQW5kIGZvciB0aG9z ZSBsZWdhY3kgYXBwbGljYXRpb25zIGFuZCBzeXN0ZW1zIHRoYXQgY2FuJ3QgZG8gSVB2NiBhbmQg YXJlIGNvc3QtcHJvaGliaXRpdmUgdG8gdXBncmFkZSwgdGhlIHNhbWUgaXMgbGlrZWx5IHRydWUg Zm9yIGFkZGluZyBzdXBwb3J0IGZvciBBbmltYS4NCg0KTW9yZSBnZW5lcmFsbHk6IExlZSBhbmQg SSBwb3NlZCB0aGUgcXVlc3Rpb24gdG8gSUVTRyBvZiB3aGV0aGVyIGl0J3MgYXBwcm9wcmlhdGUg dG8gY29udGludWUgYWRkaW5nIG5ldyBmZWF0dXJlcyB0byBJUHY0IGFmdGVyIHNlZWluZyBubyBm ZXdlciB0aGFuIDMgcmVjZW50IGRyYWZ0cyB0aGF0IGFsbCBhZGQgbmV3IGZlYXR1cmVzIGludG8g SVB2NDoNCmRyYWZ0LWR1LWFuaW1hLWlwdjQtYWNwICAiQXV0b25vbWljIENvbnRyb2wgUGxhbmUg QmFzZWQgb24gSVB2NMKyDQoNCmRyYWZ0LWppYW5nLWRoYy1zZWRoY3B2NCAiU2VjdXJlIERIQ1B2 NCINCg0KZHJhZnQtaWV0Zi10c3Z3Zy1uYXRzdXBwICJTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Np b24gUHJvdG9jb2wgKFNDVFApIE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdGlvbiBTdXBwb3J0Ig0K DQpJcyBpdCB0aW1lIHRvIHJlc3VycmVjdCB0aGlzIGRyYWZ0IGFuZCBwdXNoIGl0IGZvcndhcmQ/ IEl0IGRvZXNuJ3QgZXhwbGljaXRseSBwcm9oaWJpdCB3b3JrIG9mIHRoZSB0eXBlIHByb3Bvc2Vk IGluIHRoZSBhYm92ZSBkcmFmdHMsIGJ1dCBJJ2QgbGlrZSB0byB0aGluayB0aGF0ICB0aGUgY3Vy cmVudCBsYW5ndWFnZSBzdHJvbmdseSBkaXNjb3VyYWdlcyBpdC4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1nZW9yZ2UtaXB2Ni1zdXBwb3J0LTAzDQoNCldlcyBHZW9yZ2UNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgRS1tYWlsIGFuZCBhbnkgb2Yg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1Ympl Y3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1h aWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2Vu IGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBF LW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBh bnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K --_000_D1EF60F2643E2wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0K PGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0 LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9S REVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6 IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsg Qk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnY2b3BzICZsdDs8YSBocmVmPSJtYWls dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBDYSBCeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNiLmxpc3Q2QGdtYWlsLmNv bSI+Y2IubGlzdDZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwgSnVseSAzMSwgMjAxNSBhdCA5OjM3IEFNPGJy Pg0KPGJyPg0KPC9kaXY+DQpPbiBUaHVyc2RheSwgSnVseSAzMCwgMjAxNSwgVG9lcmxlc3MgRWNr ZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86ZWNrZXJ0QGNpc2NvLmNvbSI+ZWNrZXJ0QGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPg0KRm9yIGF1dG9ub21pYyBuZXR3b3JraW5nIChBTklNQSBXRyksIHdlIGFyZSBw bGFubmluZyB0byByZWx5IG9ubHkgb24gSVB2NiBmb3IgaW5pdGlhbDxicj4NCmF1dG9ub21pYyBj b25uZWN0aXZpdHksIGFuZCB0aGUgcXVlc3Rpb24gb2YgY29ubmVjdGluZyB0aGlzIChhdCBsZWFz dCBpbml0aWFsbHkpPGJyPg0KdG8gSVB2NCBvbmx5IE5PQyBlcXVpcG1lbnQgY2FtZSB1cC4gQWxh cywgSVB2NiBzdXBwb3J0IGluIHRyYW5zcG9ydCBzZWVtcyB0byBiZSBzdGlsbDxicj4NCndlYWsg b24gYSByYW5nZSBvZiBjb21tb25seSB1c2VkIE5PQyB0b29scy48YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Gb3Igc29tZXRoaW5nIGFzIGZvcndhcmQgbG9va2lu ZyBhcyBhbmltYSAsIGl0IGlzIHVuZm9ydHVuYXRlIHRoYXQgeW91IGJlbGlldmUgeW91IHdpbGwg bmVlZCB0byBicmluZyB0aGlzIHRlY2huaWNhbCBkZWJ0IHdpdGggeW91LiZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TXkgc3VnZ2VhdGlvbiBpcyB0aGF0IHlvdSByZXF1aXJl IGlwdjYgZm9yIHRoaXMgY2FzZS4gSWYgeW91IGRvIG5vdCBzaGVkIHRoaXMgcmVxdWlyZW1lbnQg bm93LCB5b3Ugd2lsbCBjYXJyeSBpdCB3aXRoIHlvdSBmb3JldmVyLiZuYnNwOzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGlwaG9uZSBjYW4gcmVxdWlyZSBpcHY2IGFwcHMsIHNv IGNhbiBhbmltYS4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPldHXSAmIzQzOzEuIEZ1cnRoZXIsIEkgc3Ryb25n bHkgYmVsaWV2ZSB0aGF0IHdoZW4gY29uc2lkZXJpbmcgZnV0dXJlIG5ldHdvcmsgbWFuYWdlbWVu dCBtb2RlbHMsIHRoZSBtYW5hZ2VtZW50IG92ZXJoZWFkIG9mIG1haW50YWluaW5nIGR1YWwtc3Rh Y2sgaW5kZWZpbml0ZWx5IGlzIGZhaXJseSBoaWdoLCBhbmQgaW4gYXJlYXMgd2hlcmUgYW4gb3Bl cmF0b3IgY29udHJvbHMNCiBib3RoIHNpZGVzIG9mIHRoZSBlcXVpcG1lbnQsIGEgdGFyZ2V0ZWQg bW92ZSB0byBJUHY2LW9ubHkgaXMgZmFyIG1vcmUgZmVhc2libGUgYW5kIGxpa2VseS4gVGhpcyBp cyBob3cgd2UgYW5kIG90aGVycyBoYXZlIGRlcGxveWVkIElQdjYtb25seSBhcHBsaWNhdGlvbnMg b24gb3VyIG5ldHdvcmtzIHRvZGF5IOKAkyB3ZSdyZSBub3QgYWJsZSB0byB0dXJuIG9mZiBJUHY0 IGluIHRoZSBjb3JlIGFueXRpbWUgc29vbiwgYnV0IHdlJ3JlIGNlcnRhaW5seQ0KIGFibGUgdG8g Zm9yY2UgbmV3IGFwcGxpY2F0aW9ucyB0aGF0IG9wZXJhdGUgb25seSBiZXR3ZWVuIGVxdWlwbWVu dCB0aGF0IHdlIG93biBhbmQgbWFuYWdlIHRvIHVzZSBvbmx5IElQdjYgdG8gcHJldmVudCB1cyBm cm9tIGhhdmluZyB0byBmaW5kIElQdjQgYWRkcmVzc2VzIHRvIG1hbmFnZSB0aGUgZWxlbWVudHMg aW52b2x2ZWQsIGVzcGVjaWFsbHkgYXQgbGFyZ2Ugc2NhbGUuIEFuZCBmb3IgdGhvc2UgbGVnYWN5 IGFwcGxpY2F0aW9ucyBhbmQgc3lzdGVtcw0KIHRoYXQgY2FuJ3QgZG8gSVB2NiBhbmQgYXJlIGNv c3QtcHJvaGliaXRpdmUgdG8gdXBncmFkZSwgdGhlIHNhbWUgaXMgbGlrZWx5IHRydWUgZm9yIGFk ZGluZyBzdXBwb3J0IGZvciBBbmltYS4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPk1vcmUgZ2VuZXJhbGx5OiBMZWUgYW5kIEkg cG9zZWQgdGhlIHF1ZXN0aW9uIHRvIElFU0cgb2Ygd2hldGhlciBpdCdzIGFwcHJvcHJpYXRlIHRv IGNvbnRpbnVlIGFkZGluZyBuZXcgZmVhdHVyZXMgdG8gSVB2NCBhZnRlciBzZWVpbmcgbm8gZmV3 ZXIgdGhhbiAzIHJlY2VudCBkcmFmdHMgdGhhdCBhbGwgYWRkIG5ldyBmZWF0dXJlcyBpbnRvIElQ djQ6Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1l ZGl1bTsiPmRyYWZ0LWR1LWFuaW1hLWlwdjQtYWNwJm5ic3A7Jm5ic3A7JnF1b3Q7QXV0b25vbWlj IENvbnRyb2wgUGxhbmUgQmFzZWQgb24gSVB2NMKyPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+ZHJhZnQtamlh bmctZGhjLXNlZGhjcHY0ICZxdW90O1NlY3VyZSBESENQdjQmcXVvdDs8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij48YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07 Ij5kcmFmdC1pZXRmLXRzdndnLW5hdHN1cHAgJnF1b3Q7U3RyZWFtIENvbnRyb2wgVHJhbnNtaXNz aW9uIFByb3RvY29sIChTQ1RQKSBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24gU3VwcG9ydCZx dW90OzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZv bnQtc2l6ZTogbWVkaXVtOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPklzIGl0IHRpbWUgdG8gcmVzdXJyZWN0IHRoaXMgZHJhZnQg YW5kIHB1c2ggaXQgZm9yd2FyZD8gSXQgZG9lc24ndCBleHBsaWNpdGx5IHByb2hpYml0IHdvcmsg b2YgdGhlIHR5cGUgcHJvcG9zZWQgaW4gdGhlIGFib3ZlIGRyYWZ0cywgYnV0IEknZCBsaWtlIHRv IHRoaW5rIHRoYXQgJm5ic3A7dGhlIGN1cnJlbnQgbGFuZ3VhZ2Ugc3Ryb25nbHkgZGlzY291cmFn ZXMgaXQuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nZW9y Z2UtaXB2Ni1zdXBwb3J0LTAzIiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNp emU6IG1lZGl1bTsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nZW9yZ2UtaXB2 Ni1zdXBwb3J0LTAzPC9hPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7Ij48YnI+DQo8L2Rpdj4NCjxkaXY+V2VzIEdlb3JnZTwvZGl2Pg0KPGJyPg0K PGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj5UaGlzIEUtbWFp bCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJs ZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2Fi bGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywg b3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNo bWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQu PGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D1EF60F2643E2wesleygeorgetwcablecom_-- From nobody Tue Aug 11 05:52: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 667551A89D3; Tue, 11 Aug 2015 05:52:30 -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 aAPP3C_rDXBe; Tue, 11 Aug 2015 05:52:27 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 E7A001A89C7; Tue, 11 Aug 2015 05:52:26 -0700 (PDT) Received: by wicne3 with SMTP id ne3so59402517wic.0; Tue, 11 Aug 2015 05:52:25 -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=CfZkJ4rmT6kcq6o4jAvepeS6ah2ayTqbaqU/4+Vi9xY=; b=qox4ddiBZk1lEIzYjc+G45sQAL54JoIBM0Gd2t1pWJ77sRL3GGVy+CUK9rHE0ISTF7 sCAobPTh/GLMTs3qEgBRF2hnrNS/vO9L8JeU9SaekcFg348Kp4hFMTs5SQgnjTxDHeN2 RzPQsG7rl7v4hlU8Rbd4dltcUdD2iD8ydCf64oHX6LZgSuivhfwucyupQgdxMxvpnnvK 03V8wXVxYJS7hY+Zw4h+7dPySb12Une+DL67GMTalNl3r2uV5pOM9pYlIh3I3YA1v4Ds ytSknXiFi33LSfBpl4AIKuUTuRjBvCchmJZ/JFDYKUHYtPcNQU7cT18WmdG8A0RCZDQB a+dQ== MIME-Version: 1.0 X-Received: by 10.194.10.165 with SMTP id j5mr59579474wjb.147.1439297545550; Tue, 11 Aug 2015 05:52:25 -0700 (PDT) Received: by 10.194.191.232 with HTTP; Tue, 11 Aug 2015 05:52:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Aug 2015 05:52:25 -0700 Message-ID: From: Ca By To: "George, Wes" Content-Type: multipart/alternative; boundary=e89a8f642b06edc5f1051d08924c Archived-At: Cc: "behave@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Aug 2015 12:52:30 -0000 --e89a8f642b06edc5f1051d08924c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, August 11, 2015, George, Wes wrote: > > From: v6ops > on behalf of Ca > By > > Date: Friday, July 31, 2015 at 9:37 AM > > On Thursday, July 30, 2015, Toerless Eckert > wrote: > >> For autonomic networking (ANIMA WG), we are planning to rely only on IPv= 6 >> for initial >> autonomic connectivity, and the question of connecting this (at least >> initially) >> to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seem= s >> to be still >> weak on a range of commonly used NOC tools. >> > > For something as forward looking as anima , it is unfortunate that you > believe you will need to bring this technical debt with you. > > My suggeation is that you require ipv6 for this case. If you do not shed > this requirement now, you will carry it with you forever. > > The iphone can require ipv6 apps, so can anima. > > WG] +1. Further, I strongly believe that when considering future network > management models, the management overhead of maintaining dual-stack > indefinitely is fairly high, and in areas where an operator controls both > sides of the equipment, a targeted move to IPv6-only is far more feasible > and likely. This is how we and others have deployed IPv6-only application= s > on our networks today =E2=80=93 we're not able to turn off IPv4 in the co= re anytime > soon, but we're certainly able to force new applications that operate onl= y > between equipment that we own and manage to use only IPv6 to prevent us > from having to find IPv4 addresses to manage the elements involved, > especially at large scale. And for those legacy applications and systems > that can't do IPv6 and are cost-prohibitive to upgrade, the same is likel= y > true for adding support for Anima. > > More generally: Lee and I posed the question to IESG of whether it's > appropriate to continue adding new features to IPv4 after seeing no fewer > than 3 recent drafts that all add new features into IPv4: > draft-du-anima-ipv4-acp "Autonomic Control Plane Based on IPv4=C2=B2 > > draft-jiang-dhc-sedhcpv4 "Secure DHCPv4" > > draft-ietf-tsvwg-natsupp "Stream Control Transmission Protocol (SCTP) > Network Address Translation Support" > > Is it time to resurrect this draft and push it forward? It doesn't > explicitly prohibit work of the type proposed in the above drafts, but I'= d > like to think that the current language strongly discourages it. > https://tools.ietf.org/html/draft-george-ipv6-support-03 > > Wes George > Yes. We clearly see that folks need the message to be unambiguous 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 th= at > 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 o= f > this E-mail and any printout. > --e89a8f642b06edc5f1051d08924c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, August 11, 2015, George, Wes <wesley.george@twcable.com> wrote:

From: v6ops <v6ops-bounces@ietf.org> on behalf of Ca By <cb.list6@gmail.com>
Date: Friday, July 31, 2015 at 9:37= AM

On Thursday, July 30, 2015, Toerless Eckert <eckert@= cisco.com> wrote:
For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 f= or initial
autonomic connectivity, and the question of connecting this (at least initi= ally)
to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems t= o be still
weak on a range of commonly used NOC tools.

For something as forward looking as anima , it is unfortunate that you= believe you will need to bring this technical debt with you.=C2=A0

My suggeation is that you require ipv6 for this case. If you do not sh= ed this requirement now, you will carry it with you forever.=C2=A0

The iphone can require ipv6 apps, so can anima.=C2=A0

WG] +1. Further, I strongly b= elieve that when considering future network management models, the manageme= nt overhead of maintaining dual-stack indefinitely is fairly high, and in a= reas where an operator controls both sides of the equipment, a targeted move to IPv6-only is far more feas= ible and likely. This is how we and others have deployed IPv6-only applicat= ions on our networks today =E2=80=93 we're not able to turn off IPv4 in= the core anytime soon, but we're certainly able to force new applications that operate only between equipment that we= own and manage to use only IPv6 to prevent us from having to find IPv4 add= resses to manage the elements involved, especially at large scale. And for = those legacy applications and systems that can't do IPv6 and are cost-prohibitive to upgrade, the same is li= kely true for adding support for Anima.=C2=A0

More generally: Lee and I pos= ed the question to IESG of whether it's appropriate to continue adding = new features to IPv4 after seeing no fewer than 3 recent drafts that all ad= d new features into IPv4:=C2=A0
draft-du-anima-ipv4-ac= p=C2=A0=C2=A0"Autonomic Control Plane Based on IPv4=C2=B2

draft-jiang-dhc-sedhcp= v4 "Secure DHCPv4"

draft-ietf-tsvwg-natsu= pp "Stream Control Transmission Protocol (SCTP) Network Address Transl= ation Support"

Is it time to resurrect this = draft and push it forward? It doesn't explicitly prohibit work of the t= ype proposed in the above drafts, but I'd like to think that =C2=A0the = current language strongly discourages it.=C2=A0

Wes George


= Yes.=C2=A0 We clearly see that folks need the message to be unambiguous

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.
--e89a8f642b06edc5f1051d08924c-- From nobody Tue Aug 11 17:47: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 0CFE61A1B5C for ; Tue, 11 Aug 2015 17:47:40 -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 lhj5wQpajH2V for ; Tue, 11 Aug 2015 17:47:38 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id BD0E01A1B59 for ; Tue, 11 Aug 2015 17:47:37 -0700 (PDT) Received: from [127.0.0.1] (unknown [123.123.250.123]) by centos (Coremail) with SMTP id AQAAf3Bb2AdTl8pVT37nAA--.36082S5; Wed, 12 Aug 2015 08:46:18 +0800 (CST) Message-ID: <55CA979F.9010403@cernet.edu.cn> Date: Wed, 12 Aug 2015 08:47:27 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf3Bb2AdTl8pVT37nAA--.36082S5 X-Coremail-Antispam: 1UD129KBjvdXoW7XFyxKw48tr4rGFy8uFyrtFb_yoWftrcEkr 1I9F1jy3yktr10vFs5JFy3A34DXFyFg3Z2y3WUJFZ29348ZFs7Jan7uF17Grn8Z3y3Z3W3 CF9xJFW5G398KjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbbxYjsxI4VWkKwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwA2z4x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwVC2z280aVCY1x0267AKxVWUJVW8Jw AS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2z280 aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxAIw28IcxkI7V AKI48JMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CEj282 c2IF4VAI2VCY07xJMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7 IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k2 6cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x 0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUgtfHDUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Subject: [v6ops] New Version Notification for draft-bao-v6ops-rfc6145bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 00:47:40 -0000 Hi, All, According to the conclusion made in v6ops meeting of IETF93, (removing the EAM part and refer to EAM draft), we have updated the draft-bao-v6ops-rfc6145bis, please review. Thanks. Regards, xing > Name: draft-bao-v6ops-rfc6145bis > Revision: 01 > Title: IP/ICMP Translation Algorithm (rfc6145bis) > Document date: 2015-08-07 > Group: Individual Submission > Pages: 38 > URL: https://www.ietf.org/internet-drafts/draft-bao-v6ops-rfc6145bis-01.txt > Status: https://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145bis/ > Htmlized: https://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-bao-v6ops-rfc6145bis-01 > > Abstract: > This document describes the Stateless IP/ICMP Translation Algorithm > (SIIT), which translates between IPv4 and IPv6 packet headers > (including ICMP headers). This document updates RFC 6145. > > > From nobody Tue Aug 11 18: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 E189F1A1BAA; Tue, 11 Aug 2015 18:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, 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 sTaP5OBiW191; Tue, 11 Aug 2015 18:47:32 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 AFD191A1BB8; Tue, 11 Aug 2015 18:47:32 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so103300198igb.0; Tue, 11 Aug 2015 18:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C/KNfGukBDUeeDnpg7T5MBjNvLEPiZU+4XEUvn7LVSU=; b=tHU6bOHeUJ7CiV97xdfPWqkqW/JUmoLNEl9CVAcZapT0rt5zxiYb3tVNQ5ER9r2vJH DJT1UCdPlNk9DHyvPkfmMNnHhy4HfOCjxbiqlK3BiXoY236DAlM0QMotKLBrMNRoA6ww bKwkaznuQ3VBRZRioCfhMcB7sl7Z0krgqJxA8SP7Xy+qVjZ26YXNZdlQrYgmvSYIL95K 8RMwgka6gYcxWdQIf4rPOsrxEpwsiSvSTVqQCBybfoDGLfs33hrQ6bAj0BtVfbo2VRf9 KF0yhYA1ku/tZswy856KApgseYwACJ3ICTFQO/HSfGG5yzNntGjGYP5/GfmPAAz2S2at 5tTQ== X-Received: by 10.50.64.147 with SMTP id o19mr22094961igs.15.1439344052086; Tue, 11 Aug 2015 18:47:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Tue, 11 Aug 2015 18:46:59 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Wed, 12 Aug 2015 11:46:59 +1000 Message-ID: To: Ca By Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Aug 2015 01:47:34 -0000 On 11 August 2015 at 22:52, Ca By wrote: > > > On Tuesday, August 11, 2015, George, Wes wrote: >> >> >> From: v6ops on behalf of Ca By >> >> Date: Friday, July 31, 2015 at 9:37 AM >> >> On Thursday, July 30, 2015, Toerless Eckert wrote: >>> >> >> Is it time to resurrect this draft and push it forward? It doesn't >> explicitly prohibit work of the type proposed in the above drafts, but I'd >> like to think that the current language strongly discourages it. >> https://tools.ietf.org/html/draft-george-ipv6-support-03 >> >> Wes George > > > > Yes. We clearly see that folks need the message to be unambiguous > Deprecating IPv4 would do the trick. Doesn't mean you can't use it, doesn't mean it can't continue to be fixed, just means that it has become the legacy Internet protocol. "Will IPv4 be formally deprecated when IPv6 is good enough ?" https://www.ietf.org/mail-archive/web/ipv6/current/msg00295.html Regards, Mark. From nobody Wed Aug 12 06:25: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 07C001B2DB3; Wed, 12 Aug 2015 06:25:26 -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 ibreITEuyTHY; Wed, 12 Aug 2015 06:25:24 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF161A89A9; Wed, 12 Aug 2015 06:25:23 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,661,1432612800"; d="scan'208";a="347145676" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Aug 2015 09:21:22 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 12 Aug 2015 09:25:22 -0400 From: "Howard, Lee" To: Mark Smith , Ca By Date: Wed, 12 Aug 2015 09:25:21 -0400 Thread-Topic: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) Thread-Index: AdDVAlb9pnr/cKSoRDeZvs3nCaoNFA== 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.5.2.150604 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Aug 2015 13:25:26 -0000 > >>> >>> Is it time to resurrect this draft and push it forward? It doesn't >>> explicitly prohibit work of the type proposed in the above drafts, but >>>I'd >>> like to think that the current language strongly discourages it. >>> https://tools.ietf.org/html/draft-george-ipv6-support-03 >>> >>> Wes George >> >> >> >> Yes. We clearly see that folks need the message to be unambiguous >> > >Deprecating IPv4 would do the trick. Doesn't mean you can't use it, >doesn't mean it can't continue to be fixed, just means that it has >become the legacy Internet protocol. I searched in vain for an IETF definition of =B3Deprecated,=B2 although I d= id find some examples. I found a definition of =B3Historic=B2 (sort of) in rfc2026 and an old clarifying draft draft-yevstifeyev-genarea-historic-03. All of those words seem to suggest that the deprecated/historic/obsolete protocol could still be used, but to be careful with it. I=B9d call it a SHOULD NOT, meaning don=B9t unless you have a really good reason. I would be delighted if somebody has pointers to better definitions. This work would need to happen in 6man or intarea WG, I think. I therefore offer no opinion here. 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 Aug 12 06: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 D28D01B2DD3; Wed, 12 Aug 2015 06:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, 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 dwcfzed5G1gy; Wed, 12 Aug 2015 06:36:54 -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 9F7981A0094; Wed, 12 Aug 2015 06:36:22 -0700 (PDT) Received: by igbij6 with SMTP id ij6so111666451igb.1; Wed, 12 Aug 2015 06:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ViWwAc4s6QRVlhiyq8AtN/2XrhunXRGggDpKP6b68sw=; b=ZKbFow+wTeaOlR6AWk3m+5E42DspEPV3MkDIMS8kdH4DaQ6c/lgkBXQBCOxju7iCGg Hhz2E23tyUWG9HzHaN9cn7lpnmXyUeVCF23F5i+rtBBHCubnqE3PWWfZNYXm4q8tJ9jr sKs23QcMgZBGL4JHCHB6O2m1mHvceyg8lZ8WYLR63fp62pWA/4K2pxpZLVdp6HunR2FW seoik7ToYgYpboN5cv+M15j6RrEeGk2bmPei6/8kjvd4prTOp2rJ8zXI6U2ob4nZ5y6K J7SsXsLhUAIYT2HTim6JgONU+IOW4XuGX8J95SBhcM4Ai/X72jjsoUfV4l7JtbNJb5av FASA== X-Received: by 10.50.112.73 with SMTP id io9mr23948836igb.18.1439386582147; Wed, 12 Aug 2015 06:36:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Wed, 12 Aug 2015 06:35:52 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Wed, 12 Aug 2015 23:35:52 +1000 Message-ID: To: "Howard, Lee" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "behave@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Aug 2015 13:36:56 -0000 On 12 August 2015 at 23:25, Howard, Lee wrote: > >> >>>> >>>> Is it time to resurrect this draft and push it forward? It doesn't >>>> explicitly prohibit work of the type proposed in the above drafts, but >>>>I'd >>>> like to think that the current language strongly discourages it. >>>> https://tools.ietf.org/html/draft-george-ipv6-support-03 >>>> >>>> Wes George >>> >>> >>> >>> Yes. We clearly see that folks need the message to be unambiguous >>> >> >>Deprecating IPv4 would do the trick. Doesn't mean you can't use it, >>doesn't mean it can't continue to be fixed, just means that it has >>become the legacy Internet protocol. > > I searched in vain for an IETF definition of =C2=B3Deprecated,=C2=B2 alth= ough I did > find some examples. > I found a definition of =C2=B3Historic=C2=B2 (sort of) in rfc2026 and an = old > clarifying draft draft-yevstifeyev-genarea-historic-03. > All of those words seem to suggest that the deprecated/historic/obsolete > protocol could still be used, but to be careful with it. I=C2=B9d call it= a > SHOULD NOT, meaning don=C2=B9t unless you have a really good reason. > I would be delighted if somebody has pointers to better definitions. > Hmm, I've thought the term "deprecated" was in more common use in the IETF, as it has been in the context of protocols that I've learnt the definition of the word - it means it'll still work, but isn't the best or recommended way to solve the problem. SHOULD NOT would be the same thing. Regards, Mark. > This work would need to happen in 6man or intarea WG, I think. I therefor= e > offer no opinion here. > > Lee > > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight 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 t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. From nobody Wed Aug 12 06:52:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091581B2E1D for ; Wed, 12 Aug 2015 06:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEn2YJxCw4GQ for ; Wed, 12 Aug 2015 06:52:06 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (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 8A1E01B2E1A for ; Wed, 12 Aug 2015 06:52:06 -0700 (PDT) Received: by obbop1 with SMTP id op1so13008634obb.2 for ; Wed, 12 Aug 2015 06:52:06 -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=qRw7Nl3Su/1f1Q3sHCMg73+cZQG2ebm+jI4hWtF9N0o=; b=csSsUoFkCBc6ScqRyrfe4JQYntyK13qvau+VHXN9eQGMv7enk4ndj+R1NVxOGGs7rr 4rQbzlSobJZ3mQd74RY75C0+lH3dLwHnb+ilMn0z0BO0uD6ZvrJOAl+EXfBwqeI095B/ KohrRLmpji4143tBUOQ+EE3/40s0GVnumNx0docppkd2m+anS/cPl4FBriec9fwU9srd ogdUT5clOQdaAT04sSaJhv7OlvKwM3DCQ0ETsOrHuMjwOFZnAkfvPE9X6QJK3ZkFY9ll l7v1pBYeekThzsJ4Et/mnD+uNmdw1Zq96oh9w33X77nezPBQeWq9j47U9yAZFNcn+OuG RoOQ== X-Gm-Message-State: ALoCoQlVmVxgUPlJUagb+q6wq0KW4zVw7LyjNEk8004fXbesNgye4OMo764T6FIxvz24li1p95pL MIME-Version: 1.0 X-Received: by 10.60.78.230 with SMTP id e6mr31563017oex.24.1439387525963; Wed, 12 Aug 2015 06:52:05 -0700 (PDT) Received: by 10.182.94.228 with HTTP; Wed, 12 Aug 2015 06:52:05 -0700 (PDT) X-Originating-IP: [2001:13c7:7001:2128:74f4:eca9:24a:a36d] In-Reply-To: References: Date: Wed, 12 Aug 2015 10:52:05 -0300 Message-ID: From: George Michaelson To: "behave@ietf.org" Content-Type: multipart/alternative; boundary=089e0111b2a22e1008051d1d868b Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Aug 2015 13:52:09 -0000 --089e0111b2a22e1008051d1d868b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Would it be worth modelling the inclusion of DEPRECATED as a new normative word, and rehearse what exactly we'd want it to mean? -George On Wed, Aug 12, 2015 at 10:35 AM, Mark Smith wrote= : > On 12 August 2015 at 23:25, Howard, Lee wrote: > > > >> > >>>> > >>>> Is it time to resurrect this draft and push it forward? It doesn't > >>>> explicitly prohibit work of the type proposed in the above drafts, b= ut > >>>>I'd > >>>> like to think that the current language strongly discourages it. > >>>> https://tools.ietf.org/html/draft-george-ipv6-support-03 > >>>> > >>>> Wes George > >>> > >>> > >>> > >>> Yes. We clearly see that folks need the message to be unambiguous > >>> > >> > >>Deprecating IPv4 would do the trick. Doesn't mean you can't use it, > >>doesn't mean it can't continue to be fixed, just means that it has > >>become the legacy Internet protocol. > > > > I searched in vain for an IETF definition of =C2=B3Deprecated,=C2=B2 al= though I did > > find some examples. > > I found a definition of =C2=B3Historic=C2=B2 (sort of) in rfc2026 and a= n old > > clarifying draft draft-yevstifeyev-genarea-historic-03. > > All of those words seem to suggest that the deprecated/historic/obsolet= e > > protocol could still be used, but to be careful with it. I=C2=B9d call = it a > > SHOULD NOT, meaning don=C2=B9t unless you have a really good reason. > > I would be delighted if somebody has pointers to better definitions. > > > > Hmm, I've thought the term "deprecated" was in more common use in the > IETF, as it has been in the context of protocols that I've learnt the > definition of the word - it means it'll still work, but isn't the best > or recommended way to solve the problem. SHOULD NOT would be the same > thing. > > Regards, > Mark. > > > > This work would need to happen in 6man or intarea WG, I think. I > therefore > > offer no opinion here. > > > > Lee > > > > > > > > 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 th= at > 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 o= f > this E-mail and any printout. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e0111b2a22e1008051d1d868b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would it be worth modelling the inclusion of DEPRECATED as= a new normative word, and rehearse what exactly we'd want it to mean?<= div>
-George

On Wed, Aug 12, 2015 at 10:35 AM, Mark Smith <ma= rkzzzsmith@gmail.com> wrote:
On 12 August 2015 at 23:25, Howard, Lee <lee.howard@twcable.com> wrote:
>
>>
>>>>
>>>> Is it time to resurrect this draft and push it forward? It= doesn't
>>>> explicitly prohibit work of the type proposed in the above= drafts, but
>>>>I'd
>>>> like to think that=C2=A0 the current language strongly dis= courages it.
>>>> https://tools.ietf.org/html= /draft-george-ipv6-support-03
>>>>
>>>> Wes George
>>>
>>>
>>>
>>> Yes.=C2=A0 We clearly see that folks need the message to be un= ambiguous
>>>
>>
>>Deprecating IPv4 would do the trick. Doesn't mean you can't= use it,
>>doesn't mean it can't continue to be fixed, just means that= it has
>>become the legacy Internet protocol.
>
> I searched in vain for an IETF definition of =C2=B3Deprecated,=C2=B2 a= lthough I did
> find some examples.
> I found a definition of =C2=B3Historic=C2=B2 (sort of) in rfc2026 and = an old
> clarifying draft draft-yevstifeyev-genarea-historic-03.
> All of those words seem to suggest that the deprecated/historic/obsole= te
> protocol could still be used, but to be careful with it. I=C2=B9d call= it a
> SHOULD NOT, meaning don=C2=B9t unless you have a really good reason. > I would be delighted if somebody has pointers to better definitions. >

Hmm, I've thought the term "deprecated" was in more co= mmon use in the
IETF, as it has been in the context of protocols that I've learnt the definition of the word - it means it'll still work, but isn't the b= est
or recommended way to solve the problem. SHOULD NOT would be the same
thing.

Regards,
Mark.


> This work would need to happen in 6man or intarea WG, I think. I there= fore
> offer no opinion here.
>
> Lee
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright 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 no= t the intended recipient of this E-mail, you are hereby notified that any d= issemination, distribution, copying, or action taken in relation to the con= tents of and attachments to this E-mail is strictly prohibited and may be u= nlawful. If you have received this E-mail in error, please notify the sende= r immediately and permanently delete the original and any copy of this E-ma= il and any printout.

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

--089e0111b2a22e1008051d1d868b-- From nobody Thu Aug 13 09:47: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 422C61A1ADC; Thu, 13 Aug 2015 09:47:07 -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_40=-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 28oa1CX49O-U; Thu, 13 Aug 2015 09:47:04 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573E41A1B12; Thu, 13 Aug 2015 09:47:03 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.167.91) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 13 Aug 2015 16:46:46 +0000 Message-ID: <02ab01d0d5e7$c4e75140$4001a8c0@gateway.2wire.net> From: t.petch To: "Howard, Lee" , Mark Smith , Ca By References: Date: Thu, 13 Aug 2015 17:47:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.91] X-ClientProxiedBy: HE1PR05CA0045.eurprd05.prod.outlook.com (25.164.28.13) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 2:SxXWBQeAMd/q0Tx+Aa0lfDeevkcqcAAN8q/mRLIzrRtjCvrgL3XEA8WsG4SpLj0XVWdBADp0pmJ5D10tKRm3y5oaaGmyFbkQ172En+Hhcl4iOcTOThxf2a4rFURNvVs/S0gBdhpMz0gzFrgmmLdghv9iNegN4wB/EjJQA/f28fM=; 3:jxi+eiONeJbqTOcXrm5uq1I953G5wSBrZfUncVuSZ/20bPHibkLFhDaZEhPvmQsb0c86DKgFh3mDPpolA83eIBRt4n6Gkv7AmDZOThaPKTyTEmAbnNNCvyyZIl/2hMYepsoPUz+SbwJGuqY1MkJwlg==; 25:YTF+5XtmXEUDNrXhK9mAslxXGtFSgjU0RHOUweW8+GW2C48qeaejIa/TEcWxbnJChw1/ssIiyvUPVgZW0gqD2SsP7rj5lfatf3htI9bgIVrxpWmjKfN7q3Z+gvBOBsmc65Ku3ThQLEeFRQ85roAn9nFvI7fNJ1GhDZrLW/O/LmyDtFWbvc+aTXm9kpjH/exk543S8BYg8S+2IOpurYvdExIc2pB9NsEcDY02Bgys2xpV076RJ+JEeTDG4T94BnS3sfJ+DyayIDrz8yG2ZdJlLw==; 4:ADxVy0AsCSNDV05uUVNFyTAbWgBMEN9IeP0/zkiAUStoPfPzPOlz0olqXaehTCE5GkDHxjUEpay27DzIjRf/bZci1J04rtcwoXkt5CZiIWwJlRXy4wYxTcoTidY8+ql0kXjWOmve9UgTNbz7BSWqclac77B/WBcL4GQOma2RqDLrSR1MXXbnckmeWpqRq5Ad0IucPFC9ZwEW5HHF2s/Gy5nv7nXawImMkJvA8IaVp9p77iFcVjQ9SXezDVRpXjKZY69vevFiQVcxlCzhIZ3a6Llqf0wYbbBdUVjWcR5rI/M= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMSPR07MB052; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB052; X-Forefront-PRVS: 0667289FF8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(13464003)(4001540100001)(50226001)(84392001)(81156007)(61296003)(5001960100002)(105586002)(64706001)(5001860100001)(97736004)(33646002)(86362001)(1556002)(106356001)(47776003)(19580395003)(50466002)(5001830100001)(189998001)(87976001)(23756003)(44736004)(44716002)(62966003)(66066001)(122386002)(15975445007)(93886004)(116806002)(101416001)(5001770100001)(1456003)(81686999)(5890100001)(19580405001)(14496001)(77096005)(42186005)(50986999)(77156002)(76176999)(68736005)(92566002)(46102003)(62236002)(40100003)(81816999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMSPR07MB052; 23:UtASZy3gjBrBK8ex5XqjIBbD3ebAl9mePC4/9eXb?= =?iso-8859-1?Q?C6lo8tU5sRgzDPHMDOdQ6RAVVOxogc2qXAIDDsFAujT3/+P8oRwaFtG2SN?= =?iso-8859-1?Q?6f69VXe0PFeOfDcsLIVgVc+0hIowzRfu4j5SPImCA4M/6vbnNGNe8zkegZ?= =?iso-8859-1?Q?XvJfIDGobEPDU4qTFhpOE0HJ6n/Ver4BsHBab0NrrwRfXPLv4h0xwfcCls?= =?iso-8859-1?Q?F2yxx0HdIvmqBWO3fDRJc3cS0790HVw42/pGa2bhKB9bKf4YJuxBl5EBYi?= =?iso-8859-1?Q?5aTgZBq8g89oT9nGZWWjYJBhgJNlstaWbxOMnIPJakxjB7Zv5ZMwKUcrY3?= =?iso-8859-1?Q?Xpxr5ykcE9VBAK1Z2jbwekp4h60NApEBakIqQ/tK+kubkYcidHBkDmCfoh?= =?iso-8859-1?Q?3xHGdk/0F0dWoPFwIGwI+6qL/ZTE41/wbhs6WPUt1F3Eq7ynkRCRjTEQQX?= =?iso-8859-1?Q?75fUq2r2/cfVy4MKEWkAPDHFS+yhfcd/W351yCimtShaks/NbRqvbyTgV+?= =?iso-8859-1?Q?XIMISMXQDDxC7fzikvJ04IEUmAVcGsLniOtkJ97iaIKTPsiP5xHNl2Zork?= =?iso-8859-1?Q?GprWSea3oXLO9ck8H+6y1HKGdhtXXCld0sKLIRqHG1+KDbIgDBKjNww+tE?= =?iso-8859-1?Q?OvrYpmrt7zvxcptu8l+BJdPIcdIcIgK25Zg22o+3qNXCmUgArXiyd0edNI?= =?iso-8859-1?Q?6g4R72/+ZAYKiOAnFlQP+/+yId/LvvCPRn0LPlTDAXecYxhMds5atwm2wj?= =?iso-8859-1?Q?XUT6AdSv9nk3Tzg5M5Wl9YK1oDaBj3u9N2U8Y6VyU3x2YRrMbZZelq9GCt?= =?iso-8859-1?Q?xTWSwopLWrzOxoFk3foSj5JMCiehjHjw8JhMCp77x93YJo/y3ZqO8WvASE?= =?iso-8859-1?Q?kHAmOl1T3zfxGsb5/MghJWpfQfEw885y6rKnubOmvEOxmug+7dLCMkxlO+?= =?iso-8859-1?Q?zgK4OTDuCgaype689Anf0oqtaRoChwPD3/uvYk3pqs09dExIM5pVrIjBgP?= =?iso-8859-1?Q?zLk7hd9/CQ1J7OtCTWUxt/pgFmnP9Xo43TnFVhH41krkLCMgSlyxigZmhn?= =?iso-8859-1?Q?4wOd+XdUsp64qYx0InnaqHj/2GJYg5Fu3uBTAy5oO1gaQlQwlERB6KM3IH?= =?iso-8859-1?Q?F23VFxC3EbABYAuKVgfRt2ZukNlTVQ0gNrK8RcIRnSMolk76YFrF068UBi?= =?iso-8859-1?Q?ltooRfRU5WSoRiFBt41zgQZ6n7PQnM8DgylUQAXRpdGE0GIVNpOMzheEtp?= =?iso-8859-1?Q?m0sZbr5PLmE8dieG97mjmb4L3cHm9M9SMHGQECSDfdq3hMWwDQ/4w0ZCui?= =?iso-8859-1?Q?ARbMYCqa1JylcbQftWGw7vLQHtf2ZEo9ybQej76LjurebcvSUGEULVqH7T?= =?iso-8859-1?Q?jFxzJ0U/uF1yE90Ss9+hL3vj4Elu6IUlnPUd68NZZli24milrVg7AE8tXW?= =?iso-8859-1?Q?WbCUm0XgwVEwg=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 5:IgmnFLw9eIi4j0IEGAGJfYBA4n1BRJqVz8Fo6Yhve96ZVJbtc9WQmgcbavM5v/0bFLZIEW+pDVpofai7lGFebHbukkxwLkHU4fWpZuYLp7hWs4/7sKoDWINd7wvPNOwsytRxKpqUeEZDtyo6MtwUSg==; 24:+4dkTZJR8N8gUowqIHmdSNZPKtWXov41HQYZ6WYZaGgj9ECD5rpq981qtUfJf7HTDfnr7OY2IG/EOSeQET0XpDhRHjbOdFjCG4nnPDqLpT4=; 20:C6ttviou4sdTmlQTICezck/5OePIqPxeAO+zvIvEDbNZd7ci6Xva0HR8FhdxxsyOJ+qdKgOzz2MwsMH6w5rrXg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2015 16:46:46.3604 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB052 Archived-At: Cc: v6ops@ietf.org, behave@ietf.org Subject: Re: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Aug 2015 16:47:07 -0000 ----- Original Message ----- From: "Howard, Lee" To: "Mark Smith" ; "Ca By" Cc: ; Sent: Wednesday, August 12, 2015 2:25 PM >>> >>> Is it time to resurrect this draft and push it forward? It doesn't >>> explicitly prohibit work of the type proposed in the above drafts, but >>>I'd >>> like to think that the current language strongly discourages it. >>> https://tools.ietf.org/html/draft-george-ipv6-support-03 >>> >>> Wes George >> >> Yes. We clearly see that folks need the message to be unambiguous >> >Deprecating IPv4 would do the trick. Doesn't mean you can't use it, >doesn't mean it can't continue to be fixed, just means that it has >become the legacy Internet protocol. I searched in vain for an IETF definition of ³Deprecated,² although I did find some examples. Howard I saw 'deprecated' used in an IANA registry 29aug2013 and raised the issue of a lack of definition on the main ietf list. Since then, 5226bis has been updated to say that the term is in use but should not be. The term has long had a well-defined meaning in SMI. Tom Petch I found a definition of ³Historic² (sort of) in rfc2026 and an old clarifying draft draft-yevstifeyev-genarea-historic-03. All of those words seem to suggest that the deprecated/historic/obsolete protocol could still be used, but to be careful with it. I¹d call it a SHOULD NOT, meaning don¹t unless you have a really good reason. I would be delighted if somebody has pointers to better definitions. This work would need to happen in 6man or intarea WG, I think. I therefore offer no opinion here. Lee 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 From nobody Thu Aug 13 11:43: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 89F211B2E06; Thu, 13 Aug 2015 11:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 0k2mzV1D4n3J; Thu, 13 Aug 2015 11:43:49 -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 3F8D31AC3E3; Thu, 13 Aug 2015 11:43:46 -0700 (PDT) Received: by obbhe7 with SMTP id he7so44052550obb.0; Thu, 13 Aug 2015 11:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hqqKdc3huXn5Em+QSaMEqWxt3xBeib6h1W92UvuTQ/g=; b=sHFNdHy21SfdbpClMvOZZOX976f48nl1zsGauehX+ykD1pOzh5VPDfPlUs6S9IT4BF DXhmoGQNIkOxdpHzdC8OlHYcFPegdLuhLjVbsfrE0fzW3re08OCxJxgVaIWFvdtME0aB 4IiASsEjUdSAhw9Vq1Q090vMGh2zBdKuf1lFN310BbNKnWOGibvOwln1TggnpLd1lB5f yXzCbqj86eRu59qwb4wB/wLCDvG4ggwZOAJ5Zs0i42HYcs1LonhR+dCN+fOYEuixnbD5 0A9/wjRHs/YJ+gKlV9Sn+OtYgszmRSnuRTSVaO+XbwGdCF81RxSSW22Je/m1B5S061SD UrWA== X-Received: by 10.182.120.100 with SMTP id lb4mr32241975obb.71.1439491425593; Thu, 13 Aug 2015 11:43:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.94.131 with HTTP; Thu, 13 Aug 2015 11:43:06 -0700 (PDT) In-Reply-To: References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> <559B5A2C.6090204@gmail.com> From: "Mukom Akong T." Date: Thu, 13 Aug 2015 14:43:06 -0400 Message-ID: To: IPv6 Operations Content-Type: multipart/alternative; boundary=089e013a098c147edf051d35b77e Archived-At: Cc: draft-ietf-v6ops-design-choices@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 18:43:56 -0000 --089e013a098c147edf051d35b77e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Table at top of page 3 states "Works" for certain choices. I think it will be effective to more specific about what 'Works' means in this context. As this document is heavily L3 focused, perhaps defining 'Works' in terms of "L3 routing and forwarding functions as expected without ....." [snip] +---------+------------+-------------------+------------------------+ | PA | Tunneled | Works. Using | Works. Using private | | | | private addresses | addresses likely | | | | likely better | better option. | | | | option. | | +---------+------------+-------------------+------------------------+ [snip] Like Mike, I'd think some more clarifications need to be made as to why private is a better option than PA. - I'd rather have "works but PI is a better option" - I'd be curious to know that what On 9 July 2015 at 04:25, Mark Smith wrote: > On 7 July 2015 at 14:48, Brian E Carpenter > wrote: > > Hi, > > > > I don't understand why you mention RFC 1918 in a document about > > IPv6 deployment. > > > > In the table in 2.1.1, I object strongly to the comment against > > private (i.e. ULA) addresses > > "Will probably require some sort of NAT on links to the Internet." > > > > That isn't the architecture. The architecture is that nodes have multip= le > > addresses, and only use ULAs for internal traffic, and use PA or PI > addresses > > for Internet traffic. > > I agree. > > Unless you're using link-locals only in your network (and that isn't > really possible for the edge networks), there is always an address > selection process going on between the always present link-locals and > the other address or addresses that are available. > > Perhaps it isn't that common knowledge that link-local addresses are > quite valid to be used by/for applications, as per RFC4007, and are > normally preferred over all other address types if they're available > to the application, excepting the loopback prefix, because link-locals > have the second smallest scope (and the smallest scope is preferred). > > In other words, most IPv6 networks are multi-prefix even if their > operators think they aren't because they "only" have a single GUA. > This is probably worth more visibly highlighting or emphasising in > this draft, because it seems to be something that is commonly > forgotten or not completely realised. > > > We shouldn't be documenting any other usage of > > ULAs. We shouldn't be making statements like this: > > > > "For an enterprise, the use of private address space is > > reasonable, but the enterprise will need to use NAT44 and/or > > NPT[RFC6296] on links to the Internet." > > > > We clearly can't pretend that NAT44 isn't widely used, but IMHO it shou= ld > > be completely out of scope in this document, and NPTv6 is an experiment= al > > RFC that we should never recommend. ULAs should *only* be used in > parallel > > with PA or PI. That isn't an afterthought; that is the basic intention > behind > > ULAs. > > > > I've thought that if it is unacceptable for devices inside your > network to have global addresses, then your security requirements are > probably so stringent that NPTv6 devices, packet filters and stateful > firewalls would be too simple to achieve and implement them. Instead, > you'd use application layer proxies for specific applications you > permit, that act on behalf of and completely or near completely hide > the identity of the devices inside your network, and prevent any > possible reachability to those devices, inherent in ULA addressing, > unless the application layer proxy itself is compromised. > > If using per-application application layer proxies is considered too > onerous or costly, then I think the security measures you'd have in > place (e.g., host firewalls, network perimeter firewalls/packet > filters) would mean there is less risk to deploying global addresses > internally compared to the benefits of having them. > > > > Regards, > Mark. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --089e013a098c147edf051d35b77e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Table at top of page 3 states "Works" for certai= n choices. I think it will be effective to more specific about what 'Wo= rks' means in this context. As this document is heavily L3 focused, per= haps defining 'Works' in terms of "L3 routing and forwarding f= unctions as expected without ....."


= [snip]

=C2=A0 +---------+------------+-------= ------------+------------------------+
=C2=A0 =C2=A0| =C2=A0 =C2= =A0PA =C2=A0 | =C2=A0Tunneled =C2=A0| =C2=A0 =C2=A0Works. Using =C2=A0 | = =C2=A0Works. Using private =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| private addresse= s | =C2=A0 =C2=A0addresses likely =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 likely better =C2=A0 | =C2=A0 =C2=A0 better option. =C2=A0 =C2=A0 |<= /div>
=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=A0option. =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+---------+------------+----------------= ---+------------------------+

[snip]

Like Mike, I'd think some more clarifications need to= be made as to why private is a better option than PA.=C2=A0

=
- I'd rather have "works but PI is a better option"= ;=C2=A0
- I'd be curious to know that what=C2=A0

On = 9 July 2015 at 04:25, Mark Smith <markzzzsmith@gmail.com> wrote:
On 7 July 2015= at 14:48, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> Hi,
>
> I don't understand why you mention RFC 1918 in a document about > IPv6 deployment.
>
> In the table in 2.1.1, I object strongly to the comment against
> private (i.e. ULA) addresses
> "Will probably require some sort of NAT on links to the Internet.= "
>
> That isn't the architecture. The architecture is that nodes have m= ultiple
> addresses, and only use ULAs for internal traffic, and use PA or PI ad= dresses
> for Internet traffic.

I agree.

Unless you're using link-locals only in your network (and that isn'= t
really possible for the edge networks), there is always an address
selection process going on between the always present link-locals and
the other address or addresses that are available.

Perhaps it isn't that common knowledge that link-local addresses are quite valid to be used by/for applications, as per RFC4007, and are
normally preferred over all other address types if they're available to the application, excepting the loopback prefix, because link-locals
have the second smallest scope (and the smallest scope is preferred).

In other words, most IPv6 networks are multi-prefix even if their
operators think they aren't because they "only" have a single= GUA.
This is probably worth more visibly highlighting or emphasising in
this draft, because it seems to be something that is commonly
forgotten or not completely realised.

> We shouldn't be documenting any other usage of
> ULAs. We shouldn't be making statements like this:
>
> "For an enterprise, the use of private address space is
> reasonable, but the enterprise will need to use NAT44 and/or
> NPT[RFC6296] on links to the Internet."
>
> We clearly can't pretend that NAT44 isn't widely used, but IMH= O it should
> be completely out of scope in this document, and NPTv6 is an experimen= tal
> RFC that we should never recommend. ULAs should *only* be used in para= llel
> with PA or PI. That isn't an afterthought; that is the basic inten= tion behind
> ULAs.
>

I've thought that if it is unacceptable for devices inside your<= br> network to have global addresses, then your security requirements are
probably so stringent that NPTv6 devices, packet filters and stateful
firewalls would be too simple to achieve and implement them. Instead,
you'd use application layer proxies for specific applications you
permit, that act on behalf of and completely or near completely hide
the identity of the devices inside your network, and prevent any
possible reachability to those devices, inherent in ULA addressing,
unless the application layer proxy itself is compromised.

If using per-application application layer proxies is considered too
onerous or costly, then I think the security measures you'd have in
place (e.g., host firewalls, network perimeter firewalls/packet
filters) would mean there is less risk to deploying global addresses
internally compared to the benefits of having them.

<snip>

Regards,
Mark.

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



--
=

Mukom Akong T.

http://about.me/perfexcellence | =C2=A0twitter: @perfexcellent
-------------------------------= ---------------------------------------------------------------------------= --------------------------------
=E2=80=9CWhen you work, you are the FLU= TE through whose lungs the whispering of the hours turns to MUSIC" - K= ahlil Gibran
-----------------------------------------------------------= ---------------------------------------------------------------------------= -----
--089e013a098c147edf051d35b77e-- From nobody Thu Aug 13 16:10: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 0C6CD1ACE9C for ; Thu, 13 Aug 2015 16:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDtYsRYte0DD for ; Thu, 13 Aug 2015 16:10:04 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id E125D1ACEC7 for ; Thu, 13 Aug 2015 16:10:03 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 13 Aug 2015 18:10:02 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-io0-f178.google.com [209.85.223.178] #+LO+TS+TR X-Umn-Classification: local Received: by iodb91 with SMTP id b91so68147249iod.1 for ; Thu, 13 Aug 2015 16:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=Bvco0VYDlQLitTJR3dXPEuufX8vB0XE6y/dDvdgrJhI=; b=L9108dyPiNDhFgEmkyGD0+3aEtaFraCcDdJ7O0znwTxLFmRr5ko3bXLC9+eUmEL+lo m6rcyNchJfUVrdWQINIDRzNcq/4iNgM85qDLhgQqcEJttZJqHTyCCdeSviUgcQI4pyBq LxqXSCn7fj3QssuFpD8zjsq885djUEcipsV5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=Bvco0VYDlQLitTJR3dXPEuufX8vB0XE6y/dDvdgrJhI=; b=Ny52T+UX+9Tms3Gtavw9pMjeSr3OfKr+OOAp2bOOSnmow2xj64VfXq5soshVKN9YZu LiorqZKszlDqOLmPW7aN9Yxn5amKrnYP1lucFNuFummd7M3itrbQnEAF2Rcc3slS7J0q ECYtumObmp+IujpZjV/YMXrNoG1F8Ws7QhSj4Y7Ie9C1uLhJG4ZTuA/uEaexXnN0LyfO FIfJS7oXij0w49MTlTqmkwcmC8O7o4lwnEm1xbV0waw1w+qZeoRvBBS3e/nsiZ6D/RF/ wGEeafLfyJNfO9aEnHErC2Q/x+zRcxKhrnSBpbkAJ2itYeR9cUwMXLHAO87+qJKRT6HS eLIA== X-Gm-Message-State: ALoCoQla2tvclF79rdGOxwc98a+h73GpDsDsXcOMZMu/y2HHZn0uycx0TtdLRPnHfzJwYA2J1QfeN8eD56qVel22/w3UtXoXnuLVGHh10seU9oYeu8d/YiZJvstQXdb5FNyodWmsIrsQ X-Received: by 10.107.138.87 with SMTP id m84mr13223692iod.115.1439507401942; Thu, 13 Aug 2015 16:10:01 -0700 (PDT) X-Received: by 10.107.138.87 with SMTP id m84mr13223658iod.115.1439507401490; Thu, 13 Aug 2015 16:10:01 -0700 (PDT) Received: from ?IPv6:2607:ea00:107:2001:78f5:b369:4b3f:b093? ([2607:ea00:107:2001:78f5:b369:4b3f:b093]) by smtp.gmail.com with ESMTPSA id 85sm2608519iot.6.2015.08.13.16.09.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Aug 2015 16:09:59 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-A24E6951-7022-40DC-8A03-80AE2926966F Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (12H143) From: David Farmer Date: Thu, 13 Aug 2015 18:09:58 -0500 To: "Howard, Lee" Archived-At: Cc: "behave@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Aug 2015 23:10:06 -0000 --Apple-Mail-A24E6951-7022-40DC-8A03-80AE2926966F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Aug 12, 2015, at 08:25, Howard, Lee wrote: >>>> Is it time to resurrect this draft and push it forward? It doesn't >>>> explicitly prohibit work of the type proposed in the above drafts, but >>>> I'd >>>> like to think that the current language strongly discourages it. >>>> https://tools.ietf.org/html/draft-george-ipv6-support-03 >>>>=20 >>>> Wes George >>>=20 >>>=20 >>>=20 >>> Yes. We clearly see that folks need the message to be unambiguous >>=20 >> Deprecating IPv4 would do the trick. Doesn't mean you can't use it, >> doesn't mean it can't continue to be fixed, just means that it has >> become the legacy Internet protocol. >=20 > I searched in vain for an IETF definition of =C2=B3Deprecated,=C2=B2 altho= ugh I did > find some examples. > I found a definition of =C2=B3Historic=C2=B2 (sort of) in rfc2026 and an o= ld > clarifying draft draft-yevstifeyev-genarea-historic-03. > All of those words seem to suggest that the deprecated/historic/obsolete > protocol could still be used, but to be careful with it. I=C2=B9d call it a= > SHOULD NOT, meaning don=C2=B9t unless you have a really good reason. > I would be delighted if somebody has pointers to better definitions. >=20 > This work would need to happen in 6man or intarea WG, I think. I therefore= > offer no opinion here. =46rom RFC 7526 "Deprecating the Anycast Prefix for 6to4 Relay Routers", Sec= tion 2; > In this document, the word "deprecate" and its derivatives are used only i= n their generic sense of "criticize or express disapproval" and do not have a= ny specific normative meaning. A deprecated function might exist in the Inte= rnet for many years to allow backwards compatibility. I personally think it is best for the word to not have a normative meaning, a= nd leave it to plain English. If you want/need to normatively tell someone s= omething similar use "SHOULD NOT use", "MUST NOT use", or maybe "SHOULD NOT c= ontinue development" as appropriate. =20 Although this subject seems like excellent fodder for an update to RFC6919. := ) --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail-A24E6951-7022-40DC-8A03-80AE2926966F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Is it time to resurrect this draft and push it forw= ard? It doesn't
exp= licitly prohibit work of the type proposed in the above drafts, but
I'd
=
like to think that  the current langu= age strongly discourages it.
https://tools.ietf.org/html/draft-george-ipv6-support-03

Wes George
=

<= blockquote type=3D"cite">
Yes.  We clearly see t= hat folks need the message to be unambiguous


Deprecating IPv4 would do the trick. Doe= sn't mean you can't use it,
doesn't mean it can't continue to be fixed, just means that it has
become the legacy Inter= net protocol.

I searched in va= in for an IETF definition of =C2=B3Deprecated,=C2=B2 although I didfind some examples.
I found a definition of =C2=B3Hi= storic=C2=B2 (sort of) in rfc2026 and an old
clarifying draf= t draft-yevstifeyev-genarea-historic-03.
All of those words s= eem to suggest that the deprecated/historic/obsolete
protoco= l could still be used, but to be careful with it. I=C2=B9d call it a<= br>SHOULD NOT, meaning don=C2=B9t unless you have a really good reason= .
I would be delighted if somebody has pointers to better de= finitions.

This work would need to happen i= n 6man or intarea WG, I think. I therefore
offer no opinion h= ere.

=46rom RFC 7526 "Depre= cating the Anycast Prefix for 6to4 Relay Routers", Section 2;

= 
<=
pre class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; page-bre=
ak-before: always;">In this document=
, the word "deprecate" and its derivatives are used
   only in their generic sense of "criticize or express disapproval" and
   do not have any specific normative meaning.  A deprecated function
   might exist in the Internet for many years to allow backwards
   compatibility.

=
I personally think=
 it is best for the word to not have a normative meaning, and leave it to pl=
ain English.  If you want/need to normatively tell someone something si=
milar use "SHOULD NOT use", "MUST NOT use", or maybe "SHOULD NOT continue de=
velopment" as appropriate.  

Although this subject seems like excell=
ent fodder for an update to RFC6919. :)

-- 
=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer &nbs=
p;                     &nb=
sp;  Email: farmer@umn.edu
<=
div>Office of Information Technology
University of Minnesota  =
;  
2218 University Ave SE         Phone:=
 +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-81=
2-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D


=

--Apple-Mail-A24E6951-7022-40DC-8A03-80AE2926966F--


From nobody Thu Aug 13 16:29: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 704081ACEC1 for ; Thu, 13 Aug 2015 16:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_FILL_THIS_FORM_SHORT=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 J7i8vpkm2itc for ; Thu, 13 Aug 2015 16:29:29 -0700 (PDT)
Received: from tor-smtp-03.primus.ca (smtp-auth2-146.primus.ca [216.254.140.146]) by ietfa.amsl.com (Postfix) with ESMTP id B34511ACEBD for ; Thu, 13 Aug 2015 16:29:28 -0700 (PDT)
Received: from bas5-ottawa10-3096712248.dsl.bell.ca ([184.148.20.56] helo=[10.0.1.16]) by tor-smtp-03.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1ZQ1w7-0007Hw-TK; Thu, 13 Aug 2015 19:29:28 -0400
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-13--507616925
From: Philip Matthews 
In-Reply-To: 
Date: Thu, 13 Aug 2015 19:29:27 -0400
Message-Id: <17DAA369-EA0F-47FA-86C2-0EA473EB04E6@magma.ca>
References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> <559B5A2C.6090204@gmail.com>  
To: "Mukom Akong T." 
X-Mailer: Apple Mail (2.1085)
X-Authenticated: philip_matthews - bas5-ottawa10-3096712248.dsl.bell.ca ([10.0.1.16]) [184.148.20.56]
Archived-At: 
Cc: IPv6 Operations 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Aug 2015 23:29:31 -0000

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

Hi Mukom and everyone:

Thanks for the comments.  I am on vacation right now but Victor and I =
will get together in a week to work on the revision.

- Philip

On 2015-08-13, at 14:43 , Mukom Akong T. wrote:

> Table at top of page 3 states "Works" for certain choices. I think it =
will be effective to more specific about what 'Works' means in this =
context. As this document is heavily L3 focused, perhaps defining =
'Works' in terms of "L3 routing and forwarding functions as expected =
without ....."
>=20
>=20
> [snip]
>=20
>   =
+---------+------------+-------------------+------------------------+
>    |    PA   |  Tunneled  |    Works. Using   |  Works. Using private  =
|
>    |         |            | private addresses |    addresses likely    =
|
>    |         |            |   likely better   |     better option.     =
|
>    |         |            |      option.      |                        =
|
>    =
+---------+------------+-------------------+------------------------+
>=20
> [snip]
>=20
> Like Mike, I'd think some more clarifications need to be made as to =
why private is a better option than PA.=20
>=20
> - I'd rather have "works but PI is a better option"=20
> - I'd be curious to know that what=20
>=20
>=20
> On 9 July 2015 at 04:25, Mark Smith  wrote:
> On 7 July 2015 at 14:48, Brian E Carpenter =
 wrote:
> > Hi,
> >
> > I don't understand why you mention RFC 1918 in a document about
> > IPv6 deployment.
> >
> > In the table in 2.1.1, I object strongly to the comment against
> > private (i.e. ULA) addresses
> > "Will probably require some sort of NAT on links to the Internet."
> >
> > That isn't the architecture. The architecture is that nodes have =
multiple
> > addresses, and only use ULAs for internal traffic, and use PA or PI =
addresses
> > for Internet traffic.
>=20
> I agree.
>=20
> Unless you're using link-locals only in your network (and that isn't
> really possible for the edge networks), there is always an address
> selection process going on between the always present link-locals and
> the other address or addresses that are available.
>=20
> Perhaps it isn't that common knowledge that link-local addresses are
> quite valid to be used by/for applications, as per RFC4007, and are
> normally preferred over all other address types if they're available
> to the application, excepting the loopback prefix, because link-locals
> have the second smallest scope (and the smallest scope is preferred).
>=20
> In other words, most IPv6 networks are multi-prefix even if their
> operators think they aren't because they "only" have a single GUA.
> This is probably worth more visibly highlighting or emphasising in
> this draft, because it seems to be something that is commonly
> forgotten or not completely realised.
>=20
> > We shouldn't be documenting any other usage of
> > ULAs. We shouldn't be making statements like this:
> >
> > "For an enterprise, the use of private address space is
> > reasonable, but the enterprise will need to use NAT44 and/or
> > NPT[RFC6296] on links to the Internet."
> >
> > We clearly can't pretend that NAT44 isn't widely used, but IMHO it =
should
> > be completely out of scope in this document, and NPTv6 is an =
experimental
> > RFC that we should never recommend. ULAs should *only* be used in =
parallel
> > with PA or PI. That isn't an afterthought; that is the basic =
intention behind
> > ULAs.
> >
>=20
> I've thought that if it is unacceptable for devices inside your
> network to have global addresses, then your security requirements are
> probably so stringent that NPTv6 devices, packet filters and stateful
> firewalls would be too simple to achieve and implement them. Instead,
> you'd use application layer proxies for specific applications you
> permit, that act on behalf of and completely or near completely hide
> the identity of the devices inside your network, and prevent any
> possible reachability to those devices, inherent in ULA addressing,
> unless the application layer proxy itself is compromised.
>=20
> If using per-application application layer proxies is considered too
> onerous or costly, then I think the security measures you'd have in
> place (e.g., host firewalls, network perimeter firewalls/packet
> filters) would mean there is less risk to deploying global addresses
> internally compared to the benefits of having them.
>=20
> 
>=20
> Regards,
> Mark.
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20
>=20
> --=20
>=20
> Mukom Akong T.
>=20
> http://about.me/perfexcellence	|  twitter: @perfexcellent=09
> =
--------------------------------------------------------------------------=
----------------------------------------------------------------
> =93When you work, you are the FLUTE through whose lungs the whispering =
of the hours turns to MUSIC" - Kahlil Gibran
> =
--------------------------------------------------------------------------=
-----------------------------------------------------------------


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

Hi =
Mukom and everyone:

Thanks for the comments.  I =
am on vacation right now but Victor and I will get together in a week to =
work on the revision.

- =
Philip

On 2015-08-13, at 14:43 , =
Mukom Akong T. wrote:

Table at top of page 3 states "Works" for certain choices. I =
think it will be effective to more specific about what 'Works' means in =
this context. As this document is heavily L3 focused, perhaps defining =
'Works' in terms of "L3 routing and forwarding functions as expected =
without =
....."


[snip]

<=
div>  =
+---------+------------+-------------------+------------------------+
   |    PA   |  Tunneled  | =
   Works. Using   |  Works. Using private =
 |
   |         |   =
         | private addresses |   =
 addresses likely    |
   |   =
      |            |   =
likely better   |     better option.     =
|
   |         |     =
       |      option.     =
 |                   =
     |
  =
 +---------+------------+-------------------+------------------------=
+

[snip]

Like =
Mike, I'd think some more clarifications need to be made as to why =
private is a better option than PA. 

- I'd =
rather have "works but PI is a better option" 
- I'd be =
curious to know that what 


On 9 July 2015 at =
04:25, Mark Smith <markzzzsmith@gmail.com> =
wrote:
On 7 =
July 2015 at 14:48, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Hi,

>

> I don't understand why you mention RFC 1918 in a document about

> IPv6 deployment.

>

> In the table in 2.1.1, I object strongly to the comment against

> private (i.e. ULA) addresses

> "Will probably require some sort of NAT on links to the =
Internet."

>

> That isn't the architecture. The architecture is that nodes have =
multiple

> addresses, and only use ULAs for internal traffic, and use PA or PI =
addresses

> for Internet traffic.



I agree.



Unless you're using link-locals only in your network (and that isn't

really possible for the edge networks), there is always an address

selection process going on between the always present link-locals =
and

the other address or addresses that are available.



Perhaps it isn't that common knowledge that link-local addresses are

quite valid to be used by/for applications, as per RFC4007, and are

normally preferred over all other address types if they're available

to the application, excepting the loopback prefix, because =
link-locals

have the second smallest scope (and the smallest scope is =
preferred).



In other words, most IPv6 networks are multi-prefix even if their

operators think they aren't because they "only" have a single GUA.

This is probably worth more visibly highlighting or emphasising in

this draft, because it seems to be something that is commonly

forgotten or not completely realised.



> We shouldn't be documenting any other usage of

> ULAs. We shouldn't be making statements like this:

>

> "For an enterprise, the use of private address space is

> reasonable, but the enterprise will need to use NAT44 and/or

> NPT[RFC6296] on links to the Internet."

>

> We clearly can't pretend that NAT44 isn't widely used, but IMHO it =
should

> be completely out of scope in this document, and NPTv6 is an =
experimental

> RFC that we should never recommend. ULAs should *only* be used in =
parallel

> with PA or PI. That isn't an afterthought; that is the basic =
intention behind

> ULAs.

>



I've thought that if it is unacceptable for devices inside =
your

network to have global addresses, then your security requirements =
are

probably so stringent that NPTv6 devices, packet filters and =
stateful

firewalls would be too simple to achieve and implement them. =
Instead,

you'd use application layer proxies for specific applications you

permit, that act on behalf of and completely or near completely hide

the identity of the devices inside your network, and prevent any

possible reachability to those devices, inherent in ULA addressing,

unless the application layer proxy itself is compromised.



If using per-application application layer proxies is considered too

onerous or costly, then I think the security measures you'd have in

place (e.g., host firewalls, network perimeter firewalls/packet

filters) would mean there is less risk to deploying global addresses

internally compared to the benefits of having them.



<snip>



Regards,

Mark.




_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





-- =


Mukom Akong T.

http://about.me/perfexcellence	|  twitter: =
@perfexcellent						=

----------------------------------------------------------------------=
--------------------------------------------------------------------
=93=
When you work, you are the FLUTE through whose lungs the whispering of =
the hours turns to MUSIC" - Kahlil =
Gibran
----------------------------------------------------------------=
--------------------------------------------------------------------------=
-





=

--Apple-Mail-13--507616925--


From nobody Sun Aug 16 11:00:07 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DF61A88D4 for ; Sun, 16 Aug 2015 11:00:05 -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 BfcfbDNEM_Y7 for ; Sun, 16 Aug 2015 11:00:04 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFF81A88CF for ; Sun, 16 Aug 2015 11:00:03 -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=1439748003; x=1440957603; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=LBdY4bKvkrlOSLhPhDAP1p3ix4Rzb/x1RT1XoWPl0f1mMY/DBjg38v0/ FJyAAFk/Dt/9IvC9ZQqOpT+h4FzOLX06Yq9aGbV6G3G110PXlmrq3+qT0 OKS7tkYZ99XfRmDBUluKHTtU6YLe/N492ZBs4KSNql2QuAqeatmXcSR7Y E=;
X-IronPort-AV: E=Sophos;i="5.15,690,1432598400"; d="scan'208";a="178545499"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 16 Aug 2015 18:00:03 +0000
Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7GI02C5017266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 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 t7GI02PS027880; Sun, 16 Aug 2015 11:00:02 -0700
Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t7GI01kT027873; Sun, 16 Aug 2015 11:00:01 -0700
Date: Sun, 16 Aug 2015 11:00:01 -0700
From: fred@cisco.com
Message-Id: <201508161800.t7GI01kT027873@irp-lnx1.cisco.com>
To: v6ops@ietf.org
Archived-At: 
Subject: [v6ops] draft-ietf-v6ops-siit-dc-2xlat 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, 16 Aug 2015 18:00:05 -0000

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


From nobody Mon Aug 17 09:20: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 824A51A1EF2; Mon, 17 Aug 2015 09:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ihfI0UHTKc9; Mon, 17 Aug 2015 09:20:14 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2291A1B96; Mon, 17 Aug 2015 09:20:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150817162014.13511.99968.idtracker@ietfa.amsl.com>
Date: Mon, 17 Aug 2015 09:20:14 -0700
Archived-At: 
Cc: Joel Jaeggli , Fred Baker , v6ops@ietf.org
Subject: [v6ops] Spencer Dawkins' No Objection on charter-ietf-v6ops-03-00: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Aug 2015 16:20:15 -0000

Spencer Dawkins has entered the following ballot position for
charter-ietf-v6ops-03-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-v6ops/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This looks like a fine revised charter. I had slight uneasiness about
adding 

"2.  Solicit input from network operators and users to identify
operational interaction issues with the IPv4 Internet, and determine
solutions or workarounds to those issues."

because I wondered if this will make v6ops more attractive for NAT
proposals, but if that's the right thing to do, please do the right
thing.



From nobody Mon Aug 17 10:35: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 55F611ACD5E; Mon, 17 Aug 2015 10:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuCeEJwkrfnb; Mon, 17 Aug 2015 10:35:39 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0: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 8CDFA1ACD42; Mon, 17 Aug 2015 10:35:39 -0700 (PDT)
Received: by vkfi73 with SMTP id i73so58342372vkf.2; Mon, 17 Aug 2015 10:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mjYj88/Goj8riM/nCB/fF556glNW1TWDvKUNTRrB398=; b=xuAVk1ZQeRGo8pPeA5j9ehREwPgct9HIB/gCWV3XxpmpsI69UU394plb8i1PoGSOK2 UW8kWZWI4W3f0AcREdg95IjIj+eC0c7UOCr4bNRufFWz5+zx/ybdtNjCq1DZSMO3h9HQ COD3OQbiHlitUDCCL6k+9EeeZcHmEdPbP2r2YwurfK5jZVU6sTx9Uoh6oCUHEc/BNUUd mhV5/8PTvNUt5SlL1YV2jfTcfCAdU7lIYKphXjGn6h01LgM3O/xMObZqQXVWoVfJUniQ v3ah3jBjIynL2EkgQ3Bf8Y4jmA5XQwWxQ/0P1VMahx4I6ZKreR8nGl4gV7CdMc18GkaA xwQA==
MIME-Version: 1.0
X-Received: by 10.52.170.131 with SMTP id am3mr1104197vdc.17.1439832938862; Mon, 17 Aug 2015 10:35:38 -0700 (PDT)
Received: by 10.31.63.1 with HTTP; Mon, 17 Aug 2015 10:35:38 -0700 (PDT)
In-Reply-To: <55D21AAD.8020806@gmail.com>
References: <20150817162014.13511.99968.idtracker@ietfa.amsl.com> <55D21AAD.8020806@gmail.com>
Date: Mon, 17 Aug 2015 12:35:38 -0500
Message-ID: 
From: Spencer Dawkins at IETF 
To: joel jaeggli 
Content-Type: multipart/alternative; boundary=047d7b6dba94db5ea4051d853a8f
Archived-At: 
Cc: The IESG , Fred Baker , v6ops@ietf.org
Subject: Re: [v6ops] Spencer Dawkins' No Objection on charter-ietf-v6ops-03-00: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Aug 2015 17:35:41 -0000

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

Hi, Joel,

On Mon, Aug 17, 2015 at 12:32 PM, joel jaeggli  wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/17/15 9:20 AM, Spencer Dawkins wrote:
> > Spencer Dawkins has entered the following ballot position for
> > charter-ietf-v6ops-03-00: No Objection
> >
> > When responding, please keep the subject line intact and reply to
> > all email addresses included in the To and CC lines. (Feel free to
> > cut this introductory paragraph, however.)
> >
> >
> >
> > The document, along with other ballot positions, can be found
> > here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/
> >
> >
> >
> > ----------------------------------------------------------------------
> >
> >
> COMMENT:
> > ----------------------------------------------------------------------
> >
> >  This looks like a fine revised charter. I had slight uneasiness
> > about adding
> >
> > "2.  Solicit input from network operators and users to identify
> > operational interaction issues with the IPv4 Internet, and
> > determine solutions or workarounds to those issues."
> >
> > because I wondered if this will make v6ops more attractive for NAT
> > proposals, but if that's the right thing to do, please do the
> > right thing.
>
> Given the extent to which such proposals are viewed with suspicion I
> don't think that it's likely. to the extent that v6ops has concerned
> itself with this area in the past, it has involved operational use of
> work done in behave (464xlat), or largely  how to avoid stateful nats,
> deprecation of nat-pt, multihoming without nat (really homenet has
> that remit now).


That works for me.

And thanks for the confirmation.

Spencer

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


Hi, Joel,

On Mon, Aug 17, 2015 at 12:32 PM, joel jaeggli <joelja@gmail.c=
om> wrote:
-----BEGIN PGP S=
IGNED MESSAGE-----

Hash: SHA1




On 8/17/15 9:20 AM, Spencer Dawkins wrote:

> Spencer Dawkins has entered the following ballot position for

> charter-ietf-v6ops-03-00: No Objection

>

> When responding, please keep the subject line intact and reply to

> all email addresses included in the To and CC lines. (Feel free to

> cut this introductory paragraph, however.)

>

>

>

> The document, along with other ballot positions, can be found

> here: https://datatracker.ietf.org/doc/char=
ter-ietf-v6ops/

>

>

>

> ----------------------------------------------------------------------=


>

>

COMMENT:

> ----------------------------------------------------------------------=


>

>=C2=A0 This looks like a fine revised charter. I had slight uneasiness<=
br>
> about adding

>

> "2.=C2=A0 Solicit input from network operators and users to ident=
ify

> operational interaction issues with the IPv4 Internet, and

> determine solutions or workarounds to those issues."

>

> because I wondered if this will make v6ops more attractive for NAT

> proposals, but if that's the right thing to do, please do the

> right thing.




Given the extent to which such proposals are viewed with suspic=
ion I

don't think that it's likely. to the extent that v6ops has concerne=
d

itself with this area in the past, it has involved operational use of

work done in behave (464xlat), or largely=C2=A0 how to avoid stateful nats,=


deprecation of nat-pt, multihoming without nat (really homenet has

that remit now).

That works for me. =C2=A0<=
/div>

And thanks for the confirmation.

Spencer



--047d7b6dba94db5ea4051d853a8f--


From nobody Tue Aug 18 11:27: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 6C8721ACD96; Mon, 17 Aug 2015 10:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9xsMHA5uZGH; Mon, 17 Aug 2015 10:32:36 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::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 E6FAF1ACDAE; Mon, 17 Aug 2015 10:32:31 -0700 (PDT)
Received: by pdbmi9 with SMTP id mi9so17477679pdb.3; Mon, 17 Aug 2015 10:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=vmuoAI/9BICTwZLWWAqDDoaO2N4GhzbdpJ7EyDOCh/c=; b=lkJNCOA9y+OXEn4L8+RD7uWrCTG2FjcQKbR5gzeez38lFfY6BiC8O6c1ZURIIWvrhF iyy6djaZX6k0ZV6c/7tbWjXNqHn7+U7twraBW4m5ZaMN9p3pxOQmz9/yn5wAxsVg++J8 v2xdqJKRKKyHoyBMgM8dv9ugYydpPym3M/O2GyaORgbOdr0REyB+MS09X11k3bAgyeL1 eFf+RmqnW8CstriLpU95Vx6jXmGnGOYTQ5Q7reJA0Ag55aggX2tmaPb9a/ONT9FZDIg3 /opWvjYH9ySD6kzWh3Bturf6D2s93th8DtFh9zphjagbXdPrsX8blV6hyvNAoWMr5sVj k7/Q==
X-Received: by 10.70.0.230 with SMTP id 6mr4663977pdh.76.1439832751394; Mon, 17 Aug 2015 10:32:31 -0700 (PDT)
Received: from mb.local ([8.18.217.2]) by smtp.googlemail.com with ESMTPSA id qe3sm15283008pbc.73.2015.08.17.10.32.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 10:32:30 -0700 (PDT)
To: Spencer Dawkins , The IESG 
References: <20150817162014.13511.99968.idtracker@ietfa.amsl.com>
From: joel jaeggli 
X-Enigmail-Draft-Status: N1110
Message-ID: <55D21AAD.8020806@gmail.com>
Date: Mon, 17 Aug 2015 10:32:29 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0
MIME-Version: 1.0
In-Reply-To: <20150817162014.13511.99968.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Tue, 18 Aug 2015 11:27:01 -0700
Cc: v6ops@ietf.org, Fred Baker 
Subject: Re: [v6ops] Spencer Dawkins' No Objection on charter-ietf-v6ops-03-00: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Aug 2015 17:32:38 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/17/15 9:20 AM, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for 
> charter-ietf-v6ops-03-00: No Objection
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> 
> The document, along with other ballot positions, can be found
> here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/
> 
> 
> 
> ----------------------------------------------------------------------
>
> 
COMMENT:
> ----------------------------------------------------------------------
>
>  This looks like a fine revised charter. I had slight uneasiness
> about adding
> 
> "2.  Solicit input from network operators and users to identify 
> operational interaction issues with the IPv4 Internet, and
> determine solutions or workarounds to those issues."
> 
> because I wondered if this will make v6ops more attractive for NAT 
> proposals, but if that's the right thing to do, please do the
> right thing.

Given the extent to which such proposals are viewed with suspicion I
don't think that it's likely. to the extent that v6ops has concerned
itself with this area in the past, it has involved operational use of
work done in behave (464xlat), or largely  how to avoid stateful nats,
deprecation of nat-pt, multihoming without nat (really homenet has
that remit now).

> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlXSGqwACgkQ8AA1q7Z/VrIDHACfXKC2U5BCAcO37stEmbeNfxY1
rLoAnj3AyHDVv3b2uMDURie78I4sxdaJ
=opkZ
-----END PGP SIGNATURE-----


From nobody Tue Aug 18 11:27: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 A3BAE1B2F8F for ; Mon, 17 Aug 2015 12:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 kEt8xuMegrqO for ; Mon, 17 Aug 2015 12:50:08 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C759E1B2F8C for ; Mon, 17 Aug 2015 12:50:07 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AcAwA3Q8ZV/yYyC4dbGQEBgjMhLFRvvSoJh30CgSY4FAEBAQEBAQF/C4QlAQEDEhtMEgEVFVYXAQ4BBA4NGogMAax1oDoBAQEBBgEBAQEBAQEbkCkxgx+BFAWVCwFtlG6RBBcPg32CN4EEAQEB
X-IPAS-Result: A2AcAwA3Q8ZV/yYyC4dbGQEBgjMhLFRvvSoJh30CgSY4FAEBAQEBAQF/C4QlAQEDEhtMEgEVFVYXAQ4BBA4NGogMAax1oDoBAQEBBgEBAQEBAQEbkCkxgx+BFAWVCwFtlG6RBBcPg32CN4EEAQEB
X-IronPort-AV: E=Sophos;i="5.15,634,1432612800";  d="scan'208,217";a="136785254"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Aug 2015 15:50:06 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 17 Aug 2015 15:50:06 -0400
Received: from AZ-US1EXMB02.global.avaya.com ([fe80::c01d:740:c927:8888]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Mon, 17 Aug 2015 15:50:06 -0400
From: "Lin, Ping (Ping)" 
To: "v6ops@ietf.org" 
Thread-Topic: Question re. destination cache entry in Neighbor Discovery
Thread-Index: AdDZIwd9Q8rslluxQJykua1cuaavNQ==
Date: Mon, 17 Aug 2015 19:50:06 +0000
Message-ID: <76AE033F283B3A4DA40924C68D5321FD236BB651@AZ-US1EXMB02.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.11.85.49]
Content-Type: multipart/alternative; boundary="_000_76AE033F283B3A4DA40924C68D5321FD236BB651AZUS1EXMB02glob_"
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Tue, 18 Aug 2015 11:27:01 -0700
Subject: [v6ops] Question re. destination cache entry in Neighbor Discovery
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Aug 2015 19:50:10 -0000

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

Hi Everyone,

I wonder if you could help with a couple of questions related to destinatio=
n cache management in IPv6 Neighbor Discovery:


-          It appears from testing on Windows 7  devices that if a prefix i=
s removed on a router to which the device is connected, traffic stops as so=
on as the prefix is deleted, even though the destination cache entry is not=
 removed.  Is this behavior expected?

-          After one minute, the destination cache entry is removed.   Is t=
here an RFC reference defining the lifetime of destination cache entries?

Regards,
Ping Lin
Avaya


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











Hi Everyone,


 


I wonder if you could help with a couple of question=
s related to destination cache management in IPv6 Neighbor Discovery:<=
/o:p>


 


-It appears =
from testing on Windows 7  devices that if a prefix is removed on a ro=
uter to which the device is connected, traffic stops as soon as the prefix =
is deleted, even though the destination
 cache entry is not removed.  Is this behavior expected?


-After one m=
inute, the destination cache entry is removed.   Is there an RFC =
reference defining the lifetime of destination cache entries?


 


Regards,


Ping Lin


Avaya


 






--_000_76AE033F283B3A4DA40924C68D5321FD236BB651AZUS1EXMB02glob_--


From nobody Tue Aug 18 16:26: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 3502F1A887B; Tue, 18 Aug 2015 16:26:17 -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 MHeksK6PMiat; Tue, 18 Aug 2015 16:26:15 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34CE1A87C5; Tue, 18 Aug 2015 16:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1228; q=dns/txt; s=iport; t=1439940375; x=1441149975; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bqIq97GlU85e2UQkzugk7j6B4FxYzgN9cwSOqxA8Z7U=; b=Ruht4tZYouLvAMX4azQAhRjfelvvP8mUs2diWvRSE5y4O6IQw6LMcgXz Hd3r3OyZb2gaBoBFhx5SY9V8GxqYXGEf6dkklkg3HpQhYZ+f5X6X8Hben 6ioInZpMwiNc27pJF9ZLerqHGUCfceqiT4APsMgi5Z99eP7dk5BwMoyuQ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AfBQAnvtNV/4sNJK1TCoMbgT0GxXoCgTo8EAEBAQEBAQGBCoQjAQEBAwE6PwULAgEIGB4QIRElAgQOBRuHfgMKCMwWDYVXAQEBAQEBAQEBAQEBAQEBAQEBARmLU4JPgV4qMweDGIEUAQSVIgGKfoFtgUqELIwKeYc2JoN9cYFIgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,705,1432598400"; d="scan'208";a="21627746"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 18 Aug 2015 23:26:14 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7INQEgq029685 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2015 23:26:14 GMT
Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 18 Aug 2015 18:26:13 -0500
Received: from xhc-aln-x02.cisco.com (173.36.12.76) by xch-aln-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 18 Aug 2015 18:26:13 -0500
Received: from xmb-rcd-x09.cisco.com ([169.254.9.173]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0248.002; Tue, 18 Aug 2015 18:26:13 -0500
From: "Fred Baker (fred)" 
To: Spencer Dawkins 
Thread-Topic: Spencer Dawkins' No Objection on charter-ietf-v6ops-03-00: (with COMMENT)
Thread-Index: AQHQ2g1F/UDaQxfH7UCWTtgudbLFVA==
Date: Tue, 18 Aug 2015 23:26:12 +0000
Message-ID: <6274BA70-5FEE-487A-BD02-3F7BE33BB733@cisco.com>
References: <20150817162014.13511.99968.idtracker@ietfa.amsl.com>
In-Reply-To: <20150817162014.13511.99968.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.37.102.29]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: v6ops list , The IESG , Joel Jaeggli 
Subject: Re: [v6ops] Spencer Dawkins' No Objection on charter-ietf-v6ops-03-00: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Aug 2015 23:26:17 -0000

> On Aug 17, 2015, at 9:20 AM, Spencer Dawkins  wrote:
>=20
> This looks like a fine revised charter. I had slight uneasiness about
> adding=20
>=20
> "2.  Solicit input from network operators and users to identify
> operational interaction issues with the IPv4 Internet, and determine
> solutions or workarounds to those issues."
>=20
> because I wondered if this will make v6ops more attractive for NAT
> proposals, but if that's the right thing to do, please do the right
> thing.

In fairness, there is an update to RFC 6145, incorporating a erratum, RFC 6=
791, draft-ietf-6man-deprecate-atomfrag-generation, and draft-ietf-v6ops-si=
it-eam, happening on the v6ops list right now. The obvious other working gr=
oups are either defunct or about to be. Joel told us that if v6ops could ag=
ree on the update (which is pretty close), he would take it as AD-sponsored=
. So, yes, there is a question of translation, and it is being driven by op=
erational considerations.

The question that the sunset4 chairs had with Lee and I was how this fit wi=
th their charter, which is essentially about IPv4 shutdown. The current cha=
rter wording was worked out with them.=


From nobody Tue Aug 18 20:59: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 6A9CA1A8989; Tue, 18 Aug 2015 20:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-Si2zhSzpVG; Tue, 18 Aug 2015 20:59:31 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 C5F841A88A9; Tue, 18 Aug 2015 20:59:27 -0700 (PDT)
Received: by vkpp190 with SMTP id p190so647681vkp.3; Tue, 18 Aug 2015 20:59:27 -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=LosIbXOdSkym1Lhu2YsGPlOBf3OFf+X4dwt8dQmJzp0=; b=BeceOqUHVDDEjZ0+sEBNtHWuTrGhhZUE7w7y4PNVmK2U6Zxl/3rxiMzJ4kdf2fcPWs 2N1auUH6BkBxmbHK4JuG4PmVS7co2MlCve8X0fUJ9gymWDeLHkeYgZIwL/xTxMfemCT+ y9LUSgJ2w1t+p9TVu5eiaF6j3samk6SBbEmEZ5qAc8K9d3Y5C6in/cMNQy5cKGgTygxz OxX5pbSNal1Uuwij0wE5cbSlWk6K/zVyIDu7viVbNBJ0fXz8rgWBrUzRm1AZhdBCq32O /8IxUo4XH84dVwGm1l5JHumZ8lLqdObtUnamJdD/mD4lHQNOLDLqjA9fwV8RTHQbkIHs Xr+w==
MIME-Version: 1.0
X-Received: by 10.52.114.196 with SMTP id ji4mr13626015vdb.24.1439956767091; Tue, 18 Aug 2015 20:59:27 -0700 (PDT)
Received: by 10.31.63.1 with HTTP; Tue, 18 Aug 2015 20:59:27 -0700 (PDT)
In-Reply-To: <6274BA70-5FEE-487A-BD02-3F7BE33BB733@cisco.com>
References: <20150817162014.13511.99968.idtracker@ietfa.amsl.com> <6274BA70-5FEE-487A-BD02-3F7BE33BB733@cisco.com>
Date: Tue, 18 Aug 2015 22:59:27 -0500
Message-ID: 
From: Spencer Dawkins at IETF 
To: "Fred Baker (fred)" 
Content-Type: multipart/alternative; boundary=bcaec548a503983083051da20fca
Archived-At: 
Cc: v6ops list , The IESG , Joel Jaeggli 
Subject: Re: [v6ops] Spencer Dawkins' No Objection on charter-ietf-v6ops-03-00: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 Aug 2015 03:59:32 -0000

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

Hi, Fred,

On Tue, Aug 18, 2015 at 6:26 PM, Fred Baker (fred)  wrote:

>
> > On Aug 17, 2015, at 9:20 AM, Spencer Dawkins <
> spencerdawkins.ietf@gmail.com> wrote:
> >
> > This looks like a fine revised charter. I had slight uneasiness about
> > adding
> >
> > "2.  Solicit input from network operators and users to identify
> > operational interaction issues with the IPv4 Internet, and determine
> > solutions or workarounds to those issues."
> >
> > because I wondered if this will make v6ops more attractive for NAT
> > proposals, but if that's the right thing to do, please do the right
> > thing.
>
> In fairness, there is an update to RFC 6145, incorporating a erratum, RFC
> 6791, draft-ietf-6man-deprecate-atomfrag-generation, and
> draft-ietf-v6ops-siit-eam, happening on the v6ops list right now. The
> obvious other working groups are either defunct or about to be. Joel told
> us that if v6ops could agree on the update (which is pretty close), he
> would take it as AD-sponsored. So, yes, there is a question of translation,
> and it is being driven by operational considerations.
>
> The question that the sunset4 chairs had with Lee and I was how this fit
> with their charter, which is essentially about IPv4 shutdown. The current
> charter wording was worked out with them.


Thank you for the helpful background. I'm entirely comfortable with the
proposed charter revision.

Spencer

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


Hi, Fred,

On Tue, Aug 18, 2015 at 6:26 PM, Fred Baker (fred) <fred@cisco=
.com> wrote:


> On Aug 17, 2015, at 9:20 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
>

> This looks like a fine revised charter. I had slight uneasiness about<=
br>
> adding

>

> "2.=C2=A0 Solicit input from network operators and users to ident=
ify

> operational interaction issues with the IPv4 Internet, and determine
> solutions or workarounds to those issues."

>

> because I wondered if this will make v6ops more attractive for NAT

> proposals, but if that's the right thing to do, please do the righ=
t

> thing.



In fairness, there is an update to RFC 6145, incorporating a erratum=
, RFC 6791, draft-ietf-6man-deprecate-atomfrag-generation, and draft-ietf-v=
6ops-siit-eam, happening on the v6ops list right now. The obvious other wor=
king groups are either defunct or about to be. Joel told us that if v6ops c=
ould agree on the update (which is pretty close), he would take it as AD-sp=
onsored. So, yes, there is a question of translation, and it is being drive=
n by operational considerations.



The question that the sunset4 chairs had with Lee and I was how this fit wi=
th their charter, which is essentially about IPv4 shutdown. The current cha=
rter wording was worked out with them.

Thank you for the helpful background. I'm entirely c=
omfortable with the proposed charter revision.

Spencer


--bcaec548a503983083051da20fca--


From nobody Wed Aug 19 05:50:09 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585131A0389; Wed, 19 Aug 2015 05:50:07 -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 Ki70Xyv7AznU; Wed, 19 Aug 2015 05:50:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E721A0196; Wed, 19 Aug 2015 05:50:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150819125003.14716.20634.idtracker@ietfa.amsl.com>
Date: Wed, 19 Aug 2015 05:50:03 -0700
Archived-At: 
Cc: Joel Jaeggli , Fred Baker , v6ops@ietf.org
Subject: [v6ops] Stephen Farrell's No Objection on charter-ietf-v6ops-03-00: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Aug 2015 12:50:07 -0000

Stephen Farrell has entered the following ballot position for
charter-ietf-v6ops-03-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-v6ops/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Definitely ready for external review. Could also be just fine to
re-charter,
not sure what's intended.

This is though a pretty vague charter and mostly seems to characterise
what won't be done instead of what is planned to be done. I'm ok with
that given that the WG seems to have a bunch of work to do and doesn't
seem to have gone crazy in the past.



From nobody Fri Aug 21 12:21: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 A2CE71ACD63; Fri, 21 Aug 2015 12:21:24 -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 Yeu_fwirr1Ne; Fri, 21 Aug 2015 12:21:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7851ACD6F; Fri, 21 Aug 2015 12:21:22 -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: 6.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150821192122.6467.1059.idtracker@ietfa.amsl.com>
Date: Fri, 21 Aug 2015 12:21:22 -0700
Archived-At: 
Cc: v6ops WG 
Subject: [v6ops] WG Review: IPv6 Operations (v6ops)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Aug 2015 19:21:24 -0000

The IPv6 Operations (v6ops) working group in the Operations and
Management Area of the IETF is undergoing rechartering. The IESG has not
made any determination yet. The following draft charter was submitted,
and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg at ietf.org) by 2015-08-31.

IPv6 Operations (v6ops)
------------------------------------------------
Current Status: Active WG

Chairs:
  Lee Howard 
  Fred Baker 

Assigned Area Director:
  Joel Jaeggli 

Mailing list
  Address: v6ops@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/v6ops
  Archive: https://mailarchive.ietf.org/arch/browse/v6ops/

Charter:

Charter for Working Group

The global deployment of IPv6 is underway, creating an Internet
consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes.
This deployment must be properly handled to avoid the division of
the Internet into separate IPv4 and IPv6 networks, ensuring addressing
and connectivity for all IPv4 and IPv6 nodes.

The IPv6 Operations Working Group (v6ops) develops guidelines for
the operation of IPv6 networks, and provides operational guidance
on how to deploy and operate IPv6 in new and existing networks.

The main focus of the IPv6 Operations Working Group is to look at
the deployment and operational issues in IPv6 networks.

The goals of the v6ops working group are:

1.  Solicit input from network operators and users to identify
operational issues with the IPv6 Internet, and determine solutions
or workarounds to those issues.

2.  Solicit input from network operators and users to identify
operational interaction issues with the IPv4 Internet, and determine
solutions or workarounds to those issues.

3.  Operational solutions for identified issues should be developed
in v6ops and documented in informational or BCP drafts.

These documents should document IPv6 operational experience, including
interactions with IPv4, in dual stack networks, IPv6 networks with
IPv4 delivered as an overlay or translation service, or IPv6-only
networks.

IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility
of the groups or areas responsible for those protocols or technologies.
However, the v6ops Working Group may provide input to those
areas/groups, as needed, and cooperate with those areas/groups in
reviewing solutions to IPv6 operational and deployment problems.

Future work items within this scope will be adopted by the Working
Group only if there is a substantial expression of interest from
the community and if the work clearly does not fit elsewhere in the
IETF.

There must be a continuous expression of interest for the Working
Group to work on a particular work item.  If there is no longer
sufficient interest in the Working Group in a work item, the item
may be removed from the list of Working Group items.


Milestones:

TBD


From nobody Sun Aug 23 11:00: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 8A20D1B29F0 for ; Sun, 23 Aug 2015 11:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.811
X-Spam-Level: 
X-Spam-Status: No, score=-111.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 yDE04m6kHoSm for ; Sun, 23 Aug 2015 11:00:04 -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 5A9421B29EE for ; Sun, 23 Aug 2015 11:00:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=644; q=dns/txt; s=iport; t=1440352804; x=1441562404; h=date:from:message-id:to:subject:cc; bh=vu5h4PQSP0SS9f3gqctxxIdKEug7o0vVhvjsAEzsfBA=; b=aBsGKi65ZURCZsJHxmOCSk7FgzVS/UwKqUbeDRb7RSAmq9kSBX4TtXpG tu5t9tGrIsOrli4FVgyInBgR80BP7lS5TlN41UVUbe0XXTloX8wEsoqjN /dlaZzmE8rKPqflo/8wJqfy/iz6DbhjEr1lKfq+rGj3WcR9GsWrl9JtSY I=;
X-IronPort-AV: E=Sophos;i="5.15,733,1432598400"; d="scan'208";a="22870129"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP; 23 Aug 2015 18:00:04 +0000
Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7NI03mG003714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Aug 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 t7NI038S029036; Sun, 23 Aug 2015 11:00:03 -0700
Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t7NI011E029031; Sun, 23 Aug 2015 11:00:01 -0700
Date: Sun, 23 Aug 2015 11:00:01 -0700
From: fred@cisco.com
Message-Id: <201508231800.t7NI011E029031@irp-lnx1.cisco.com>
To: v6ops@ietf.org
Archived-At: 
Subject: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 23 Aug 2015 18:00:05 -0000

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.  
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 Tue Aug 25 10:54: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 360531ACE4E for ; Tue, 25 Aug 2015 10:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsuQpvXKAVRq for ; Tue, 25 Aug 2015 10:54:51 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05F71ACE4A for ; Tue, 25 Aug 2015 10:54:50 -0700 (PDT)
Received: by igcse8 with SMTP id se8so19334887igc.1 for ; Tue, 25 Aug 2015 10:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5UqIxQMVhLttryaAC0FQBX5HekMTMlLbvDM8d13yEnE=; b=aVs/DA39jaKDx4nocZenw8GgWpuB8CkoY33FQQb4EuhodSh1bVNZK51Bkry/k1uRO3 fNB24e58vhodPzOPXPC6ysjOR+kBXBHv/B65yl7nCZL21Ra8GUlZTkhnfYYJ5X+VjhJ3 +WJoqhQcT/0MbZ23Sn6ozFPwDVUqOjyA0oyZmAodKnytb//Zp0ylSLIcDzxpilZFWp/a 9ZAu5fH7+i5If1fhA5odvLIOXpON56rXZqm3djC0B2NeYWTzLnrJB6dyWCCkFVqbj9gX 14yL4+shsHPbIHhqzsokqncEd9kCU+O35IF5VBJmgIPCdDUQ6QflXI+lw/j99ew1YA7p 5yqQ==
MIME-Version: 1.0
X-Received: by 10.50.143.12 with SMTP id sa12mr4410671igb.64.1440525290283; Tue, 25 Aug 2015 10:54:50 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.143.7 with HTTP; Tue, 25 Aug 2015 10:54:50 -0700 (PDT)
In-Reply-To: <201508231800.t7NI011E029031@irp-lnx1.cisco.com>
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com>
Date: Tue, 25 Aug 2015 10:54:50 -0700
X-Google-Sender-Auth: 4ZChpjB545hSIkbzPE4oIptaxew
Message-ID: 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: "Fred Baker (fred)" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 25 Aug 2015 17:54:52 -0000

At Sun, 23 Aug 2015 11:00:01 -0700,
fred@cisco.com wrote:

> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.
> Please read it now. If you find nits (spelling errors, minor suggested
> wording changes, etc), comment to the authors; if you find greater
> issues, such as disagreeing with a statement or finding additional
> issues that need to be addressed, please post your comments to the
> list.
>
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.

I've read the draft.  It's well-written, and I think the topic and its
content are useful.

I have one minor comment on Section 2.2:

   Some networks send periodic multicast Router Advertisements (e.g.,
   once every few seconds).

I guess the intent here is explain non-default cases where multicast
RAs are sent out very frequently (correct?).  But the actual text
doesn't necessarily read that way to me, since sending multicast RAs
periodically is the default behavior per RFC4861, and the default
interval is between 200sec and 600sec.  Assuming my interpretation of
the intent is correct, I suggest revising this sentence as follows:

   Some networks send periodic multicast Router Advertisements very
   frequently (e.g., once every few seconds).

--
JINMEI, Tatuya


From nobody Wed Aug 26 09:23: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 471891A0125 for ; Wed, 26 Aug 2015 09:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw-UenSsbQCE for ; Wed, 26 Aug 2015 09:23:09 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::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 669451A0047 for ; Wed, 26 Aug 2015 09:23:09 -0700 (PDT)
Received: by labgv11 with SMTP id gv11so55293896lab.2 for ; Wed, 26 Aug 2015 09:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=ixgH/vaiBoDbsECo5JSdQSWDkOZUfK04q3Ca5WxoOvE=; b=qwCqnizZe4ES5/siTUDfYi5IIj2fGj46RcNrg7iVrLhxLFWu8vdV3m/G6oquAxyT/Z s8u8WrWaxK8BdWuA7Pqzof4GjoGEV7srl4BbL95JOxFc6JMBQVCJhZlHRk/f/CuHJe8N D16jo070dPRJ/eulZpBwhssX2e/zXQlwnK89xhbbubDramPDh4WfnDdFWwVjMFNQJLtW eAOp7uUZXT0LOZX9+LcKz14x/aVdXO0RpoaezaeMpa4fJsp1WhP6yoS5hajEi/jzULWD ejh6PHAuqoTva+1x+xwKMMQDINE5Oq8uq48alOJxW5j1XTx0J40L9KOPXmMOu6bLaJYQ brow==
MIME-Version: 1.0
X-Received: by 10.112.170.103 with SMTP id al7mr31647387lbc.66.1440606187824;  Wed, 26 Aug 2015 09:23:07 -0700 (PDT)
Received: by 10.112.242.1 with HTTP; Wed, 26 Aug 2015 09:23:07 -0700 (PDT)
Date: Wed, 26 Aug 2015 11:23:07 -0500
Message-ID: 
From: Alberto Leiva 
To: v6ops@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [v6ops] What do I do with untranslatable IPv4 addresses?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 Aug 2015 16:23:11 -0000

Because all it does is prepend a prefix, the address translation
algorithm from RFC 6052 can take any IPv4 address as input and
generate an IPv6 address as a result.

Because it depends on an input IPv6 address containing the prefix, the
opposite is not true: It cannot generate an IPv4 address out of *any*
IPv6 address.

I think this is the reason why RFC 6791 requires an IPv4 address pool
but doesn't even mention an IPv6 pool; assuming RFC 6052 is the only
address translation algorithm at play, any IPv4 router will source
ICMPv4 errors in translatable ways. It's IPv6 routers that need to be
masked with special IPv4 addresses.

If we're defining new address translation algorithms, I think we risk
breaking this assumption. In particular, EAM breaks it. It is entirely
possible to configure an EAM table where not every IPv4 address is
translatable. (ie. pretty much any EAMT that doesn't include
0.0.0.0/0)

Now, it's true that EAM can be used in concert with RFC 6052
translation (therefore making every IPv4 address translatable), but
Tore and I agree that there are use cases where EAM can be used
without the 6052 falling back option
(https://mail-lists.nic.mx/pipermail/jool-list/2015-August/000041.html).
For this reason, it would be asinine for an implementation to force
the presence of a 6052 prefix in the configuration as long as there is
at least one entry in the EAMT. This *could* (though in SIIT/DC it
doesn't seem to be an issue) lead to a situation where an IPv4 router
answers an ICMPv4 error and the translator will have to drop it
because its source address doesn't match the EAMT.

I don't know if this is a problem; I'm just theorizing. But it seems
to me an "IPv6 RFC 6791 pool" should be defined, if not for the sake
of EAM, for the sake of any future address translation algorithms,
either IETF-defined or homemade...

Opinions?
Alberto


From nobody Wed Aug 26 09:54: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 D51331B2D7F for ; Wed, 26 Aug 2015 09:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSSfAckvBa_D for ; Wed, 26 Aug 2015 09:54:44 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::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 C82B31A21BC for ; Wed, 26 Aug 2015 09:54:43 -0700 (PDT)
Received: by labia3 with SMTP id ia3so59164720lab.3 for ; Wed, 26 Aug 2015 09:54:42 -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=+VKbILUAf/Pmie9oPHbcNeOS7IMWziLWefEiwTFaXRs=; b=SvG17uJBMJL5bkU144M/qLX2na0P1307FXXRJEC4MIebOmvvtj+Ou0Txzd7kETWdSJ hXo1SGmVGvFM+izsRy28MH167rxjIZyyiJPPUNXsA7UtQUeJf8UgEYw6T0awl0GbO9IL n2zVsVh7R75O/wxTQJVoyXu06KCz5izCLsz+VtuFNQVvG6taMGvG5MVhcsQa1QxbCVZQ ai07/8zFmlgdoeyY/pksAaWF02u/YBBTomU2TB8LeYxnSUlFCF/CAZXmjxXGJf1x+GIL Iirc5wFFCtTRonVhCWHGGP5CrB1JxKRibys5mdPO3aQwjg7zCHa0yQFhcorUxvYBZ82S SC7w==
MIME-Version: 1.0
X-Received: by 10.153.4.11 with SMTP id ca11mr19801898lad.80.1440608082135; Wed, 26 Aug 2015 09:54:42 -0700 (PDT)
Received: by 10.112.242.1 with HTTP; Wed, 26 Aug 2015 09:54:42 -0700 (PDT)
In-Reply-To: <55CA979F.9010403@cernet.edu.cn>
References: <55CA979F.9010403@cernet.edu.cn>
Date: Wed, 26 Aug 2015 11:54:42 -0500
Message-ID: 
From: Alberto Leiva 
To: Xing Li 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] New Version Notification for draft-bao-v6ops-rfc6145bis-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Aug 2015 16:54:46 -0000

Say

Something about 6145 has been bothering me for a while. Regarding ICMP
error length:

RFC 1812 section 4.3.2.3 says "the ICMP [error] datagram SHOULD
contain as much of the original datagram as possible without the
length of the ICMP datagram exceeding 576 bytes."

RFC 4443 says "[The ICMP payload should measure] as much of invoking
packet as possible without the ICMPv6 packet exceeding the minimum
IPv6 MTU."

I don't know how current or realistic these constraints are. I
apologize if I've been living under a rock.

Regardless:

Since the minimum IPv6 MTU is not the same as the IPv4 MTU, a
translator can end up with an "illegal" ICMP error. Following the
numbers above, after removing both IPv6 headers and attaching both
IPv4 headers, a resulting IPv4 packet can be an ICMPv4 error and span
1240 bytes.

For the sake of correctness, shouldn't the translator truncate it?
(And update the outer ICMP checksum accordingly)

On Tue, Aug 11, 2015 at 7:47 PM, Xing Li  wrote:
> Hi, All,
>
> According to the conclusion made in v6ops meeting of IETF93, (removing
> the EAM part and refer to EAM draft), we have updated the
> draft-bao-v6ops-rfc6145bis, please review. Thanks.
>
> Regards,
>
> xing
>
>> Name:         draft-bao-v6ops-rfc6145bis
>> Revision:     01
>> Title:                IP/ICMP Translation Algorithm (rfc6145bis)
>> Document date:        2015-08-07
>> Group:                Individual Submission
>> Pages:                38
>> URL:            https://www.ietf.org/internet-drafts/draft-bao-v6ops-rfc6145bis-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145bis/
>> Htmlized:       https://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis-01
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-bao-v6ops-rfc6145bis-01
>>
>> Abstract:
>>    This document describes the Stateless IP/ICMP Translation Algorithm
>>    (SIIT), which translates between IPv4 and IPv6 packet headers
>>    (including ICMP headers).  This document updates RFC 6145.
>>
>>
>>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Thu Aug 27 06:13: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 157411AD0C0 for ; Thu, 27 Aug 2015 06:13: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, 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 YSu0L_lgZQMs for ; Thu, 27 Aug 2015 06:13:20 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 201141A86DF for ; Thu, 27 Aug 2015 06:13:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 936BB402DD; Thu, 27 Aug 2015 15:13:18 +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 eMw3YEaP5VUx; Thu, 27 Aug 2015 15:13:16 +0200 (CEST)
Received: from Rays-MacBook-Pro.local (d75067.upc-d.chello.nl [213.46.75.67]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 364F9401C3; Thu, 27 Aug 2015 15:13:16 +0200 (CEST)
Message-ID: <55DF0CEB.5040500@globis.net>
Date: Thu, 27 Aug 2015 15:13:15 +0200
From: "Ray Hunter (v6ops)" 
User-Agent: Postbox 4.0.3 (Macintosh/20150805)
MIME-Version: 1.0
To: fred@cisco.com
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com>
In-Reply-To: <201508231800.t7NI011E029031@irp-lnx1.cisco.com>
Content-Type: multipart/alternative; boundary="------------080407090404020004080001"
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 27 Aug 2015 13:13:22 -0000

This is a multi-part message in MIME format.
--------------080407090404020004080001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



fred@cisco.com wrote:
> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.
> Please read it now. If you find nits (spelling errors, minor suggested
> wording changes, etc), comment to the authors; if you find greater
> issues, such as disagreeing with a statement or finding additional
> issues that need to be addressed, please post your comments to the
> list.
>
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.
>
>
I have read this draft. I understand the motivation, it is clearly 
written, and I support it.

Minor Suggestions:

I'd reference 4861 in the first sentence of the intro.
s/Routing information is communicated to IPv6 hosts by Router 
Advertisement messages. /Routing information is communicated to IPv6 
hosts by Router Advertisement messages [RFC4861]/

Recommendation 2 is redundant IMHO. THere's no way a router manufacturer 
can really know if the devices it is serving are battery powered devices 
or not (perhaps the subject of another draft e.g. perhaps extension to 
4620 to discover this via NI on creating a new ND cache entry?)

For recommendation 3: the timing recommendations should be more 
concrete, provided rough consensus can be achieved. In order to maximize 
the benefit I'd suggest specifying the upper end of the suggested ranges.

s/Networks that serve battery-powered devices /Routers with network 
interfaces that are known to serve battery-powered devices/



-- 
regards,
RayH


--------------080407090404020004080001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit







fred@cisco.com wrote:



  
This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.






I have read this draft. I understand the motivation, it is clearly 
written, and I support it.



Minor Suggestions:




I'd reference 4861 in the first sentence of the intro.


s/Routing information is communicated to IPv6 hosts by Router 
Advertisement messages. /Routing information is communicated to IPv6 
hosts by Router Advertisement messages [RFC4861]/



Recommendation 2 is redundant IMHO. THere's no way a router manufacturer
 can really know if the devices it is serving are battery powered 
devices or not (perhaps the subject of another draft e.g. perhaps 
extension to 4620 to discover this via NI on creating a new ND cache 
entry?)



For recommendation 3: the timing recommendations should be more 
concrete, provided rough consensus can be achieved. In order to maximize
 the benefit I'd suggest specifying the upper end of the suggested 
ranges.



s/Networks that serve battery-powered devices /Routers with network 
interfaces that are known to serve battery-powered devices/ 








-- 


regards,

RayH

  





--------------080407090404020004080001--


From nobody Thu Aug 27 06:38: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 76A4D1A1BDC for ; Thu, 27 Aug 2015 06:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf_MpOYIg_kP for ; Thu, 27 Aug 2015 06:38:50 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0: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 11CBE1A8860 for ; Thu, 27 Aug 2015 06:38:50 -0700 (PDT)
Received: by vkd66 with SMTP id 66so9154254vkd.0 for ; Thu, 27 Aug 2015 06:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=fnAPU8X5gHwD2a3dnJCEYRC5kOTZdnR96rwKudGc0bk=; b=O082Qrn6PaIrpZKWau814m2XyDmkULillbmdRQBcG6UbGkLBosSsSvUP8M7FrN3okL ESEfPb5K4milf1jxtw+y8ZtlvEVikA1HL2K7iun07SXqSzbdwxFfoTQerhJOFOu88Ro/ NAYVxTzWkWv6Um4bU43I+/aBqGza6l87b+tlqHg4rfv0jfVu1Bn38oWdULrQ4Rzi6Uvs 5mOaq5SnkQltDN3vzQoHtKIN1686fMkkwYCPnBaVZhMrQTxdzeT/0mr1MfETo65MPh8m Bw2XXJQbmgozKQLgD/xLP361R9qZN/9K5sY1s756VBqTLawMZ3YHOlNy1Ow1ijUQf1aw MTeA==
X-Received: by 10.52.119.212 with SMTP id kw20mr4549309vdb.42.1440682729333; Thu, 27 Aug 2015 06:38:49 -0700 (PDT)
Received: from [172.20.27.214] ([190.213.5.99]) by smtp.googlemail.com with ESMTPSA id aa1sm454721vdc.28.2015.08.27.06.38.48 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 06:38:48 -0700 (PDT)
To: v6ops@ietf.org
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>
From: Alejandro Acosta 
Message-ID: <55DF12E0.6040603@gmail.com>
Date: Thu, 27 Aug 2015 09:08:40 -0430
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <55DF0CEB.5040500@globis.net>
Content-Type: multipart/alternative; boundary="------------000807010707080008060109"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 27 Aug 2015 13:38:52 -0000

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

Hello,
  I fully support this draft, in fact, I believe that all draft should
have a mandatory "Eco-friendly" section.

  My comments:

In section 3 - Consequences


   o  Some hosts simply experience bad battery life on these networks
      and otherwise operate normally.  This is frustrating for users of
      these networks.

 
  The sentence: "This is frustrating for users of   these networks." 
does not convince me. The impact of a bad battery life is quite big, to
say it's just "frustrating" IMHO is not enough. I think it should be
remove or create a stronger sentence.


In section 4.2:


   2.  Networks that serve large numbers (tens or hundreds) of battery-
       powered devices SHOULD enable this behaviour.


  This might be a dummy question but I wonder if this is automatic or
something that will be adjusted by the administrator (or both). Probably
we could be more specific in this section, I mean, just to be more clear.


Regards,

Alejandro,

El 8/27/2015 a las 8:43 AM, Ray Hunter (v6ops) escribió:
>
>
> fred@cisco.com wrote:
>> This is to initiate a two week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.  
>> Please read it now. If you find nits (spelling errors, minor suggested
>> wording changes, etc), comment to the authors; if you find greater
>> issues, such as disagreeing with a statement or finding additional
>> issues that need to be addressed, please post your comments to the
>> list.
>>
>> We are looking specifically for comments on the importance of the
>> document as well as its content. If you have read the document and
>> believe it to be of operational utility, that is also an important
>> comment to make.
>>
>>
> I have read this draft. I understand the motivation, it is clearly
> written, and I support it.
>
> Minor Suggestions:
>
> I'd reference 4861 in the first sentence of the intro.
> s/Routing information is communicated to IPv6 hosts by Router
> Advertisement messages. /Routing information is communicated to IPv6
> hosts by Router Advertisement messages [RFC4861]/
>
> Recommendation 2 is redundant IMHO. THere's no way a router
> manufacturer can really know if the devices it is serving are battery
> powered devices or not (perhaps the subject of another draft e.g.
> perhaps extension to 4620 to discover this via NI on creating a new ND
> cache entry?)
>
> For recommendation 3: the timing recommendations should be more
> concrete, provided rough consensus can be achieved. In order to
> maximize the benefit I'd suggest specifying the upper end of the
> suggested ranges.
>
> s/Networks that serve battery-powered devices /Routers with network
> interfaces that are known to serve battery-powered devices/
>
>
>
> -- 
> regards,
> RayH
> 
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--------------000807010707080008060109
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello,

        I fully support this draft, in fact, I believe that all draft
      should have a mandatory "Eco-friendly" section.

      

        My comments:

      

      In section 3 - Consequences

      

      

         o  Some hosts simply experience bad battery life on these
      networks

            and otherwise operate normally.  This is frustrating for
      users of

            these networks.

      

        

        The sentence: "This is frustrating for users of   these
      networks."  does not convince me. The impact of a bad battery life
      is quite big, to say it's just "frustrating" IMHO is not enough. I
      think it should be remove or create a stronger sentence. 

      

      

      In section 4.2:

      

      

         2.  Networks that serve large numbers (tens or hundreds) of
      battery-

             powered devices SHOULD enable this behaviour.

      

      

        This might be a dummy question but I wonder if this is automatic
      or something that will be adjusted by the administrator (or both).
      Probably we could be more specific in this section, I mean, just
      to be more clear. 

      

      

      Regards,

      

      Alejandro,

      

      El 8/27/2015 a las 8:43 AM, Ray Hunter (v6ops) escribió:

    

    

      
      

      

      fred@cisco.com wrote:

      

        
This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.




      

      I have read this draft. I understand the motivation, it is clearly
      written, and I support it.

      

      Minor Suggestions:

      

      I'd reference 4861 in the first sentence of the intro.

      s/Routing information is communicated to IPv6 hosts by Router
      Advertisement messages. /Routing information is communicated to
      IPv6 hosts by Router Advertisement messages [RFC4861]/

      

      Recommendation 2 is redundant IMHO. THere's no way a router
      manufacturer can really know if the devices it is serving are
      battery powered devices or not (perhaps the subject of another
      draft e.g. perhaps extension to 4620 to discover this via NI on
      creating a new ND cache entry?)

      

      For recommendation 3: the timing recommendations should be more
      concrete, provided rough consensus can be achieved. In order to
      maximize the benefit I'd suggest specifying the upper end of the
      suggested ranges.

      

      s/Networks that serve battery-powered devices /Routers with
      network interfaces that are known to serve battery-powered
      devices/ 

      

      

      

      
-- 

        
regards,

          RayH

          

      

      

      

      

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


    

    

  


--------------000807010707080008060109--


From nobody Thu Aug 27 08: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 AC19E1B2B56 for ; Thu, 27 Aug 2015 08:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlGa9N7VCSui for ; Thu, 27 Aug 2015 08:20:30 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 040BA1B2B48 for ; Thu, 27 Aug 2015 08:20:30 -0700 (PDT)
Received: by igbjg10 with SMTP id jg10so69858411igb.0 for ; Thu, 27 Aug 2015 08:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tPTJtZWvzei25SJ+UOe46svEqKYnsTUkknkhEOO2Q6o=; b=BRr/abhEVboAb0bz17gTkbbUF3AetN5sEJXlBQgPZ/GMn8Lx+HM6IDSdRzEkFyNIU1 5jk5Bia+NAeMg3HkR49n4TT/3L5AGHORBDi9hHU9T8PdukCULyYY+7LBCI6/YdrgRY1a UNKmoxKeIYjPNnydJtD7VEqPfpLPquoNRcB+Zw7Z/Lr9FwJWJQSlidmIhUnqitwKekXB j5JFrbicwWqcX9bYyeB5htCjTOMgOX36LJp6K+tEhclK+okYtf50vF6P6cpUw5i1KlTX fjGHI2fY1j3xohJr1h7bAk6MptujWeVgTK7rXGV3JVd/dd1wDlaeZLtEAVmbOpAvV+tC sjag==
MIME-Version: 1.0
X-Received: by 10.50.102.4 with SMTP id fk4mr10860911igb.46.1440688829387; Thu, 27 Aug 2015 08:20:29 -0700 (PDT)
Received: by 10.107.13.2 with HTTP; Thu, 27 Aug 2015 08:20:29 -0700 (PDT)
In-Reply-To: <55DF0CEB.5040500@globis.net>
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>
Date: Thu, 27 Aug 2015 17:20:29 +0200
Message-ID: 
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= 
To: "Ray Hunter (v6ops)" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 27 Aug 2015 15:20:31 -0000

On 8/27/15, Ray Hunter (v6ops)  wrote:
>
>
> fred@cisco.com wrote:
>> This is to initiate a two week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.
>> Please read it now. If you find nits (spelling errors, minor suggested
>> wording changes, etc), comment to the authors; if you find greater
>> issues, such as disagreeing with a statement or finding additional
>> issues that need to be addressed, please post your comments to the
>> list.
>>
>> We are looking specifically for comments on the importance of the
>> document as well as its content. If you have read the document and
>> believe it to be of operational utility, that is also an important
>> comment to make.
>>
>>
> I have read this draft. I understand the motivation, it is clearly
> written, and I support it.
>
> Minor Suggestions:
>
> I'd reference 4861 in the first sentence of the intro.
> s/Routing information is communicated to IPv6 hosts by Router
> Advertisement messages. /Routing information is communicated to IPv6
> hosts by Router Advertisement messages [RFC4861]/

Thanks, noted!

>
> Recommendation 2 is redundant IMHO. THere's no way a router manufacturer
> can really know if the devices it is serving are battery powered devices
> or not (perhaps the subject of another draft e.g. perhaps extension to
> 4620 to discover this via NI on creating a new ND cache entry?)

It's not entirely redundant, the intent here is that this mechanism is
enabled on the network, which has two parts:

1) the equipment on the network has an option to enable it. (e.g. the
administrator needs to ensure that their equipment supports it).

2) the administrator has enabled it. (e.g. today's Cisco
implementation simply has the command "ipv6 nd ra solicited unicast"
which needs to be configured).

How about a small tweak as below:

"2) Administrators of networks that serve large numbers (tens or
hundreds) of battery-
       powered devices SHOULD enable this behaviour."

>
> For recommendation 3: the timing recommendations should be more
> concrete, provided rough consensus can be achieved. In order to maximize
> the benefit I'd suggest specifying the upper end of the suggested ranges.

I tend to configure such networks with the RA interval of 1800
seconds, with router lifetime of 9000 seconds (and when
draft-krishnan-6man-maxra gets through, will be happy to bump those
values up to 21K and 64K respectively). Lorenzo's take is that "every
few minutes is already much better than every 3 seconds".

So, based on my today's knowledge the upper limit is whatever is
enforced by the protocol + the usual "three-RA-per-lifetime" rule of
thumb - which looks to be in line with the text in the draft that does
not specify any upper bound.

Does the text suggest differently ?

>
> s/Networks that serve battery-powered devices /Routers with network
> interfaces that are known to serve battery-powered devices/
>

Thanks, noted!

--a

>
>
> --
> regards,
> RayH
> 
>


From nobody Thu Aug 27 08:31: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 0F87B1B2AD5 for ; Thu, 27 Aug 2015 08:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3JzoriJujsu for ; Thu, 27 Aug 2015 08:31:25 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 686A81B2A64 for ; Thu, 27 Aug 2015 08:31:24 -0700 (PDT)
Received: by igbjg10 with SMTP id jg10so19427759igb.0 for ; Thu, 27 Aug 2015 08:31:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=g81a2yFsMLeKJBqrpxB64yYUI63QSxGz0at6Hb+38GE=; b=sG46eHczqUGjhv8Ghk/SLb8yDHQt5Ng5AFVs31k5IZOd1IMeuILSz3nHmpDYSieeGE UODJoKrntZk1Rt/FBn17gWJIhLUtxq5ojkuNQ1MBdxmWZ4ehBH0ypmPomiTgn/T12Cbs o4xmahGyNj+gqxQDWKM1lRvFcWTTNOea/p9hqGwP+h34YST1EbyFnakmL0ozqfDjZDX4 uFQVWeBM6TkzqcBQ8fIRrhs3N24+DLYOuMPFj8Arcspdq2OWVOeR+LB8Z6qnyyqRz1/m II8k6Qw3ybPIpzJNKPk1S1mrHCGPJs3Jo00g/AKxNmdUBJv9qCtaVq+BGl/ldKxIJdOp f5tQ==
MIME-Version: 1.0
X-Received: by 10.50.138.232 with SMTP id qt8mr17964503igb.21.1440689483857; Thu, 27 Aug 2015 08:31:23 -0700 (PDT)
Received: by 10.107.13.2 with HTTP; Thu, 27 Aug 2015 08:31:23 -0700 (PDT)
In-Reply-To: <55DF12E0.6040603@gmail.com>
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net> <55DF12E0.6040603@gmail.com>
Date: Thu, 27 Aug 2015 17:31:23 +0200
Message-ID: 
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= 
To: Alejandro Acosta 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 27 Aug 2015 15:31:27 -0000

Hello Alejandro,

On 8/27/15, Alejandro Acosta  wrote:
> Hello,
>   I fully support this draft, in fact, I believe that all draft should
> have a mandatory "Eco-friendly" section.
>
>   My comments:
>
> In section 3 - Consequences
>
>
>    o  Some hosts simply experience bad battery life on these networks
>       and otherwise operate normally.  This is frustrating for users of
>       these networks.
>
>
>   The sentence: "This is frustrating for users of   these networks."
> does not convince me. The impact of a bad battery life is quite big, to
> say it's just "frustrating" IMHO is not enough. I think it should be
> remove or create a stronger sentence.

If Lorenzo agrees, I'd opt for removing the sentence about the
frustrated users.

>
>
> In section 4.2:
>
>
>    2.  Networks that serve large numbers (tens or hundreds) of battery-
>        powered devices SHOULD enable this behaviour.
>
>
>   This might be a dummy question but I wonder if this is automatic or
> something that will be adjusted by the administrator (or both). Probably
> we could be more specific in this section, I mean, just to be more clear.

Yeah, looks like this text needs tweaking - both you and Ray has
commented on it, copypasting from my reply to him, so to check with
you:

How about a small tweak as below:

"2) Administrators of networks that serve large numbers (tens or
hundreds) of battery-
       powered devices SHOULD enable this behaviour."

--a


>
>
> Regards,
>
> Alejandro,
>
> El 8/27/2015 a las 8:43 AM, Ray Hunter (v6ops) escribi=C3=B3:
>>
>>
>> fred@cisco.com wrote:
>>> This is to initiate a two week working group last call of
>>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumpt=
ion.
>>>
>>> Please read it now. If you find nits (spelling errors, minor suggested
>>> wording changes, etc), comment to the authors; if you find greater
>>> issues, such as disagreeing with a statement or finding additional
>>> issues that need to be addressed, please post your comments to the
>>> list.
>>>
>>> We are looking specifically for comments on the importance of the
>>> document as well as its content. If you have read the document and
>>> believe it to be of operational utility, that is also an important
>>> comment to make.
>>>
>>>
>> I have read this draft. I understand the motivation, it is clearly
>> written, and I support it.
>>
>> Minor Suggestions:
>>
>> I'd reference 4861 in the first sentence of the intro.
>> s/Routing information is communicated to IPv6 hosts by Router
>> Advertisement messages. /Routing information is communicated to IPv6
>> hosts by Router Advertisement messages [RFC4861]/
>>
>> Recommendation 2 is redundant IMHO. THere's no way a router
>> manufacturer can really know if the devices it is serving are battery
>> powered devices or not (perhaps the subject of another draft e.g.
>> perhaps extension to 4620 to discover this via NI on creating a new ND
>> cache entry?)
>>
>> For recommendation 3: the timing recommendations should be more
>> concrete, provided rough consensus can be achieved. In order to
>> maximize the benefit I'd suggest specifying the upper end of the
>> suggested ranges.
>>
>> s/Networks that serve battery-powered devices /Routers with network
>> interfaces that are known to serve battery-powered devices/
>>
>>
>>
>> --
>> regards,
>> RayH
>> 
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>


From nobody Thu Aug 27 08:39: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 7A4C81AC445 for ; Thu, 27 Aug 2015 08:39:13 -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 9QDT6EO8DtmA for ; Thu, 27 Aug 2015 08:39:12 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22901A6F28 for ; Thu, 27 Aug 2015 08:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2161; q=dns/txt; s=iport; t=1440689951; x=1441899551; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=QZSH+rIb5qSwttc2Y4LGlhd1f+2LrY58bD1UpPd1sAM=; b=Yug/7vSxYUtsL8c63PhaftrqU8zKFDQHe8n71l+6CkpjgqOuWrnogeZ8 y3MPe2f9sKyYVaU3dPqnYYpEnhRDIMS2Ylns0Y4wRFQGjiDUqgx811qRK PGHHeLG1pIfdZ6EP6Ln7gKDMsvJ8TstMb0k5j5R4XPqedHWBpAZug6+bV M=;
X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="606629093"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 27 Aug 2015 15:39:10 +0000
Received: from dhcp-10-149-4-97.cisco.com (dhcp-10-149-4-97.cisco.com [10.149.4.97]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t7RFd93f011784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Aug 2015 15:39:09 GMT
Date: Thu, 27 Aug 2015 17:39:12 +0200 (CEST)
From: Andrew Yourtchenko 
X-X-Sender: ayourtch@ayourtch-mac
To: =?ISO-2022-JP?Q?=1B$B=3F=40L=40C#=3AH=1B=28J?= 
In-Reply-To: 
Message-ID: 
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> 
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="0-247922532-1440689953=:68676"
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 27 Aug 2015 15:39:13 -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.

--0-247922532-1440689953=:68676
Content-Type: text/plain; charset=ISO-2022-JP; format=flowed

On Tue, 25 Aug 2015, $B?@L@C#:H(J wrote:

> At Sun, 23 Aug 2015 11:00:01 -0700,
> fred@cisco.com wrote:
>
>> This is to initiate a two week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.
>> Please read it now. If you find nits (spelling errors, minor suggested
>> wording changes, etc), comment to the authors; if you find greater
>> issues, such as disagreeing with a statement or finding additional
>> issues that need to be addressed, please post your comments to the
>> list.
>>
>> We are looking specifically for comments on the importance of the
>> document as well as its content. If you have read the document and
>> believe it to be of operational utility, that is also an important
>> comment to make.
>
> I've read the draft.  It's well-written, and I think the topic and its
> content are useful.
>
> I have one minor comment on Section 2.2:
>
>   Some networks send periodic multicast Router Advertisements (e.g.,
>   once every few seconds).
>
> I guess the intent here is explain non-default cases where multicast
> RAs are sent out very frequently (correct?).  But the actual text
> doesn't necessarily read that way to me, since sending multicast RAs
> periodically is the default behavior per RFC4861, and the default
> interval is between 200sec and 600sec.  Assuming my interpretation of
> the intent is correct, I suggest revising this sentence as follows:
>
>   Some networks send periodic multicast Router Advertisements very
>   frequently (e.g., once every few seconds).

Thanks for the catch, I think this was exactly what we intended to say 
here, I've noted it down.

--a

>
> --
> JINMEI, Tatuya
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
--0-247922532-1440689953=:68676--


From nobody Thu Aug 27 08:54: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 E6C2E1B2E7E for ; Thu, 27 Aug 2015 08:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u2EF9G1oNCF for ; Thu, 27 Aug 2015 08:54:43 -0700 (PDT)
Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 D58981B2D34 for ; Thu, 27 Aug 2015 08:54:42 -0700 (PDT)
Received: by ykbi184 with SMTP id i184so24401070ykb.2 for ; Thu, 27 Aug 2015 08:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=9LImys+yilUVRDR+JVSgh5gAmb8zOFvdsP20Nv0+XQc=; b=XkWwSA+nu5rF8/sGqEEL7TimdsvUmDKKXxzP9BGYGPpIJ2F8BVWEO8byLpC71o9uKf COEE/9b84qnTgnsgzYADRTmnwWzd5sxnSLgReNE0Ni0xW6FLupEXEutFcpZBAYiYCgBj lle8SF2dmNGLnsB/8KHPj/lxbtR7Cs7KYEIhUxkyRaSCPUgb5sKcD61m9dtdvPjhA2pR cLY7G1Q348IlQEPbJ9WQReK9i0j+tlP+1wQnC4kYQ5mNtpUb+8jej4gYojuzSmunbtjX fvZLbdxIGbDu2Yzg6VrAL5UJbYFrs1TJk69+FmMbVbqDU86hiCrfJCBFwS4Ii4otj0pO kE7g==
X-Received: by 10.129.52.209 with SMTP id b200mr3835403ywa.58.1440690882221; Thu, 27 Aug 2015 08:54:42 -0700 (PDT)
Received: from [172.20.27.214] ([190.213.5.99]) by smtp.googlemail.com with ESMTPSA id p20sm2113566ywe.42.2015.08.27.08.54.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 08:54:40 -0700 (PDT)
To: =?UTF-8?Q?Andrew_=f0=9f=91=bd_Yourtchenko?= 
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net> <55DF12E0.6040603@gmail.com> 
From: Alejandro Acosta 
X-Enigmail-Draft-Status: N1110
Message-ID: <55DF32C1.6000504@gmail.com>
Date: Thu, 27 Aug 2015 11:24:41 -0430
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 27 Aug 2015 15:54:45 -0000

Hello Andrew,
  Inline:

El 8/27/2015 a las 11:01 AM, Andrew 👽 Yourtchenko escribió:
> Hello Alejandro,
>
> On 8/27/15, Alejandro Acosta  wrote:
>> Hello,
>>   I fully support this draft, in fact, I believe that all draft should
>> have a mandatory "Eco-friendly" section.
>>
>>   My comments:
>>
>> In section 3 - Consequences
>>
>>
>>    o  Some hosts simply experience bad battery life on these networks
>>       and otherwise operate normally.  This is frustrating for users of
>>       these networks.
>>
>>
>>   The sentence: "This is frustrating for users of   these networks."
>> does not convince me. The impact of a bad battery life is quite big, to
>> say it's just "frustrating" IMHO is not enough. I think it should be
>> remove or create a stronger sentence.
> If Lorenzo agrees, I'd opt for removing the sentence about the
> frustrated users.

Perfect

>
>>
>> In section 4.2:
>>
>>
>>    2.  Networks that serve large numbers (tens or hundreds) of battery-
>>        powered devices SHOULD enable this behaviour.
>>
>>
>>   This might be a dummy question but I wonder if this is automatic or
>> something that will be adjusted by the administrator (or both). Probably
>> we could be more specific in this section, I mean, just to be more clear.
> Yeah, looks like this text needs tweaking - both you and Ray has
> commented on it, copypasting from my reply to him, so to check with
> you:
>
> How about a small tweak as below:
>
> "2) Administrators of networks that serve large numbers (tens or
> hundreds) of battery-
>        powered devices SHOULD enable this behaviour."

It sounds ok to me.
In the future (and not that far away) another draft could be written
about making routers smarter.., I mean, they can recognize the number of
devices in the network (in your example tens or hundreds) and change the
behavior automatically to your draft. It looks feasible to me.

Regards,


>
> --a
>
>
>>
>> Regards,
>>
>> Alejandro,
>>
>> El 8/27/2015 a las 8:43 AM, Ray Hunter (v6ops) escribió:
>>>
>>> fred@cisco.com wrote:
>>>> This is to initiate a two week working group last call of
>>>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.
>>>>
>>>> Please read it now. If you find nits (spelling errors, minor suggested
>>>> wording changes, etc), comment to the authors; if you find greater
>>>> issues, such as disagreeing with a statement or finding additional
>>>> issues that need to be addressed, please post your comments to the
>>>> list.
>>>>
>>>> We are looking specifically for comments on the importance of the
>>>> document as well as its content. If you have read the document and
>>>> believe it to be of operational utility, that is also an important
>>>> comment to make.
>>>>
>>>>
>>> I have read this draft. I understand the motivation, it is clearly
>>> written, and I support it.
>>>
>>> Minor Suggestions:
>>>
>>> I'd reference 4861 in the first sentence of the intro.
>>> s/Routing information is communicated to IPv6 hosts by Router
>>> Advertisement messages. /Routing information is communicated to IPv6
>>> hosts by Router Advertisement messages [RFC4861]/
>>>
>>> Recommendation 2 is redundant IMHO. THere's no way a router
>>> manufacturer can really know if the devices it is serving are battery
>>> powered devices or not (perhaps the subject of another draft e.g.
>>> perhaps extension to 4620 to discover this via NI on creating a new ND
>>> cache entry?)
>>>
>>> For recommendation 3: the timing recommendations should be more
>>> concrete, provided rough consensus can be achieved. In order to
>>> maximize the benefit I'd suggest specifying the upper end of the
>>> suggested ranges.
>>>
>>> s/Networks that serve battery-powered devices /Routers with network
>>> interfaces that are known to serve battery-powered devices/
>>>
>>>
>>>
>>> --
>>> regards,
>>> RayH
>>> 
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>


From nobody Thu Aug 27 20:51: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 26D5C1B3382 for ; Thu, 27 Aug 2015 20:51:35 -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 5ujedLTqVjNV for ; Thu, 27 Aug 2015 20:51:32 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE1E1B3292 for ; Thu, 27 Aug 2015 20:51:31 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAM97599; Fri, 28 Aug 2015 03:51:29 +0000 (GMT)
Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 28 Aug 2015 04:51:25 +0100
Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.156]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Fri, 28 Aug 2015 11:51:21 +0800
From: "Liushucheng (Will)" 
To: "draft-ietf-v6ops-host-addr-availability@tools.ietf.org" 
Thread-Topic: Review for draft-ietf-v6ops-host-addr-availability
Thread-Index: AdDhRK8mEsSwFY5dTgqAjgOzIUGw1g==
Date: Fri, 28 Aug 2015 03:51:20 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.78.84]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: [v6ops] Review for draft-ietf-v6ops-host-addr-availability
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Aug 2015 03:51:35 -0000

Hi all,

After taking a look at this draft, I feet it practical and agree to the poi=
nt, with some comments below (most are clarifying ones).

Section 4:
>   Assigning a limited number of addresses per host implies that
>   functions that require multiple addresses will either be unavailable
>   (e.g., if the network provides only one IPv6 address per host, or if
>   the host has reached the limit of the number of addresses available),
>   or that the functions will only be available after an explicit
>   request to the network is granted.  The necessity of explicit

Could you explicitly point out which "functions" or add a reference?


Section 6:
>    o  Using Stateless Address Autoconfiguration [RFC4862].  SLAAC allows
>       hosts to create global IPv6 addresses on demand by simply forming
>       new addresses from the global prefix assigned to the link.

Traditional slaac only allows for a single stable address, since the addres=
s is generated by embedding the underlying mac address.

>  It is also possible for a client to
>       request additional addresses using a different DUID.

Would this really comply with the spirit of DHCPv6?

> Immune to layer 3 on-  |    No   |    Yes     |   Yes   |   Yes   |
>    | link resource          |         |            |         |         |
>    | exhaustion attack

What do you mean by "Immune to layer 3 on-link resource exhaustion attack"?

Section 7:
>In
>   typical implementations, privacy addresses use up to 8 addresses (one
>   per day). =20

Any reference?


NITS

Section 1:
s/adressing/addressing/

Section 6:
> The prefix can also be
>       hierarchically delegated to downstream clients, or, if it is a
>       /64, it be reshared with downstream clients via ND proxying
>       [RFC4389] or /64 sharing [RFC7278]

s/it be reshared/be reshared/

Section 9.1:
>=20
>    Some network operators - often operators of networks that provide
>    services to third parties such as university campus networks - have
>    made the argument that the only feasible IPv6 deployment mechanism is
>    DHCPv6, due to the need to be able to track at all times IPv6
>    addresses are assigned to which hosts.

s/times IPv6 addresses are assigned to which hosts/times which IPv6 address=
es are assigned to which hosts/

Section 9.2:
s/which is is/which is/

Regards,
Will


From nobody Fri Aug 28 01:10: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 0907E1B2EE1 for ; Fri, 28 Aug 2015 01:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.381
X-Spam-Level: ***
X-Spam-Status: No, score=3.381 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qepittVUA1Tl for ; Fri, 28 Aug 2015 01:10:08 -0700 (PDT)
Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 7715A1B31B9 for ; Fri, 28 Aug 2015 01:10:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DB7D54005A; Fri, 28 Aug 2015 10:10:06 +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 z7BkxyJnQQvF; Fri, 28 Aug 2015 10:10:01 +0200 (CEST)
Received: from Rays-MacBook-Pro.local (d75067.upc-d.chello.nl [213.46.75.67]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0416140028; Fri, 28 Aug 2015 10:10:00 +0200 (CEST)
Message-ID: <55E01757.7080208@globis.net>
Date: Fri, 28 Aug 2015 10:09:59 +0200
From: "Ray Hunter (v6ops)" 
User-Agent: Postbox 4.0.3 (Macintosh/20150805)
MIME-Version: 1.0
To: =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= 
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040200080407050508010800"
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 28 Aug 2015 08:10:11 -0000

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

inline.

> Andrew 👽 Yourtchenko 
> 27 Aug 2015 17:20
> On 8/27/15, Ray Hunter (v6ops)  wrote:
>> fred@cisco.com wrote:
>>> This is to initiate a two week working group last call of
>>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.
>>> Please read it now. If you find nits (spelling errors, minor suggested
>>> wording changes, etc), comment to the authors; if you find greater
>>> issues, such as disagreeing with a statement or finding additional
>>> issues that need to be addressed, please post your comments to the
>>> list.
>>>
>>> We are looking specifically for comments on the importance of the
>>> document as well as its content. If you have read the document and
>>> believe it to be of operational utility, that is also an important
>>> comment to make.
>>>
>>>
>> I have read this draft. I understand the motivation, it is clearly
>> written, and I support it.
>>
>> Minor Suggestions:
>>
>> I'd reference 4861 in the first sentence of the intro.
>> s/Routing information is communicated to IPv6 hosts by Router
>> Advertisement messages. /Routing information is communicated to IPv6
>> hosts by Router Advertisement messages [RFC4861]/
>
> Thanks, noted!
>
>> Recommendation 2 is redundant IMHO. THere's no way a router manufacturer
>> can really know if the devices it is serving are battery powered devices
>> or not (perhaps the subject of another draft e.g. perhaps extension to
>> 4620 to discover this via NI on creating a new ND cache entry?)
>
> It's not entirely redundant, the intent here is that this mechanism is
> enabled on the network, which has two parts:
>
> 1) the equipment on the network has an option to enable it. (e.g. the
> administrator needs to ensure that their equipment supports it).
>
> 2) the administrator has enabled it. (e.g. today's Cisco
> implementation simply has the command "ipv6 nd ra solicited unicast"
> which needs to be configured).
>
> How about a small tweak as below:
>
> "2) Administrators of networks that serve large numbers (tens or
> hundreds) of battery-
>         powered devices SHOULD enable this behaviour."
Works for me.
>> For recommendation 3: the timing recommendations should be more
>> concrete, provided rough consensus can be achieved. In order to maximize
>> the benefit I'd suggest specifying the upper end of the suggested ranges.
>
> I tend to configure such networks with the RA interval of 1800
> seconds, with router lifetime of 9000 seconds (and when
> draft-krishnan-6man-maxra gets through, will be happy to bump those
> values up to 21K and 64K respectively). Lorenzo's take is that "every
> few minutes is already much better than every 3 seconds".
>
> So, based on my today's knowledge the upper limit is whatever is
> enforced by the protocol + the usual "three-RA-per-lifetime" rule of
> thumb - which looks to be in line with the text in the draft that does
> not specify any upper bound.
>
> Does the text suggest differently ?
No, but it specifies an absolute value without explaining how that value 
is derived.

So if the protocols ever change, the BCP value may no longer appropriate 
e.g. if draft-krishnan-6man-maxra becomes a standard.

Why not specify in terms of the upper limit of the protocol, and 
formula, rather than a specific time?

e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writing 
is 1800 seconds (derived from RFC4861 Section 6.2.1)

Suggested text:

s/Networks that serve battery-powered devices SHOULD NOT send
        multicast RAs too frequently (e.g., more than one every 5-10
        minutes for current battery-powered devices) unless the
        information in the RA packet has substantially changed.  If there
        is a desire to ensure that hosts pick up configuration changes
        quickly, those networks MAY send frequent Router Advertisements
        for a limited period of time (e.g., not more than one minute)
        immediately after a configuration change./

3. Routers with network interfaces that are known to serve 
battery-powered devices SHOULD NOT send multicast RAs too frequently 
unless the information in the RA packet has substantially changed.

The BCP value for MinRtrAdvInterval can be derived using the formula 
0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the 
maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861 
Section 6.2.1] suggesting MaxRtrAdvInterval = 1800 and MinRtrAdvInterval 
= 600 seconds.

4. If there is a desire to ensure that hosts pick up configuration 
changes quickly, those router interfaces MAY send frequent multicast RA 
for a limited period of time immediately after a configuration change.

A suggested (arbritary) time limit for this behavior is one minute.
/

>> s/Networks that serve battery-powered devices /Routers with network
>> interfaces that are known to serve battery-powered devices/
>>
>
> Thanks, noted!
>
> --a
>
>> --
>> regards,
>> RayH
>> 
>>
>

-- 
regards,
RayH


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



inline.







  
      
     27 
Aug 2015 17:20
    

  
On 8/27/15, Ray Hunter (v6ops) <v6ops@globis.net> wrote:

fred@cisco.com wrote:

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.



I have read this draft. I understand the motivation, it is clearly
written, and I support it.

Minor Suggestions:

I'd reference 4861 in the first sentence of the intro.
s/Routing information is communicated to IPv6 hosts by Router
Advertisement messages. /Routing information is communicated to IPv6
hosts by Router Advertisement messages [RFC4861]/


Thanks, noted!


Recommendation 2 is redundant IMHO. THere's no way a router manufacturer
can really know if the devices it is serving are battery powered devices
or not (perhaps the subject of another draft e.g. perhaps extension to
4620 to discover this via NI on creating a new ND cache entry?)


It's not entirely redundant, the intent here is that this mechanism is
enabled on the network, which has two parts:

1) the equipment on the network has an option to enable it. (e.g. the
administrator needs to ensure that their equipment supports it).

2) the administrator has enabled it. (e.g. today's Cisco
implementation simply has the command "ipv6 nd ra solicited unicast"
which needs to be configured).

How about a small tweak as below:

"2) Administrators of networks that serve large numbers (tens or
hundreds) of battery-
       powered devices SHOULD enable this behaviour."




Works for me.



  

    


For recommendation 3: the timing recommendations should be more
concrete, provided rough consensus can be achieved. In order to maximize
the benefit I'd suggest specifying the upper end of the suggested ranges.


I tend to configure such networks with the RA interval of 1800
seconds, with router lifetime of 9000 seconds (and when
draft-krishnan-6man-maxra gets through, will be happy to bump those
values up to 21K and 64K respectively). Lorenzo's take is that "every
few minutes is already much better than every 3 seconds".

So, based on my today's knowledge the upper limit is whatever is
enforced by the protocol + the usual "three-RA-per-lifetime" rule of
thumb - which looks to be in line with the text in the draft that does
not specify any upper bound.

Does the text suggest differently ?




No, but it specifies an absolute value without explaining how that value
 is derived.



So if the protocols ever change, the BCP value may no longer appropriate
 e.g. if draft-krishnan-6man-maxra becomes a standard.



Why not specify in terms of the upper limit of the protocol, and 
formula, rather than a specific time?



e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writing 
is 1800 seconds (derived from RFC4861 Section 6.2.1)



Suggested text:



s/Networks that serve battery-powered devices SHOULD NOT send

       multicast RAs too frequently (e.g., more than one every 5-10

       minutes for current battery-powered devices) unless the

       information in the RA packet has substantially changed.  If there

       is a desire to ensure that hosts pick up configuration changes

       quickly, those networks MAY send frequent Router Advertisements

       for a limited period of time (e.g., not more than one minute)

       immediately after a configuration change./



3. Routers with network
interfaces that are known to serve battery-powered devices SHOULD NOT 
send multicast RAs too frequently unless the information in the RA 
packet has substantially changed.



The BCP value for MinRtrAdvInterval can be derived using the formula 
0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the 
maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861 
Section 6.2.1] suggesting MaxRtrAdvInterval = 1800 and MinRtrAdvInterval
 = 600 seconds.



4. If there is a desire to ensure that hosts pick up configuration 
changes quickly, those router interfaces MAY send frequent multicast RA 
for a limited period of time immediately after a configuration change.



A suggested (arbritary) time limit for this behavior is one minute.

/





  

    


s/Networks that serve battery-powered devices /Routers with network
interfaces that are known to serve battery-powered devices/



Thanks, noted!

--a


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>



  






-- 


regards,

RayH

  





--------------040200080407050508010800--


From nobody Fri Aug 28 05:23: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 C5FB31A1B1B for ; Fri, 28 Aug 2015 05:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmJcCs4CX9GS for ; Fri, 28 Aug 2015 05:23:25 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 8BFE11A00E3 for ; Fri, 28 Aug 2015 05:23:19 -0700 (PDT)
Received: by iofe124 with SMTP id e124so25244496iof.1 for ; Fri, 28 Aug 2015 05:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dOgDo8KIfq7VKffn0IS008N/1z0O27dkhUkykv4j2iM=; b=p8Uqw9zCICuIAzzuNPWuakb3CMlrw0f/uBZ5xEfL/J0wRNXeeHEd3KRKj6b0ikhRMO FwE/nyDVsdL8dxIftFMeX3KnBnQxbTTiisYfIM9I8AUUdCrGMnyc35kVzNvMJXMd20NM 7xhYlumlU5eyYeriooOP8k1cai1JepQ3698a5eVgeiOV3VnlqvS6EwheJu0KmR11df1G oTOIKBf8q6sHpc5BYgHILoaGkMTBuuwBCzlG94IBQCsnye0UwzaMKPCB6Pmv6+GtYNjS jRS50YMkUr2/zSHCLYfCM0OxvO2XDEGMCMxwPMqF46SIXUH+0UmBU14yteM6tA3jWfQs 6NYw==
MIME-Version: 1.0
X-Received: by 10.107.39.142 with SMTP id n136mr6271193ion.193.1440764598847;  Fri, 28 Aug 2015 05:23:18 -0700 (PDT)
Received: by 10.107.13.2 with HTTP; Fri, 28 Aug 2015 05:23:18 -0700 (PDT)
In-Reply-To: <55E01757.7080208@globis.net>
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>  <55E01757.7080208@globis.net>
Date: Fri, 28 Aug 2015 14:23:18 +0200
Message-ID: 
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= 
To: "Ray Hunter (v6ops)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 28 Aug 2015 12:23:31 -0000

inline.

On 8/28/15, Ray Hunter (v6ops)  wrote:
> inline.
>
>> Andrew =F0=9F=91=BD Yourtchenko 
>> 27 Aug 2015 17:20
>> On 8/27/15, Ray Hunter (v6ops)  wrote:
>>> fred@cisco.com wrote:
>>>> This is to initiate a two week working group last call of
>>>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consump=
tion.
>>>> Please read it now. If you find nits (spelling errors, minor suggested
>>>> wording changes, etc), comment to the authors; if you find greater
>>>> issues, such as disagreeing with a statement or finding additional
>>>> issues that need to be addressed, please post your comments to the
>>>> list.
>>>>
>>>> We are looking specifically for comments on the importance of the
>>>> document as well as its content. If you have read the document and
>>>> believe it to be of operational utility, that is also an important
>>>> comment to make.
>>>>
>>>>
>>> I have read this draft. I understand the motivation, it is clearly
>>> written, and I support it.
>>>
>>> Minor Suggestions:
>>>
>>> I'd reference 4861 in the first sentence of the intro.
>>> s/Routing information is communicated to IPv6 hosts by Router
>>> Advertisement messages. /Routing information is communicated to IPv6
>>> hosts by Router Advertisement messages [RFC4861]/
>>
>> Thanks, noted!
>>
>>> Recommendation 2 is redundant IMHO. THere's no way a router manufacture=
r
>>> can really know if the devices it is serving are battery powered device=
s
>>> or not (perhaps the subject of another draft e.g. perhaps extension to
>>> 4620 to discover this via NI on creating a new ND cache entry?)
>>
>> It's not entirely redundant, the intent here is that this mechanism is
>> enabled on the network, which has two parts:
>>
>> 1) the equipment on the network has an option to enable it. (e.g. the
>> administrator needs to ensure that their equipment supports it).
>>
>> 2) the administrator has enabled it. (e.g. today's Cisco
>> implementation simply has the command "ipv6 nd ra solicited unicast"
>> which needs to be configured).
>>
>> How about a small tweak as below:
>>
>> "2) Administrators of networks that serve large numbers (tens or
>> hundreds) of battery-
>>         powered devices SHOULD enable this behaviour."
> Works for me.
>>> For recommendation 3: the timing recommendations should be more
>>> concrete, provided rough consensus can be achieved. In order to maximiz=
e
>>> the benefit I'd suggest specifying the upper end of the suggested
>>> ranges.
>>
>> I tend to configure such networks with the RA interval of 1800
>> seconds, with router lifetime of 9000 seconds (and when
>> draft-krishnan-6man-maxra gets through, will be happy to bump those
>> values up to 21K and 64K respectively). Lorenzo's take is that "every
>> few minutes is already much better than every 3 seconds".
>>
>> So, based on my today's knowledge the upper limit is whatever is
>> enforced by the protocol + the usual "three-RA-per-lifetime" rule of
>> thumb - which looks to be in line with the text in the draft that does
>> not specify any upper bound.
>>
>> Does the text suggest differently ?
> No, but it specifies an absolute value without explaining how that value
> is derived.

no, it specifies a *lower limit* - it tells the networks in question
should send the RAs with the interval *bigger* than X - so it's not
subject to change if the protocol limit increases. OTOH the X is kinda
pulled out of the hat, I agree.

So, how about the following change instead:

s/Networks that serve battery-powered devices SHOULD NOT send
        multicast RAs too frequently (e.g., more than one every 5-10
        minutes for current battery-powered devices) unless the
        information in the RA packet has substantially changed.  /

Networks that serve battery-powered devices should try to maximize the
interval between the  multicast RAs within the limits allowed by
protocol - unless the information in the RA packet has changed. On the
other hand, the maximum value should be bound to allow a sufficient
number of RAs to be sent within the router/prefix lifetimes - to
account for the potential packet loss in the wireless network. This
packet loss will depend on the quality of the radio spectrum/coverage
and may need to be decided on a per-network basis. In the best-case
scenario one would ensure that at least 3 (a chosen arbitrary value)
RAs are transmitted within the smallest of the lifetimes for the
parameters contained within the RA.  /

Or something along these lines.

>
> So if the protocols ever change, the BCP value may no longer appropriate
> e.g. if draft-krishnan-6man-maxra becomes a standard.
>
> Why not specify in terms of the upper limit of the protocol, and
> formula, rather than a specific time?
>
> e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writing
> is 1800 seconds (derived from RFC4861 Section 6.2.1)
>
> Suggested text:
>
> s/Networks that serve battery-powered devices SHOULD NOT send
>         multicast RAs too frequently (e.g., more than one every 5-10
>         minutes for current battery-powered devices) unless the
>         information in the RA packet has substantially changed.  If there
>         is a desire to ensure that hosts pick up configuration changes
>         quickly, those networks MAY send frequent Router Advertisements
>         for a limited period of time (e.g., not more than one minute)
>         immediately after a configuration change./
>
> 3. Routers with network interfaces that are known to serve
> battery-powered devices SHOULD NOT send multicast RAs too frequently
> unless the information in the RA packet has substantially changed.
>

Up until here I agree with the bullet point text, but I have a comment
for the below.

> The BCP value for MinRtrAdvInterval can be derived using the formula
> 0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the
> maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861
> Section 6.2.1] suggesting MaxRtrAdvInterval =3D 1800 and MinRtrAdvInterva=
l
> =3D 600 seconds.

This part largely rephrases the text from RFC4861:

      MinRtrAdvInterval
....

                     Default: 0.33 * MaxRtrAdvInterval If
                     MaxRtrAdvInterval >=3D 9 seconds; otherwise, the
                     Default is MaxRtrAdvInterval.

Why repeating it here ?

Also, I find the reasoning using the final effective RA interval to be
easier for the reader to get the spirit of the document, rather than
prescribing the Min/Max values.

Thus the suggested alternative wording above.

>
> 4. If there is a desire to ensure that hosts pick up configuration
> changes quickly, those router interfaces MAY send frequent multicast RA
> for a limited period of time immediately after a configuration change.
>
> A suggested (arbritary) time limit for this behavior is one minute.

Splitting this into a separate bullet point for extra emphasis is
reasonable indeed, thanks!

--a

> /
>
>>> s/Networks that serve battery-powered devices /Routers with network
>>> interfaces that are known to serve battery-powered devices/
>>>
>>
>> Thanks, noted!
>>
>> --a
>>
>>> --
>>> regards,
>>> RayH
>>> 
>>>
>>
>
> --
> regards,
> RayH
> 
>


From nobody Fri Aug 28 07:57: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 67AA71A86FF for ; Fri, 28 Aug 2015 07:57: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 0O2EpydueFtZ for ; Fri, 28 Aug 2015 07:57:47 -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 7D7C51A92F6 for ; Fri, 28 Aug 2015 07:57:47 -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 t7SEvjrq026258 for ; Fri, 28 Aug 2015 16:57:45 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5DCB4200E41 for ; Fri, 28 Aug 2015 17:02:10 +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 5606E200D99 for ; Fri, 28 Aug 2015 17:02:10 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t7SEvhrw017754 for ; Fri, 28 Aug 2015 16:57:45 +0200
To: v6ops@ietf.org
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net> <55DF12E0.6040603@gmail.com>  <55DF32C1.6000504@gmail.com>
From: Alexandru Petrescu 
Message-ID: <55E076E7.5040305@gmail.com>
Date: Fri, 28 Aug 2015 16:57:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55DF32C1.6000504@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 28 Aug 2015 14:57:50 -0000

Le 27/08/2015 17:54, Alejandro Acosta a écrit :
> Hello Andrew, Inline:
>
> El 8/27/2015 a las 11:01 AM, Andrew 👽 Yourtchenko escribió:
>> Hello Alejandro,
>>
>> On 8/27/15, Alejandro Acosta 
>> wrote:
>>> Hello, I fully support this draft, in fact, I believe that all
>>> draft should have a mandatory "Eco-friendly" section.
>>>
>>> My comments:
>>>
>>> In section 3 - Consequences
>>>
>>>
>>> o  Some hosts simply experience bad battery life on these
>>> networks and otherwise operate normally.  This is frustrating for
>>> users of these networks.
>>>
>>>
>>> The sentence: "This is frustrating for users of   these
>>> networks." does not convince me. The impact of a bad battery life
>>> is quite big, to say it's just "frustrating" IMHO is not enough.
>>> I think it should be remove or create a stronger sentence.
>> If Lorenzo agrees, I'd opt for removing the sentence about the
>> frustrated users.
>
> Perfect
>
>>
>>>
>>> In section 4.2:
>>>
>>>
>>> 2.  Networks that serve large numbers (tens or hundreds) of
>>> battery- powered devices SHOULD enable this behaviour.
>>>
>>>
>>> This might be a dummy question but I wonder if this is automatic
>>> or something that will be adjusted by the administrator (or
>>> both). Probably we could be more specific in this section, I
>>> mean, just to be more clear.
>> Yeah, looks like this text needs tweaking - both you and Ray has
>> commented on it, copypasting from my reply to him, so to check
>> with you:
>>
>> How about a small tweak as below:
>>
>> "2) Administrators of networks that serve large numbers (tens or
>> hundreds) of battery- powered devices SHOULD enable this
>> behaviour."
>
> It sounds ok to me. In the future (and not that far away) another
> draft could be written about making routers smarter..,

The link-layers should be smarter, not the Routers.  The link-layers
should have link-layer messages about expressing interest in joining
link-layer multicast groups (have mssages, not just API primitives).

Alex

  I mean, they can recognize the number of
> devices in the network (in your example tens or hundreds) and change
> the behavior automatically to your draft. It looks feasible to me.
>
> Regards,
>
>
>>
>> --a
>>
>>
>>>
>>> Regards,
>>>
>>> Alejandro,
>>>
>>> El 8/27/2015 a las 8:43 AM, Ray Hunter (v6ops) escribió:
>>>>
>>>> fred@cisco.com wrote:
>>>>> This is to initiate a two week working group last call of
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.
>>>>>
>>>>>
>>>>>
Please read it now. If you find nits (spelling errors, minor suggested
>>>>> wording changes, etc), comment to the authors; if you find
>>>>> greater issues, such as disagreeing with a statement or
>>>>> finding additional issues that need to be addressed, please
>>>>> post your comments to the list.
>>>>>
>>>>> We are looking specifically for comments on the importance of
>>>>> the document as well as its content. If you have read the
>>>>> document and believe it to be of operational utility, that is
>>>>> also an important comment to make.
>>>>>
>>>>>
>>>> I have read this draft. I understand the motivation, it is
>>>> clearly written, and I support it.
>>>>
>>>> Minor Suggestions:
>>>>
>>>> I'd reference 4861 in the first sentence of the intro.
>>>> s/Routing information is communicated to IPv6 hosts by Router
>>>> Advertisement messages. /Routing information is communicated to
>>>> IPv6 hosts by Router Advertisement messages [RFC4861]/
>>>>
>>>> Recommendation 2 is redundant IMHO. THere's no way a router
>>>> manufacturer can really know if the devices it is serving are
>>>> battery powered devices or not (perhaps the subject of another
>>>> draft e.g. perhaps extension to 4620 to discover this via NI on
>>>> creating a new ND cache entry?)
>>>>
>>>> For recommendation 3: the timing recommendations should be
>>>> more concrete, provided rough consensus can be achieved. In
>>>> order to maximize the benefit I'd suggest specifying the upper
>>>> end of the suggested ranges.
>>>>
>>>> s/Networks that serve battery-powered devices /Routers with
>>>> network interfaces that are known to serve battery-powered
>>>> devices/
>>>>
>>>>
>>>>
>>>> -- regards, RayH
>>>> 
>>>>
>>>>
>>>>
>>>>
_______________________________________________
>>>> 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 Fri Aug 28 08:01: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 315051B34A4 for ; Fri, 28 Aug 2015 08:01:40 -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 vSW7W2TKtggo for ; Fri, 28 Aug 2015 08:01:35 -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 630A31B3497 for ; Fri, 28 Aug 2015 08:01:35 -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 t7SF1XsA013443; Fri, 28 Aug 2015 17:01:33 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 72E87206622; Fri, 28 Aug 2015 17:05:58 +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 668D6206625; Fri, 28 Aug 2015 17:05:58 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t7SF1WHB020477; Fri, 28 Aug 2015 17:01:33 +0200
To: "George, Wes" , "v6ops@ietf.org" 
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <55A6771E.30805@gmail.com> 
From: Alexandru Petrescu 
Message-ID: <55E077CC.1020208@gmail.com>
Date: Fri, 28 Aug 2015 17:01:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Aug 2015 15:01:40 -0000

Le 26/07/2015 03:21, George, Wes a écrit :
>
>
> On 7/15/15, 11:07 AM, "v6ops on behalf of Alexandru Petrescu"
> 
> wrote:
>
>> One problem I see is when operators deliver a single global /64
>> prefix, and that /64 is understood as a single IPv6 global
>> address.
>>
>> Forming multiple IPv6 addresses out of a single /64 is possible
>> for multiple apps running on that device, so that may not be a
>> problem. There may be some privacy concerns though, in that an
>> attacker can identify there is a single device there (the /64 is
>> unique).
>
> WG] that is not a privacy consideration that is unique to this
> document, and as such I recommend that we stay away from it, as it
> just distracts from the main point by essentially asking for rolling
> /64 assignments or multiple /64s. We need to keep the scope of this
> document fairly tight.
>
>>
>> But 'sharing' these IPv6 addresses with some other devices
>> (64share) has more serious drawbacks, typically in the number of
>> subnets - only one subnet is possible.
>
> WG] I fully expect implementations of the type that this draft
> discusses to get by with bridging if they need to share a /64 such as
> for mobile device tethering. If they truly need multiple subnets,
> there is no way to get around supporting DHCP_PD with some sane
> configuration around sending and accepting hints for larger prefixes,
> because that doesn't work for SLACC either. That probably needs to be
> another document, with those specific use cases documented, because
> "always support multiple subnets" is a more significant request than
> "always support multiple addresses"

Makes sense to me.  This document should either say "always support
multiple addresses and always support multiple prefixes" or may we write
another document for the prefixes requirement part.

Alex

>
>
> Thanks,
>
> Wes
>
>
> 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.
>


From nobody Fri Aug 28 08:10: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 297A41B348D for ; Fri, 28 Aug 2015 08:09:58 -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 jt0q7pUVW-th for ; Fri, 28 Aug 2015 08:09:55 -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 5F06B1B343E for ; Fri, 28 Aug 2015 08:09:55 -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 t7SF9rbr015977 for ; Fri, 28 Aug 2015 17:09:53 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1A25B206573 for ; Fri, 28 Aug 2015 17:14:19 +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 1226320652B for ; Fri, 28 Aug 2015 17:14:19 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t7SF9qaK016671 for ; Fri, 28 Aug 2015 17:09:53 +0200
To: v6ops@ietf.org
References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com>    <20150727091241.GL84167@Space.Net>    <20150728115944.GZ84167@Space.Net>    <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com>  <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> 
From: Alexandru Petrescu 
Message-ID: <55E079C0.1080209@gmail.com>
Date: Fri, 28 Aug 2015 17:09:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Aug 2015 15:09:58 -0000

Le 29/07/2015 04:01, Lorenzo Colitti a écrit :
> On Wed, Jul 29, 2015 at 2:51 AM, Ted Lemon  > wrote:
>
> So you want the device to be able to use DHCPv6-PD on the upstream,
> but support SLAAC on the downstream.   So this really isn’t a general
> mechanism: it’s for the smartphone router use case specifically.
>
>
> Or for laptops that want to run VMs. Or for future protocols that
> need more space, or for applications that want per-application
> IP-addresses. Or anything else.
>
> What this gives you is that on a network that has tracking
> requirements that require the use of DHCPv6, then DHCPv6 can be used
> all the way to "where the buck stops", i.e., all the way to the end
> user of the network. The end user can then use other mechanisms, such
> as SLAAC or bridging, to extend the network.
>
> There are 256 times as many /40s as IPv4 addresses.   That’s a
> _really_ small number unless you see the Internet growth curve
> flattening out, and your draft suggests that you don't.
>
>
> The draft only recommends using DHCPv6 PD on if the network "requires
>  explicit requests for address space". That rules out anything
> running SLAAC, which is supported by the vast majority of IPv6
> deployments today. If you want the draft to recommend that networks
> should not require explicit requests for address space, then it can
> do that.

I dont understand what can the draft do...

The network operators should accept explicit requests for address space,
e.g. a /63 prefix request.

This is not only about host address availability, but also about router
prefix availability.

It is not only about addresses on the upstream interface, but about 
delegated address space.

Alex

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


From nobody Fri Aug 28 08:40: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 F0AB11B2AF5 for ; Fri, 28 Aug 2015 08:40:31 -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 MKUAJCmDuXuF for ; Fri, 28 Aug 2015 08:40:30 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2362F1B2AC2 for ; Fri, 28 Aug 2015 08:40:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4014; q=dns/txt; s=iport; t=1440776430; x=1441986030; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S6r0akvJKrJj6uPcVFAQjZUv2YQDTkOmzjWdu34TM5s=; b=fVESSZvtZuHOGFzLytAxheeMBcQvVWKqEyGqcp1i5WAN3Gsi52ifGH4o 18cnEUI8zN9+vhbznribwgROwVOl0rLubQ7iq5/7NIMIU0PZ+6i2OBrtw +nCqIUDXXM4VMDfIC+xzg728TvVywKRgwJSEqCiBcE0WofqAXw1LA1v0t A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoAgBugOBV/5RdJa1eDoMNVGkGvXsBCYFuCoV7AoE8OBQBAQEBAQEBgQqEIwEBAQQBAQE3NAkCEAIBCA4DBAEBAQoUECEGCx0IAgQBDQUIiBEDEg2/Nw2FHQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi2KCT4ILMQcGgxKBFAEEjG6IUQGFBYYAgzeEMow2eYc8JoIMH4EWPnEBgUeBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,425,1437436800"; d="scan'208";a="183105874"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Aug 2015 15:40:29 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t7SFeTnt010111 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 15:40:29 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 28 Aug 2015 10:40:28 -0500
Received: from xhc-aln-x12.cisco.com (173.36.12.86) by xch-aln-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 28 Aug 2015 10:40:28 -0500
Received: from xmb-rcd-x09.cisco.com ([169.254.9.173]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 10:40:28 -0500
From: "Fred Baker (fred)" 
To: Alberto Leiva , Xing Li 
Thread-Topic: [v6ops] New Version Notification for draft-bao-v6ops-rfc6145bis-01.txt
Thread-Index: AQHQ4B/yTpPUwjpWkkSVS0oEvCxJDZ4hjasB
Date: Fri, 28 Aug 2015 15:40:27 +0000
Message-ID: <8C48B86A895913448548E6D15DA7553B0630FED9@xmb-rcd-x09.cisco.com>
References: <55CA979F.9010403@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: [173.37.102.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] New Version Notification for draft-bao-v6ops-rfc6145bis-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Aug 2015 15:40:32 -0000

=0A=
=0A=
In both cases, I think the logic was to carry as much of the IP datagram an=
d payload as possible with a good probability of delivery to the destinatio=
n of the ICMP message. I the last 1980's (when most of RFC 1812 was actuall=
y written), 576 was a very real number. A number of things converged, the m=
ost important one being, perhaps, CIDR (which meant that a host couldn't ne=
cessarily determine whether the address of a remote destination was or was =
not within its own network) that made people move away from the magic in th=
e number. In IPv6, there have been multiple attempts to pick a magic number=
 that "all" networks can support, winding up in the 1240/1280 range. But th=
e point of this exercise was never, I think, to pick a number. It was to ge=
t the ICMP message along with whatever it could return back to the host tha=
t sent the message it was responding to.=0A=
=0A=
I think I would conclude that if the translator sends as much as it can, it=
 is within sight of the intent.=0A=
________________________________________=0A=
From: v6ops [v6ops-bounces@ietf.org] on behalf of Alberto Leiva [ydahhrk@gm=
ail.com]=0A=
Sent: Wednesday, August 26, 2015 9:54 AM=0A=
To: Xing Li=0A=
Cc: v6ops@ietf.org=0A=
Subject: Re: [v6ops] New Version Notification for draft-bao-v6ops-rfc6145bi=
s-01.txt=0A=
=0A=
Say=0A=
=0A=
Something about 6145 has been bothering me for a while. Regarding ICMP=0A=
error length:=0A=
=0A=
RFC 1812 section 4.3.2.3 says "the ICMP [error] datagram SHOULD=0A=
contain as much of the original datagram as possible without the=0A=
length of the ICMP datagram exceeding 576 bytes."=0A=
=0A=
RFC 4443 says "[The ICMP payload should measure] as much of invoking=0A=
packet as possible without the ICMPv6 packet exceeding the minimum=0A=
IPv6 MTU."=0A=
=0A=
I don't know how current or realistic these constraints are. I=0A=
apologize if I've been living under a rock.=0A=
=0A=
Regardless:=0A=
=0A=
Since the minimum IPv6 MTU is not the same as the IPv4 MTU, a=0A=
translator can end up with an "illegal" ICMP error. Following the=0A=
numbers above, after removing both IPv6 headers and attaching both=0A=
IPv4 headers, a resulting IPv4 packet can be an ICMPv4 error and span=0A=
1240 bytes.=0A=
=0A=
For the sake of correctness, shouldn't the translator truncate it?=0A=
(And update the outer ICMP checksum accordingly)=0A=
=0A=
On Tue, Aug 11, 2015 at 7:47 PM, Xing Li  wrote:=0A=
> Hi, All,=0A=
>=0A=
> According to the conclusion made in v6ops meeting of IETF93, (removing=0A=
> the EAM part and refer to EAM draft), we have updated the=0A=
> draft-bao-v6ops-rfc6145bis, please review. Thanks.=0A=
>=0A=
> Regards,=0A=
>=0A=
> xing=0A=
>=0A=
>> Name:         draft-bao-v6ops-rfc6145bis=0A=
>> Revision:     01=0A=
>> Title:                IP/ICMP Translation Algorithm (rfc6145bis)=0A=
>> Document date:        2015-08-07=0A=
>> Group:                Individual Submission=0A=
>> Pages:                38=0A=
>> URL:            https://www.ietf.org/internet-drafts/draft-bao-v6ops-rfc=
6145bis-01.txt=0A=
>> Status:         https://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145=
bis/=0A=
>> Htmlized:       https://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis-0=
1=0A=
>> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-bao-v6ops-rfc6=
145bis-01=0A=
>>=0A=
>> Abstract:=0A=
>>    This document describes the Stateless IP/ICMP Translation Algorithm=
=0A=
>>    (SIIT), which translates between IPv4 and IPv6 packet headers=0A=
>>    (including ICMP headers).  This document updates RFC 6145.=0A=
>>=0A=
>>=0A=
>>=0A=
>=0A=
>=0A=
> _______________________________________________=0A=
> v6ops mailing list=0A=
> v6ops@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/v6ops=0A=
=0A=
_______________________________________________=0A=
v6ops mailing list=0A=
v6ops@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/v6ops=


From nobody Fri Aug 28 11:44: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 80CF71ACE25 for ; Fri, 28 Aug 2015 11:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.449
X-Spam-Level: 
X-Spam-Status: No, score=-0.449 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzN_rqtQgRaB for ; Fri, 28 Aug 2015 11:44:00 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 0C9F21ACDD8 for ; Fri, 28 Aug 2015 11:44:00 -0700 (PDT)
Received: by lbcbn3 with SMTP id bn3so34987064lbc.2 for ; Fri, 28 Aug 2015 11:43:58 -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=FcJF3x48bGWuHToh3ZnBgSG3Xh+VbwQE+BES5jchIQ0=; b=MH7wQ888uGTqX5KbC0ZaSbvVUCOnd5PKnMBbAqP80nHLZh30dVAxgNOTI6ef7bMSLL lt81dHHWeGsUesjiN2shBZ8cMDsBcgXP2iSMd5z0Nl1J31wGGa7i2tfWoImUVkzwqyQv 67vcaRURV39X/HKjGiLg2DsDSnpHHGUkueV0j1ABAHQZsq7dd6B7ppyHlpCzPI9RbqIF hAY1lGFUJ4fZUUU1SpyELI1OSTkDaeiRi5sOiLWF5hiNJqwMnzqdsN7p/wDVk6vAI5gG nEXMMK6u23BiWbs8qd6B6qlDroeCQejwX5l5ZtldGbhwSLS/+mJz4EVGudmh7xfne6rw aOrQ==
MIME-Version: 1.0
X-Received: by 10.112.142.105 with SMTP id rv9mr5405662lbb.11.1440787438339; Fri, 28 Aug 2015 11:43:58 -0700 (PDT)
Received: by 10.25.41.207 with HTTP; Fri, 28 Aug 2015 11:43:58 -0700 (PDT)
In-Reply-To: 
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>  <55E01757.7080208@globis.net> 
Date: Fri, 28 Aug 2015 19:43:58 +0100
Message-ID: 
From: Nabil Benamar 
To: =?UTF-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= 
Content-Type: multipart/alternative; boundary=001a11c3775c758e7a051e63779d
Archived-At: 
Cc: "Ray Hunter \(v6ops\)" , v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 28 Aug 2015 18:44:03 -0000

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

I have read the draft and I'm supporting it. I have just one question about
the chosen values of RA. " Networks that serve battery-powered devices SHOU=
LD
NOT send

       multicast RAs too frequently (e.g., more than one every 5-10
       minutes for current battery-powered devices)
=E2=80=8B..."=E2=80=8B

=E2=80=8BHow these values have been chosen ? Why 5-10 minutes exactly ?=E2=
=80=8B


Best regards
Nabil    =D9=86=D8=A8=D9=8A=D9=84



On Fri, Aug 28, 2015 at 1:23 PM, Andrew =F0=9F=91=BD Yourtchenko 
wrote:

> inline.
>
> On 8/28/15, Ray Hunter (v6ops)  wrote:
> > inline.
> >
> >> Andrew =F0=9F=91=BD Yourtchenko 
> >> 27 Aug 2015 17:20
> >> On 8/27/15, Ray Hunter (v6ops)  wrote:
> >>> fred@cisco.com wrote:
> >>>> This is to initiate a two week working group last call of
> >>>>
> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumptio=
n
> .
> >>>> Please read it now. If you find nits (spelling errors, minor suggest=
ed
> >>>> wording changes, etc), comment to the authors; if you find greater
> >>>> issues, such as disagreeing with a statement or finding additional
> >>>> issues that need to be addressed, please post your comments to the
> >>>> list.
> >>>>
> >>>> We are looking specifically for comments on the importance of the
> >>>> document as well as its content. If you have read the document and
> >>>> believe it to be of operational utility, that is also an important
> >>>> comment to make.
> >>>>
> >>>>
> >>> I have read this draft. I understand the motivation, it is clearly
> >>> written, and I support it.
> >>>
> >>> Minor Suggestions:
> >>>
> >>> I'd reference 4861 in the first sentence of the intro.
> >>> s/Routing information is communicated to IPv6 hosts by Router
> >>> Advertisement messages. /Routing information is communicated to IPv6
> >>> hosts by Router Advertisement messages [RFC4861]/
> >>
> >> Thanks, noted!
> >>
> >>> Recommendation 2 is redundant IMHO. THere's no way a router
> manufacturer
> >>> can really know if the devices it is serving are battery powered
> devices
> >>> or not (perhaps the subject of another draft e.g. perhaps extension t=
o
> >>> 4620 to discover this via NI on creating a new ND cache entry?)
> >>
> >> It's not entirely redundant, the intent here is that this mechanism is
> >> enabled on the network, which has two parts:
> >>
> >> 1) the equipment on the network has an option to enable it. (e.g. the
> >> administrator needs to ensure that their equipment supports it).
> >>
> >> 2) the administrator has enabled it. (e.g. today's Cisco
> >> implementation simply has the command "ipv6 nd ra solicited unicast"
> >> which needs to be configured).
> >>
> >> How about a small tweak as below:
> >>
> >> "2) Administrators of networks that serve large numbers (tens or
> >> hundreds) of battery-
> >>         powered devices SHOULD enable this behaviour."
> > Works for me.
> >>> For recommendation 3: the timing recommendations should be more
> >>> concrete, provided rough consensus can be achieved. In order to
> maximize
> >>> the benefit I'd suggest specifying the upper end of the suggested
> >>> ranges.
> >>
> >> I tend to configure such networks with the RA interval of 1800
> >> seconds, with router lifetime of 9000 seconds (and when
> >> draft-krishnan-6man-maxra gets through, will be happy to bump those
> >> values up to 21K and 64K respectively). Lorenzo's take is that "every
> >> few minutes is already much better than every 3 seconds".
> >>
> >> So, based on my today's knowledge the upper limit is whatever is
> >> enforced by the protocol + the usual "three-RA-per-lifetime" rule of
> >> thumb - which looks to be in line with the text in the draft that does
> >> not specify any upper bound.
> >>
> >> Does the text suggest differently ?
> > No, but it specifies an absolute value without explaining how that valu=
e
> > is derived.
>
> no, it specifies a *lower limit* - it tells the networks in question
> should send the RAs with the interval *bigger* than X - so it's not
> subject to change if the protocol limit increases. OTOH the X is kinda
> pulled out of the hat, I agree.
>
> So, how about the following change instead:
>
> s/Networks that serve battery-powered devices SHOULD NOT send
>         multicast RAs too frequently (e.g., more than one every 5-10
>         minutes for current battery-powered devices) unless the
>         information in the RA packet has substantially changed.  /
>
> Networks that serve battery-powered devices should try to maximize the
> interval between the  multicast RAs within the limits allowed by
> protocol - unless the information in the RA packet has changed. On the
> other hand, the maximum value should be bound to allow a sufficient
> number of RAs to be sent within the router/prefix lifetimes - to
> account for the potential packet loss in the wireless network. This
> packet loss will depend on the quality of the radio spectrum/coverage
> and may need to be decided on a per-network basis. In the best-case
> scenario one would ensure that at least 3 (a chosen arbitrary value)
> RAs are transmitted within the smallest of the lifetimes for the
> parameters contained within the RA.  /
>
> Or something along these lines.
>
> >
> > So if the protocols ever change, the BCP value may no longer appropriat=
e
> > e.g. if draft-krishnan-6man-maxra becomes a standard.
> >
> > Why not specify in terms of the upper limit of the protocol, and
> > formula, rather than a specific time?
> >
> > e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writing
> > is 1800 seconds (derived from RFC4861 Section 6.2.1)
> >
> > Suggested text:
> >
> > s/Networks that serve battery-powered devices SHOULD NOT send
> >         multicast RAs too frequently (e.g., more than one every 5-10
> >         minutes for current battery-powered devices) unless the
> >         information in the RA packet has substantially changed.  If the=
re
> >         is a desire to ensure that hosts pick up configuration changes
> >         quickly, those networks MAY send frequent Router Advertisements
> >         for a limited period of time (e.g., not more than one minute)
> >         immediately after a configuration change./
> >
> > 3. Routers with network interfaces that are known to serve
> > battery-powered devices SHOULD NOT send multicast RAs too frequently
> > unless the information in the RA packet has substantially changed.
> >
>
> Up until here I agree with the bullet point text, but I have a comment
> for the below.
>
> > The BCP value for MinRtrAdvInterval can be derived using the formula
> > 0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the
> > maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861
> > Section 6.2.1] suggesting MaxRtrAdvInterval =3D 1800 and MinRtrAdvInter=
val
> > =3D 600 seconds.
>
> This part largely rephrases the text from RFC4861:
>
>       MinRtrAdvInterval
> ....
>
>                      Default: 0.33 * MaxRtrAdvInterval If
>                      MaxRtrAdvInterval >=3D 9 seconds; otherwise, the
>                      Default is MaxRtrAdvInterval.
>
> Why repeating it here ?
>
> Also, I find the reasoning using the final effective RA interval to be
> easier for the reader to get the spirit of the document, rather than
> prescribing the Min/Max values.
>
> Thus the suggested alternative wording above.
>
> >
> > 4. If there is a desire to ensure that hosts pick up configuration
> > changes quickly, those router interfaces MAY send frequent multicast RA
> > for a limited period of time immediately after a configuration change.
> >
> > A suggested (arbritary) time limit for this behavior is one minute.
>
> Splitting this into a separate bullet point for extra emphasis is
> reasonable indeed, thanks!
>
> --a
>
> > /
> >
> >>> s/Networks that serve battery-powered devices /Routers with network
> >>> interfaces that are known to serve battery-powered devices/
> >>>
> >>
> >> Thanks, noted!
> >>
> >> --a
> >>
> >>> --
> >>> regards,
> >>> RayH
> >>> <
> https://www.postbox-inc.com/?utm_source=3Demail&utm_medium=3Dsiglink&utm_=
campaign=3Dreach
> >
> >>>
> >>
> >
> > --
> > regards,
> > RayH
> > <
> https://www.postbox-inc.com/?utm_source=3Demail&utm_medium=3Dsiglink&utm_=
campaign=3Dreach
> >
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


I have read the draft and =
I'm supporting it. I have just one question about the chosen values of =
RA. "=C2=A0Networks that serve battery-powered devices=
=C2=A0SHOULD NOT send
       multicast RAs too frequently (e.g., more than one every =
5-10
       minutes for current battery-powered devices)
=E2=80=8B..."=E2=80=8B
 
=E2=80=
=8BHow these values have been chosen ? Why 5-10 minutes exactly ?=E2=80=8B<=
/div>

Best regards
Nabil =C2=A0 =C2=A0=D9=86=
=D8=A8=D9=8A=D9=84




On Fri, Aug 28, 2015 at 1:23 PM, Andrew =F0=
=9F=91=BD  Yourtchenko <ayourtch@gmail.com> wrote:
inline.



On 8/28/15, Ray Hunter (v6ops) <v6op=
s@globis.net> wrote:

> inline.

>

>> Andrew =F0=9F=91=BD Yourtchenko <mailto:ayourtch@gmail.com>


>> 27 Aug 2015 17:20

>> On 8/27/15, Ray Hunter (v6ops)<v6ops@globis.net>=C2=A0 wrote:

>>> fred@cisco.com wrote:
>>>> This is to initiate a two week working group last call of<=
br>
>>>> http://to=
ols.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.

>>>> Please read it now. If you find nits (spelling errors, min=
or suggested

>>>> wording changes, etc), comment to the authors; if you find=
 greater

>>>> issues, such as disagreeing with a statement or finding ad=
ditional

>>>> issues that need to be addressed, please post your comment=
s 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 docu=
ment and

>>>> believe it to be of operational utility, that is also an i=
mportant

>>>> comment to make.

>>>>

>>>>

>>> I have read this draft. I understand the motivation, it is cle=
arly

>>> written, and I support it.

>>>

>>> Minor Suggestions:

>>>

>>> I'd reference 4861 in the first sentence of the intro.

>>> s/Routing information is communicated to IPv6 hosts by Router<=
br>
>>> Advertisement messages. /Routing information is communicated t=
o IPv6

>>> hosts by Router Advertisement messages [RFC4861]/

>>

>> Thanks, noted!

>>

>>> Recommendation 2 is redundant IMHO. THere's no way a route=
r manufacturer

>>> can really know if the devices it is serving are battery power=
ed devices

>>> or not (perhaps the subject of another draft e.g. perhaps exte=
nsion to

>>> 4620 to discover this via NI on creating a new ND cache entry?=
)

>>

>> It's not entirely redundant, the intent here is that this mech=
anism is

>> enabled on the network, which has two parts:

>>

>> 1) the equipment on the network has an option to enable it. (e.g. =
the

>> administrator needs to ensure that their equipment supports it).
>>

>> 2) the administrator has enabled it. (e.g. today's Cisco

>> implementation simply has the command "ipv6 nd ra solicited u=
nicast"

>> which needs to be configured).

>>

>> How about a small tweak as below:

>>

>> "2) Administrators of networks that serve large numbers (tens=
 or

>> hundreds) of battery-

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0powered devices SHOULD enable thi=
s behaviour."

> Works for me.

>>> For recommendation 3: the timing recommendations should be mor=
e

>>> concrete, provided rough consensus can be achieved. In order t=
o maximize

>>> the benefit I'd suggest specifying the upper end of the su=
ggested

>>> ranges.

>>

>> I tend to configure such networks with the RA interval of 1800

>> seconds, with router lifetime of 9000 seconds (and when

>> draft-krishnan-6man-maxra gets through, will be happy to bump thos=
e

>> values up to 21K and 64K respectively). Lorenzo's take is that=
 "every

>> few minutes is already much better than every 3 seconds".

>>

>> So, based on my today's knowledge the upper limit is whatever =
is

>> enforced by the protocol + the usual "three-RA-per-lifetime&q=
uot; rule of

>> thumb - which looks to be in line with the text in the draft that =
does

>> not specify any upper bound.

>>

>> Does the text suggest differently ?

> No, but it specifies an absolute value without explaining how that val=
ue

> is derived.




no, it specifies a *lower limit* - it tells the networks in que=
stion

should send the RAs with the interval *bigger* than X - so it's not

subject to change if the protocol limit increases. OTOH the X is kinda

pulled out of the hat, I agree.



So, how about the following change instead:



s/Networks that serve battery-powered devices SHOULD NOT send

=C2=A0 =C2=A0 =C2=A0 =C2=A0 multicast RAs too frequently (e.g., more than o=
ne every 5-10

=C2=A0 =C2=A0 =C2=A0 =C2=A0 minutes for current battery-powered devices) un=
less the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 information in the RA packet has substan=
tially changed.=C2=A0 /



Networks that serve battery-powered devices should try to maximize the

interval between the=C2=A0 multicast RAs within the limits allowed by

protocol - unless the information in the RA packet has changed. On the

other hand, the maximum value should be bound to allow a sufficient

number of RAs to be sent within the router/prefix lifetimes - to

account for the potential packet loss in the wireless network. This

packet loss will depend on the quality of the radio spectrum/coverage

and may need to be decided on a per-network basis. In the best-case

scenario one would ensure that at least 3 (a chosen arbitrary value)

RAs are transmitted within the smallest of the lifetimes for the

parameters contained within the RA.=C2=A0 /



Or something along these lines.



>

> So if the protocols ever change, the BCP value may no longer appropria=
te

> e.g. if draft-krishnan-6man-maxra becomes a standard.

>

> Why not specify in terms of the upper limit of the protocol, and

> formula, rather than a specific time?

>

> e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writin=
g

> is 1800 seconds (derived from RFC4861 Section 6.2.1)

>

> Suggested text:

>

> s/Networks that serve battery-powered devices SHOULD NOT send

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multicast RAs too frequently (e.g., m=
ore than one every 5-10

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minutes for current battery-powered d=
evices) unless the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information in the RA packet has subs=
tantially changed.=C2=A0 If there

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is a desire to ensure that hosts pick=
 up configuration changes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0quickly, those networks MAY send freq=
uent Router Advertisements

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for a limited period of time (e.g., n=
ot more than one minute)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0immediately after a configuration cha=
nge./

>

> 3. Routers with network interfaces that are known to serve

> battery-powered devices SHOULD NOT send multicast RAs too frequently
> unless the information in the RA packet has substantially changed.

>



Up until here I agree with the bullet point text, but I have a comme=
nt

for the below.



> The BCP value for MinRtrAdvInterval can be derived using the formula
> 0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the

> maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861<=
br>
> Section 6.2.1] suggesting MaxRtrAdvInterval =3D 1800 and MinRtrAdvInte=
rval

> =3D 600 seconds.



This part largely rephrases the text from RFC4861:



=C2=A0 =C2=A0 =C2=A0 MinRtrAdvInterval

....



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Default: 0.33 * MaxRtrAdvInterval If

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0MaxRtrAdvInterval >=3D 9 seconds; otherwise, the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Default is MaxRtrAdvInterval.



Why repeating it here ?



Also, I find the reasoning using the final effective RA interval to be

easier for the reader to get the spirit of the document, rather than

prescribing the Min/Max values.



Thus the suggested alternative wording above.



>

> 4. If there is a desire to ensure that hosts pick up configuration

> changes quickly, those router interfaces MAY send frequent multicast R=
A

> for a limited period of time immediately after a configuration change.=


>

> A suggested (arbritary) time limit for this behavior is one minute.


Splitting this into a separate bullet point for extra emphasis is
reasonable indeed, thanks!



--a



> /

>

>>> s/Networks that serve battery-powered devices /Routers with ne=
twork

>>> interfaces that are known to serve battery-powered devices/
>>>

>>

>> Thanks, noted!

>>

>> --a

>>

>>> --

>>> regards,

>>> RayH

>>> <https://www.postbox-inc.com/?utm_source=3Demail&utm_mediu=
m=3Dsiglink&utm_campaign=3Dreach>

>>>

>>

>

> --

> regards,

> RayH


> <https://www.postbox-in=
c.com/?utm_source=3Demail&utm_medium=3Dsiglink&utm_campaign=3Dreach=
>

>



_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





--001a11c3775c758e7a051e63779d--


From nobody Fri Aug 28 16:27: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 5182C1A8928 for ; Fri, 28 Aug 2015 16:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=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 sMf31lRk56Jl for ; Fri, 28 Aug 2015 16:27:41 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c: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 A6A131A86DD for ; Fri, 28 Aug 2015 16:27:40 -0700 (PDT)
Received: by wicfv10 with SMTP id fv10so24153565wic.0 for ; Fri, 28 Aug 2015 16:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=21AsikGLiEcoj7mty7Njx8MfRlUmeD3cD4QJutHz2tA=; b=x2a+LZjHnP8u7ZZ2/D636WZc0K1O4o6h3C5QbGuiU6nahJ0RyR/5LcjdvqM0PQER65 iMcMPrXrYKV8WgkSgThojWHmkXGi3GUopagVratDs6dIteFinMsSE3A6VtypGxIUw5GG 3Mt26BcrllK7EUbAAEJ2T8KbiXLhpLZm1agixTZNh6cs6x/HUfPUDj1MuLXtACcESCdD gdnN+RRxLrTD7DNK17BWAl2PAcQ1KOntDp+FhLPQQ8l8F+BZ0Cxm2+5lb6pCsnD9M8Qw jzsVSrVvMQ6mOwS7RF3y6xE6r5S1niHXB2COAJwt8Ufn8yNqZmLePMc98DmLK2/qb7L3 lI5A==
X-Received: by 10.180.23.162 with SMTP id n2mr6767537wif.8.1440804459355; Fri, 28 Aug 2015 16:27:39 -0700 (PDT)
Received: from ?IPv6:2001:470:1f13:62e:5108:9c24:b82c:7060? ([2001:470:1f13:62e:5108:9c24:b82c:7060]) by smtp.gmail.com with ESMTPSA id fa8sm5915428wib.14.2015.08.28.16.27.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Aug 2015 16:27:38 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-A9CB0B8D-DA07-49AA-993F-CB67563501BC
Mime-Version: 1.0 (1.0)
From: =?utf-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= 
X-Mailer: iPhone Mail (12H321)
In-Reply-To: 
Date: Sat, 29 Aug 2015 01:27:36 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <5BF6A0DA-AF63-47EB-AEDE-A5206C541197@gmail.com>
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>  <55E01757.7080208@globis.net>  
To: Nabil Benamar 
Archived-At: 
Cc: "Ray Hunter \(v6ops\)" , v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 28 Aug 2015 23:27:44 -0000

--Apple-Mail-A9CB0B8D-DA07-49AA-993F-CB67563501BC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Nabil,

Inline...

> On 28 Aug 2015, at 20:43, Nabil Benamar  wrote:
>=20
> I have read the draft and I'm supporting it. I have just one question abou=
t the chosen values of RA. " Networks that serve battery-powered devices SHO=
ULD NOT send
>        multicast RAs too frequently (e.g., more than one every 5-10
>        minutes for current battery-powered devices)=E2=80=8B..."=E2=80=8B=20=

> =E2=80=8BHow these values have been chosen ? Why 5-10 minutes exactly ?=E2=
=80=8B
>=20

Arbitrarily - on a basis that it is much better than every 3 seconds :-) I'v=
e sent the proposed text without arbitrary values (suggesting to maximize he=
 interval within protocol limits taking into account potential packet loss).=


my message to Ray which you sent this reply to has a new proposed replacemen=
t text - could you take a look and tell what you think about it ?

--a

> Best regards
> Nabil    =D9=86=D8=A8=D9=8A=D9=84
>=20
>=20
>=20
>> On Fri, Aug 28, 2015 at 1:23 PM, Andrew =F0=9F=91=BD Yourtchenko  wrote:
>> inline.
>>=20
>> On 8/28/15, Ray Hunter (v6ops)  wrote:
>> > inline.
>> >
>> >> Andrew =F0=9F=91=BD Yourtchenko 
>> >> 27 Aug 2015 17:20
>> >> On 8/27/15, Ray Hunter (v6ops)  wrote:
>> >>> fred@cisco.com wrote:
>> >>>> This is to initiate a two week working group last call of
>> >>>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consu=
mption.
>> >>>> Please read it now. If you find nits (spelling errors, minor suggest=
ed
>> >>>> wording changes, etc), comment to the authors; if you find greater
>> >>>> issues, such as disagreeing with a statement or finding additional
>> >>>> issues that need to be addressed, please post your comments to the
>> >>>> list.
>> >>>>
>> >>>> We are looking specifically for comments on the importance of the
>> >>>> document as well as its content. If you have read the document and
>> >>>> believe it to be of operational utility, that is also an important
>> >>>> comment to make.
>> >>>>
>> >>>>
>> >>> I have read this draft. I understand the motivation, it is clearly
>> >>> written, and I support it.
>> >>>
>> >>> Minor Suggestions:
>> >>>
>> >>> I'd reference 4861 in the first sentence of the intro.
>> >>> s/Routing information is communicated to IPv6 hosts by Router
>> >>> Advertisement messages. /Routing information is communicated to IPv6
>> >>> hosts by Router Advertisement messages [RFC4861]/
>> >>
>> >> Thanks, noted!
>> >>
>> >>> Recommendation 2 is redundant IMHO. THere's no way a router manufactu=
rer
>> >>> can really know if the devices it is serving are battery powered devi=
ces
>> >>> or not (perhaps the subject of another draft e.g. perhaps extension t=
o
>> >>> 4620 to discover this via NI on creating a new ND cache entry?)
>> >>
>> >> It's not entirely redundant, the intent here is that this mechanism is=

>> >> enabled on the network, which has two parts:
>> >>
>> >> 1) the equipment on the network has an option to enable it. (e.g. the
>> >> administrator needs to ensure that their equipment supports it).
>> >>
>> >> 2) the administrator has enabled it. (e.g. today's Cisco
>> >> implementation simply has the command "ipv6 nd ra solicited unicast"
>> >> which needs to be configured).
>> >>
>> >> How about a small tweak as below:
>> >>
>> >> "2) Administrators of networks that serve large numbers (tens or
>> >> hundreds) of battery-
>> >>         powered devices SHOULD enable this behaviour."
>> > Works for me.
>> >>> For recommendation 3: the timing recommendations should be more
>> >>> concrete, provided rough consensus can be achieved. In order to maxim=
ize
>> >>> the benefit I'd suggest specifying the upper end of the suggested
>> >>> ranges.
>> >>
>> >> I tend to configure such networks with the RA interval of 1800
>> >> seconds, with router lifetime of 9000 seconds (and when
>> >> draft-krishnan-6man-maxra gets through, will be happy to bump those
>> >> values up to 21K and 64K respectively). Lorenzo's take is that "every
>> >> few minutes is already much better than every 3 seconds".
>> >>
>> >> So, based on my today's knowledge the upper limit is whatever is
>> >> enforced by the protocol + the usual "three-RA-per-lifetime" rule of
>> >> thumb - which looks to be in line with the text in the draft that does=

>> >> not specify any upper bound.
>> >>
>> >> Does the text suggest differently ?
>> > No, but it specifies an absolute value without explaining how that valu=
e
>> > is derived.
>>=20
>> no, it specifies a *lower limit* - it tells the networks in question
>> should send the RAs with the interval *bigger* than X - so it's not
>> subject to change if the protocol limit increases. OTOH the X is kinda
>> pulled out of the hat, I agree.
>>=20
>> So, how about the following change instead:
>>=20
>> s/Networks that serve battery-powered devices SHOULD NOT send
>>         multicast RAs too frequently (e.g., more than one every 5-10
>>         minutes for current battery-powered devices) unless the
>>         information in the RA packet has substantially changed.  /
>>=20
>> Networks that serve battery-powered devices should try to maximize the
>> interval between the  multicast RAs within the limits allowed by
>> protocol - unless the information in the RA packet has changed. On the
>> other hand, the maximum value should be bound to allow a sufficient
>> number of RAs to be sent within the router/prefix lifetimes - to
>> account for the potential packet loss in the wireless network. This
>> packet loss will depend on the quality of the radio spectrum/coverage
>> and may need to be decided on a per-network basis. In the best-case
>> scenario one would ensure that at least 3 (a chosen arbitrary value)
>> RAs are transmitted within the smallest of the lifetimes for the
>> parameters contained within the RA.  /
>>=20
>> Or something along these lines.
>>=20
>> >
>> > So if the protocols ever change, the BCP value may no longer appropriat=
e
>> > e.g. if draft-krishnan-6man-maxra becomes a standard.
>> >
>> > Why not specify in terms of the upper limit of the protocol, and
>> > formula, rather than a specific time?
>> >
>> > e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writing=

>> > is 1800 seconds (derived from RFC4861 Section 6.2.1)
>> >
>> > Suggested text:
>> >
>> > s/Networks that serve battery-powered devices SHOULD NOT send
>> >         multicast RAs too frequently (e.g., more than one every 5-10
>> >         minutes for current battery-powered devices) unless the
>> >         information in the RA packet has substantially changed.  If the=
re
>> >         is a desire to ensure that hosts pick up configuration changes
>> >         quickly, those networks MAY send frequent Router Advertisements=

>> >         for a limited period of time (e.g., not more than one minute)
>> >         immediately after a configuration change./
>> >
>> > 3. Routers with network interfaces that are known to serve
>> > battery-powered devices SHOULD NOT send multicast RAs too frequently
>> > unless the information in the RA packet has substantially changed.
>> >
>>=20
>> Up until here I agree with the bullet point text, but I have a comment
>> for the below.
>>=20
>> > The BCP value for MinRtrAdvInterval can be derived using the formula
>> > 0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the
>> > maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861
>> > Section 6.2.1] suggesting MaxRtrAdvInterval =3D 1800 and MinRtrAdvInter=
val
>> > =3D 600 seconds.
>>=20
>> This part largely rephrases the text from RFC4861:
>>=20
>>       MinRtrAdvInterval
>> ....
>>=20
>>                      Default: 0.33 * MaxRtrAdvInterval If
>>                      MaxRtrAdvInterval >=3D 9 seconds; otherwise, the
>>                      Default is MaxRtrAdvInterval.
>>=20
>> Why repeating it here ?
>>=20
>> Also, I find the reasoning using the final effective RA interval to be
>> easier for the reader to get the spirit of the document, rather than
>> prescribing the Min/Max values.
>>=20
>> Thus the suggested alternative wording above.
>>=20
>> >
>> > 4. If there is a desire to ensure that hosts pick up configuration
>> > changes quickly, those router interfaces MAY send frequent multicast RA=

>> > for a limited period of time immediately after a configuration change.
>> >
>> > A suggested (arbritary) time limit for this behavior is one minute.
>>=20
>> Splitting this into a separate bullet point for extra emphasis is
>> reasonable indeed, thanks!
>>=20
>> --a
>>=20
>> > /
>> >
>> >>> s/Networks that serve battery-powered devices /Routers with network
>> >>> interfaces that are known to serve battery-powered devices/
>> >>>
>> >>
>> >> Thanks, noted!
>> >>
>> >> --a
>> >>
>> >>> --
>> >>> regards,
>> >>> RayH
>> >>> 
>> >>>
>> >>
>> >
>> > --
>> > regards,
>> > RayH
>> > 
>> >
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>=20

--Apple-Mail-A9CB0B8D-DA07-49AA-993F-CB67563501BC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Nabil,

Inl=
ine...

On 28 Aug 2015, at 20:43, Nabil Benamar <benamar73@gmail.com> wrote:

=

I have read the draft and I'm supporting it. I have just one question abo=
ut the chosen values of RA. " Networks that serve batter=
y-powered devices SHOULD NOT send
       multicast RAs too frequently (e.g., more th=
an one every 5-10
       minutes for current battery-powered devices)
=E2=80=8B..."=E2=80=8B
 
=E2=80=8BHow these va=
lues have been chosen ? Why 5-10 minutes exactly ?=E2=80=8B

<=
/div>

<=
div>
Arbitrarily - on a basis that it is much better than ever=
y 3 seconds :-) I've sent the proposed text without arbitrary values (sugges=
ting to maximize he interval within protocol limits taking into account pote=
ntial packet loss).

my message to Ray which you sen=
t this reply to has a new proposed replacement text - could you take a look a=
nd tell what you think about it ?

--a

B=
est regards
Nabil    =D9=86=D8=A8=D9=8A=D9=84=



=


On Fri, Aug 28, 2015 at 1:23 PM, Andrew =F0=9F=
=91=BD  Yourtchenko <ayourtch@gmail.com> wrote:
inline.



On 8/28/15, Ray Hunter (v6ops) <v6ops=
@globis.net> wrote:

> inline.

>

>> Andrew =F0=9F=91=BD Yourtchenko <mailto:ayourtch@gmail.com>


>> 27 Aug 2015 17:20

>> On 8/27/15, Ray Hunter (v6ops)<v6ops@globis.net>  wrote:

>>> fred@cisco.com wrote:
=

>>>> This is to initiate a two week working group last call of
>>>> http://tool=
s.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.

>>>> Please read it now. If you find nits (spelling errors, mino=
r suggested

>>>> wording changes, etc), comment to the authors; if you find g=
reater

>>>> issues, such as disagreeing with a statement or finding add=
itional

>>>> issues that need to be addressed, please post your comments=
 to the

>>>> list.

>>>>

>>>> We are looking specifically for comments on the importance o=
f the

>>>> document as well as its content. If you have read the docum=
ent and

>>>> believe it to be of operational utility, that is also an im=
portant

>>>> comment to make.

>>>>

>>>>

>>> I have read this draft. I understand the motivation, it is clea=
rly

>>> written, and I support it.

>>>

>>> Minor Suggestions:

>>>

>>> I'd reference 4861 in the first sentence of the intro.

>>> s/Routing information is communicated to IPv6 hosts by Router
>>> Advertisement messages. /Routing information is communicated to=
 IPv6

>>> hosts by Router Advertisement messages [RFC4861]/

>>

>> Thanks, noted!

>>

>>> Recommendation 2 is redundant IMHO. THere's no way a router man=
ufacturer

>>> can really know if the devices it is serving are battery powere=
d devices

>>> or not (perhaps the subject of another draft e.g. perhaps exten=
sion to

>>> 4620 to discover this via NI on creating a new ND cache entry?)=


>>

>> It's not entirely redundant, the intent here is that this mechanism=
 is

>> enabled on the network, which has two parts:

>>

>> 1) the equipment on the network has an option to enable it. (e.g. t=
he

>> administrator needs to ensure that their equipment supports it).
>>

>> 2) the administrator has enabled it. (e.g. today's Cisco

>> implementation simply has the command "ipv6 nd ra solicited unicast=
"

>> which needs to be configured).

>>

>> How about a small tweak as below:

>>

>> "2) Administrators of networks that serve large numbers (tens or
>> hundreds) of battery-

>>         powered devices SHOULD enable this=
 behaviour."

> Works for me.

>>> For recommendation 3: the timing recommendations should be more=


>>> concrete, provided rough consensus can be achieved. In order to=
 maximize

>>> the benefit I'd suggest specifying the upper end of the suggest=
ed

>>> ranges.

>>

>> I tend to configure such networks with the RA interval of 1800

>> seconds, with router lifetime of 9000 seconds (and when

>> draft-krishnan-6man-maxra gets through, will be happy to bump those=


>> values up to 21K and 64K respectively). Lorenzo's take is that "eve=
ry

>> few minutes is already much better than every 3 seconds".

>>

>> So, based on my today's knowledge the upper limit is whatever is
>> enforced by the protocol + the usual "three-RA-per-lifetime" rule o=
f

>> thumb - which looks to be in line with the text in the draft that d=
oes

>> not specify any upper bound.

>>

>> Does the text suggest differently ?

> No, but it specifies an absolute value without explaining how that valu=
e

> is derived.




no, it specifies a *lower limit* - it tells the networks in ques=
tion

should send the RAs with the interval *bigger* than X - so it's not

subject to change if the protocol limit increases. OTOH the X is kinda

pulled out of the hat, I agree.



So, how about the following change instead:



s/Networks that serve battery-powered devices SHOULD NOT send

        multicast RAs too frequently (e.g., more than on=
e every 5-10

        minutes for current battery-powered devices) unl=
ess the

        information in the RA packet has substant=
ially changed.  /



Networks that serve battery-powered devices should try to maximize the

interval between the  multicast RAs within the limits allowed by

protocol - unless the information in the RA packet has changed. On the

other hand, the maximum value should be bound to allow a sufficient

number of RAs to be sent within the router/prefix lifetimes - to

account for the potential packet loss in the wireless network. This

packet loss will depend on the quality of the radio spectrum/coverage

and may need to be decided on a per-network basis. In the best-case

scenario one would ensure that at least 3 (a chosen arbitrary value)

RAs are transmitted within the smallest of the lifetimes for the

parameters contained within the RA.  /



Or something along these lines.



>

> So if the protocols ever change, the BCP value may no longer appropriat=
e

> e.g. if draft-krishnan-6man-maxra becomes a standard.

>

> Why not specify in terms of the upper limit of the protocol, and

> formula, rather than a specific time?

>

> e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writing=


> is 1800 seconds (derived from RFC4861 Section 6.2.1)

>

> Suggested text:

>

> s/Networks that serve battery-powered devices SHOULD NOT send

>         multicast RAs too frequently (e.g., mo=
re than one every 5-10

>         minutes for current battery-powered de=
vices) unless the

>         information in the RA packet has subst=
antially changed.  If there

>         is a desire to ensure that hosts pick u=
p configuration changes

>         quickly, those networks MAY send frequ=
ent Router Advertisements

>         for a limited period of time (e.g., no=
t more than one minute)

>         immediately after a configuration chan=
ge./

>

> 3. Routers with network interfaces that are known to serve

> battery-powered devices SHOULD NOT send multicast RAs too frequently
> unless the information in the RA packet has substantially changed.

>



Up until here I agree with the bullet point text, but I have a commen=
t

for the below.



> The BCP value for MinRtrAdvInterval can be derived using the formula
> 0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the

> maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861
> Section 6.2.1] suggesting MaxRtrAdvInterval =3D 1800 and MinRtrAdvInter=
val

> =3D 600 seconds.



This part largely rephrases the text from RFC4861:



      MinRtrAdvInterval

....



                     =
Default: 0.33 * MaxRtrAdvInterval If

                     =
MaxRtrAdvInterval >=3D 9 seconds; otherwise, the

                     =
Default is MaxRtrAdvInterval.



Why repeating it here ?



Also, I find the reasoning using the final effective RA interval to be

easier for the reader to get the spirit of the document, rather than

prescribing the Min/Max values.



Thus the suggested alternative wording above.



>

> 4. If there is a desire to ensure that hosts pick up configuration

> changes quickly, those router interfaces MAY send frequent multicast RA=


> for a limited period of time immediately after a configuration change.<=
br>
>

> A suggested (arbritary) time limit for this behavior is one minute.
=



Splitting this into a separate bullet point for extra emphasis is
=

reasonable indeed, thanks!



--a



> /

>

>>> s/Networks that serve battery-powered devices /Routers with net=
work

>>> interfaces that are known to serve battery-powered devices/
=

>>>

>>

>> Thanks, noted!

>>

>> --a

>>

>>> --

>>> regards,

>>> RayH

>>> <https://www.postbox-inc.com/?utm_source=3Demail&utm_medium=3D=
siglink&utm_campaign=3Dreach>

>>>

>>

>

> --

> regards,

> RayH


> <https://www.postbox-inc.c=
om/?utm_source=3Demail&utm_medium=3Dsiglink&utm_campaign=3Dreach=
>

>



_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





=

--Apple-Mail-A9CB0B8D-DA07-49AA-993F-CB67563501BC--


From nobody Sat Aug 29 01:31: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 79FF11AD0AA for ; Sat, 29 Aug 2015 01:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.449
X-Spam-Level: 
X-Spam-Status: No, score=-0.449 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPGp4txf6MSE for ; Sat, 29 Aug 2015 01:30:56 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::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 7CECA1ACEA8 for ; Sat, 29 Aug 2015 01:30:55 -0700 (PDT)
Received: by laboe4 with SMTP id oe4so19103031lab.0 for ; Sat, 29 Aug 2015 01:30:54 -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=AAaXYcrKJ4Ue1ihSuNau6wYHlwTHAfbEJeLt8yJffDg=; b=kt4hTGxpr319Q6LjyHpYkOkTm2TFs8jgWjhtCr8p8iEgiEdQYj7z8rVUskNhYmu81o C1INpj1NcYTow8KiEdq7MTOYRTsO7oBQo7p5OStNBZDMFqYCwuKoO/HERGOxmPknqE2g Vvw1nWBP5r/oPaEcENK2dndlfZ2H2Iurj8maGLjQ7Hkc9gUy9zhReopWJNgu5YTciH++ kE0opN9lTyDFvloh9M1ehbZrujB5ug2lTWfT1+rPObnUA8s8DdDBbIn0NCzn+Gxf+yTx LwG7lZZHgD1HwMh2EBvyFRiWkhgub4H8BeJ7uTMk6OtPlx5NoA1+9toPdiVTLwZMdXAZ 7ABg==
MIME-Version: 1.0
X-Received: by 10.152.23.167 with SMTP id n7mr6538318laf.108.1440837053874; Sat, 29 Aug 2015 01:30:53 -0700 (PDT)
Received: by 10.25.41.207 with HTTP; Sat, 29 Aug 2015 01:30:53 -0700 (PDT)
In-Reply-To: <5BF6A0DA-AF63-47EB-AEDE-A5206C541197@gmail.com>
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>  <55E01757.7080208@globis.net>   <5BF6A0DA-AF63-47EB-AEDE-A5206C541197@gmail.com>
Date: Sat, 29 Aug 2015 09:30:53 +0100
Message-ID: 
From: Nabil Benamar 
To: =?UTF-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= 
Content-Type: multipart/alternative; boundary=089e0160a5e6c68e61051e6f0481
Archived-At: 
Cc: "Ray Hunter \(v6ops\)" , v6ops list 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 29 Aug 2015 08:30:59 -0000

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

Hi Andrew,

The suggested text is better than the original one. It doesn't contain an
arbitrary values for sending RAs. It replaces the "Networks administrators"
by " Networks", which is ok because we can't rely only on Admins to set up
the feature of RA unicast...Maybe another draft could tackle the issue of
smartness of routers and their ability to detect the nature of the network
in a given link (battery-powered devices )

Best regards
Nabil    =D9=86=D8=A8=D9=8A=D9=84



On Sat, Aug 29, 2015 at 12:27 AM, Andrew =F0=9F=91=BD Yourtchenko 
wrote:

> Hi Nabil,
>
> Inline...
>
> On 28 Aug 2015, at 20:43, Nabil Benamar  wrote:
>
> I have read the draft and I'm supporting it. I have just one question
> about the chosen values of RA. " Networks that serve battery-powered
> devices SHOULD NOT send
>
>        multicast RAs too frequently (e.g., more than one every 5-10
>        minutes for current battery-powered devices)
> =E2=80=8B..."=E2=80=8B
>
> =E2=80=8BHow these values have been chosen ? Why 5-10 minutes exactly ?=
=E2=80=8B
>
>
>
> Arbitrarily - on a basis that it is much better than every 3 seconds :-)
> I've sent the proposed text without arbitrary values (suggesting to
> maximize he interval within protocol limits taking into account potential
> packet loss).
>
> my message to Ray which you sent this reply to has a new proposed
> replacement text - could you take a look and tell what you think about it=
 ?
>
> --a
>
> Best regards
> Nabil    =D9=86=D8=A8=D9=8A=D9=84
>
>
>
> On Fri, Aug 28, 2015 at 1:23 PM, Andrew =F0=9F=91=BD Yourtchenko  > wrote:
>
>> inline.
>>
>> On 8/28/15, Ray Hunter (v6ops)  wrote:
>> > inline.
>> >
>> >> Andrew =F0=9F=91=BD Yourtchenko 
>> >> 27 Aug 2015 17:20
>> >> On 8/27/15, Ray Hunter (v6ops)  wrote:
>> >>> fred@cisco.com wrote:
>> >>>> This is to initiate a two week working group last call of
>> >>>>
>> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumpti=
on
>> .
>> >>>> Please read it now. If you find nits (spelling errors, minor
>> suggested
>> >>>> wording changes, etc), comment to the authors; if you find greater
>> >>>> issues, such as disagreeing with a statement or finding additional
>> >>>> issues that need to be addressed, please post your comments to the
>> >>>> list.
>> >>>>
>> >>>> We are looking specifically for comments on the importance of the
>> >>>> document as well as its content. If you have read the document and
>> >>>> believe it to be of operational utility, that is also an important
>> >>>> comment to make.
>> >>>>
>> >>>>
>> >>> I have read this draft. I understand the motivation, it is clearly
>> >>> written, and I support it.
>> >>>
>> >>> Minor Suggestions:
>> >>>
>> >>> I'd reference 4861 in the first sentence of the intro.
>> >>> s/Routing information is communicated to IPv6 hosts by Router
>> >>> Advertisement messages. /Routing information is communicated to IPv6
>> >>> hosts by Router Advertisement messages [RFC4861]/
>> >>
>> >> Thanks, noted!
>> >>
>> >>> Recommendation 2 is redundant IMHO. THere's no way a router
>> manufacturer
>> >>> can really know if the devices it is serving are battery powered
>> devices
>> >>> or not (perhaps the subject of another draft e.g. perhaps extension =
to
>> >>> 4620 to discover this via NI on creating a new ND cache entry?)
>> >>
>> >> It's not entirely redundant, the intent here is that this mechanism i=
s
>> >> enabled on the network, which has two parts:
>> >>
>> >> 1) the equipment on the network has an option to enable it. (e.g. the
>> >> administrator needs to ensure that their equipment supports it).
>> >>
>> >> 2) the administrator has enabled it. (e.g. today's Cisco
>> >> implementation simply has the command "ipv6 nd ra solicited unicast"
>> >> which needs to be configured).
>> >>
>> >> How about a small tweak as below:
>> >>
>> >> "2) Administrators of networks that serve large numbers (tens or
>> >> hundreds) of battery-
>> >>         powered devices SHOULD enable this behaviour."
>> > Works for me.
>> >>> For recommendation 3: the timing recommendations should be more
>> >>> concrete, provided rough consensus can be achieved. In order to
>> maximize
>> >>> the benefit I'd suggest specifying the upper end of the suggested
>> >>> ranges.
>> >>
>> >> I tend to configure such networks with the RA interval of 1800
>> >> seconds, with router lifetime of 9000 seconds (and when
>> >> draft-krishnan-6man-maxra gets through, will be happy to bump those
>> >> values up to 21K and 64K respectively). Lorenzo's take is that "every
>> >> few minutes is already much better than every 3 seconds".
>> >>
>> >> So, based on my today's knowledge the upper limit is whatever is
>> >> enforced by the protocol + the usual "three-RA-per-lifetime" rule of
>> >> thumb - which looks to be in line with the text in the draft that doe=
s
>> >> not specify any upper bound.
>> >>
>> >> Does the text suggest differently ?
>> > No, but it specifies an absolute value without explaining how that val=
ue
>> > is derived.
>>
>> no, it specifies a *lower limit* - it tells the networks in question
>> should send the RAs with the interval *bigger* than X - so it's not
>> subject to change if the protocol limit increases. OTOH the X is kinda
>> pulled out of the hat, I agree.
>>
>> So, how about the following change instead:
>>
>> s/Networks that serve battery-powered devices SHOULD NOT send
>>         multicast RAs too frequently (e.g., more than one every 5-10
>>         minutes for current battery-powered devices) unless the
>>         information in the RA packet has substantially changed.  /
>>
>> Networks that serve battery-powered devices should try to maximize the
>> interval between the  multicast RAs within the limits allowed by
>> protocol - unless the information in the RA packet has changed. On the
>> other hand, the maximum value should be bound to allow a sufficient
>> number of RAs to be sent within the router/prefix lifetimes - to
>> account for the potential packet loss in the wireless network. This
>> packet loss will depend on the quality of the radio spectrum/coverage
>> and may need to be decided on a per-network basis. In the best-case
>> scenario one would ensure that at least 3 (a chosen arbitrary value)
>> RAs are transmitted within the smallest of the lifetimes for the
>> parameters contained within the RA.  /
>>
>> Or something along these lines.
>>
>> >
>> > So if the protocols ever change, the BCP value may no longer appropria=
te
>> > e.g. if draft-krishnan-6man-maxra becomes a standard.
>> >
>> > Why not specify in terms of the upper limit of the protocol, and
>> > formula, rather than a specific time?
>> >
>> > e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writin=
g
>> > is 1800 seconds (derived from RFC4861 Section 6.2.1)
>> >
>> > Suggested text:
>> >
>> > s/Networks that serve battery-powered devices SHOULD NOT send
>> >         multicast RAs too frequently (e.g., more than one every 5-10
>> >         minutes for current battery-powered devices) unless the
>> >         information in the RA packet has substantially changed.  If
>> there
>> >         is a desire to ensure that hosts pick up configuration changes
>> >         quickly, those networks MAY send frequent Router Advertisement=
s
>> >         for a limited period of time (e.g., not more than one minute)
>> >         immediately after a configuration change./
>> >
>> > 3. Routers with network interfaces that are known to serve
>> > battery-powered devices SHOULD NOT send multicast RAs too frequently
>> > unless the information in the RA packet has substantially changed.
>> >
>>
>> Up until here I agree with the bullet point text, but I have a comment
>> for the below.
>>
>> > The BCP value for MinRtrAdvInterval can be derived using the formula
>> > 0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the
>> > maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861
>> > Section 6.2.1] suggesting MaxRtrAdvInterval =3D 1800 and MinRtrAdvInte=
rval
>> > =3D 600 seconds.
>>
>> This part largely rephrases the text from RFC4861:
>>
>>       MinRtrAdvInterval
>> ....
>>
>>                      Default: 0.33 * MaxRtrAdvInterval If
>>                      MaxRtrAdvInterval >=3D 9 seconds; otherwise, the
>>                      Default is MaxRtrAdvInterval.
>>
>> Why repeating it here ?
>>
>> Also, I find the reasoning using the final effective RA interval to be
>> easier for the reader to get the spirit of the document, rather than
>> prescribing the Min/Max values.
>>
>> Thus the suggested alternative wording above.
>>
>> >
>> > 4. If there is a desire to ensure that hosts pick up configuration
>> > changes quickly, those router interfaces MAY send frequent multicast R=
A
>> > for a limited period of time immediately after a configuration change.
>> >
>> > A suggested (arbritary) time limit for this behavior is one minute.
>>
>> Splitting this into a separate bullet point for extra emphasis is
>> reasonable indeed, thanks!
>>
>> --a
>>
>> > /
>> >
>> >>> s/Networks that serve battery-powered devices /Routers with network
>> >>> interfaces that are known to serve battery-powered devices/
>> >>>
>> >>
>> >> Thanks, noted!
>> >>
>> >> --a
>> >>
>> >>> --
>> >>> regards,
>> >>> RayH
>> >>> <
>> https://www.postbox-inc.com/?utm_source=3Demail&utm_medium=3Dsiglink&utm=
_campaign=3Dreach
>> >
>> >>>
>> >>
>> >
>> > --
>> > regards,
>> > RayH
>> > <
>> https://www.postbox-inc.com/?utm_source=3Demail&utm_medium=3Dsiglink&utm=
_campaign=3Dreach
>> >
>> >
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>

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


Hi Andrew,

The suggest=
ed text is better than the original one. It doesn't contain an arbitrar=
y values for sending RAs. It replaces the "Networks administrators&quo=
t; by " Networks", which is ok because we can't rely only on =
Admins to set up the feature of RA unicast...Maybe another draft could tack=
le the issue of smartness of routers and their ability to detect the nature=
 of the network in a given link (battery-powered devices=
=C2=A0)

=

Best regards
Nabil =C2=A0 =C2=A0=D9=86=D8=A8=D9=8A=D9=84


=



On Sat, Aug 29, 2015 at 12:27 AM, Andrew =F0=
=9F=91=BD Yourtchenko <ayourtch@gmail.com> wrote:
Hi Nabil,

Inline...

On 28 Aug 2015, at 20:43, =
Nabil Benamar <=
benamar73@gmail.com> wrote:

<=
div>
I have read the draft =
and I'm supporting it. I have just one question about the chosen values=
 of RA. "=C2=A0Networks that serve battery-powered dev=
ices=C2=A0SHOULD NOT send
       multicast RAs too frequently (e.g., more than one every 5-10
       minutes for current battery-powered devices)
=E2=80=8B..."=E2=80=8B
 
=E2=80=8BHow these =
values have been chosen ? Why 5-10 minutes exactly ?=E2=80=8B



Arbitrarily - on a basis that it is much bett=
er than every 3 seconds :-) I've sent the proposed text without arbitra=
ry values (suggesting to maximize he interval within protocol limits taking=
 into account potential packet loss).

my message t=
o Ray which you sent this reply to has a new proposed replacement text - co=
uld you take a look and tell what you think about it ?

--a
=


Best regards
Nabil =C2=A0 =C2=A0=D9=86=D8=A8=D9=
=8A=D9=84




On Fri, Aug 28, 2015 at 1:23 PM, Andrew =F0=
=9F=91=BD  Yourtchenko <ayourtch@gmail.com> wrote:
inline.



On 8/28/15, Ray Hunter (v6ops) <v6ops@globis.net> wrote:

> inline.

>

>> Andrew =F0=9F=91=BD Yourtchenko <mailto:ayourtch@gmail.com>


>> 27 Aug 2015 17:20

>> On 8/27/15, Ray Hunter (v6ops)<v6ops@globis.net>=C2=A0 wrote:

>>> fred@cisco=
.com wrote:

>>>> This is to initiate a two week working group last call of<=
br>
>>>> http://to=
ols.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.

>>>> Please read it now. If you find nits (spelling errors, min=
or suggested

>>>> wording changes, etc), comment to the authors; if you find=
 greater

>>>> issues, such as disagreeing with a statement or finding ad=
ditional

>>>> issues that need to be addressed, please post your comment=
s 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 docu=
ment and

>>>> believe it to be of operational utility, that is also an i=
mportant

>>>> comment to make.

>>>>

>>>>

>>> I have read this draft. I understand the motivation, it is cle=
arly

>>> written, and I support it.

>>>

>>> Minor Suggestions:

>>>

>>> I'd reference 4861 in the first sentence of the intro.

>>> s/Routing information is communicated to IPv6 hosts by Router<=
br>
>>> Advertisement messages. /Routing information is communicated t=
o IPv6

>>> hosts by Router Advertisement messages [RFC4861]/

>>

>> Thanks, noted!

>>

>>> Recommendation 2 is redundant IMHO. THere's no way a route=
r manufacturer

>>> can really know if the devices it is serving are battery power=
ed devices

>>> or not (perhaps the subject of another draft e.g. perhaps exte=
nsion to

>>> 4620 to discover this via NI on creating a new ND cache entry?=
)

>>

>> It's not entirely redundant, the intent here is that this mech=
anism is

>> enabled on the network, which has two parts:

>>

>> 1) the equipment on the network has an option to enable it. (e.g. =
the

>> administrator needs to ensure that their equipment supports it).
>>

>> 2) the administrator has enabled it. (e.g. today's Cisco

>> implementation simply has the command "ipv6 nd ra solicited u=
nicast"

>> which needs to be configured).

>>

>> How about a small tweak as below:

>>

>> "2) Administrators of networks that serve large numbers (tens=
 or

>> hundreds) of battery-

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0powered devices SHOULD enable thi=
s behaviour."

> Works for me.

>>> For recommendation 3: the timing recommendations should be mor=
e

>>> concrete, provided rough consensus can be achieved. In order t=
o maximize

>>> the benefit I'd suggest specifying the upper end of the su=
ggested

>>> ranges.

>>

>> I tend to configure such networks with the RA interval of 1800

>> seconds, with router lifetime of 9000 seconds (and when

>> draft-krishnan-6man-maxra gets through, will be happy to bump thos=
e

>> values up to 21K and 64K respectively). Lorenzo's take is that=
 "every

>> few minutes is already much better than every 3 seconds".

>>

>> So, based on my today's knowledge the upper limit is whatever =
is

>> enforced by the protocol + the usual "three-RA-per-lifetime&q=
uot; rule of

>> thumb - which looks to be in line with the text in the draft that =
does

>> not specify any upper bound.

>>

>> Does the text suggest differently ?

> No, but it specifies an absolute value without explaining how that val=
ue

> is derived.




no, it specifies a *lower limit* - it tells the networks in que=
stion

should send the RAs with the interval *bigger* than X - so it's not

subject to change if the protocol limit increases. OTOH the X is kinda

pulled out of the hat, I agree.



So, how about the following change instead:



s/Networks that serve battery-powered devices SHOULD NOT send

=C2=A0 =C2=A0 =C2=A0 =C2=A0 multicast RAs too frequently (e.g., more than o=
ne every 5-10

=C2=A0 =C2=A0 =C2=A0 =C2=A0 minutes for current battery-powered devices) un=
less the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 information in the RA packet has substan=
tially changed.=C2=A0 /



Networks that serve battery-powered devices should try to maximize the

interval between the=C2=A0 multicast RAs within the limits allowed by

protocol - unless the information in the RA packet has changed. On the

other hand, the maximum value should be bound to allow a sufficient

number of RAs to be sent within the router/prefix lifetimes - to

account for the potential packet loss in the wireless network. This

packet loss will depend on the quality of the radio spectrum/coverage

and may need to be decided on a per-network basis. In the best-case

scenario one would ensure that at least 3 (a chosen arbitrary value)

RAs are transmitted within the smallest of the lifetimes for the

parameters contained within the RA.=C2=A0 /



Or something along these lines.



>

> So if the protocols ever change, the BCP value may no longer appropria=
te

> e.g. if draft-krishnan-6man-maxra becomes a standard.

>

> Why not specify in terms of the upper limit of the protocol, and

> formula, rather than a specific time?

>

> e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writin=
g

> is 1800 seconds (derived from RFC4861 Section 6.2.1)

>

> Suggested text:

>

> s/Networks that serve battery-powered devices SHOULD NOT send

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multicast RAs too frequently (e.g., m=
ore than one every 5-10

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minutes for current battery-powered d=
evices) unless the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information in the RA packet has subs=
tantially changed.=C2=A0 If there

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is a desire to ensure that hosts pick=
 up configuration changes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0quickly, those networks MAY send freq=
uent Router Advertisements

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for a limited period of time (e.g., n=
ot more than one minute)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0immediately after a configuration cha=
nge./

>

> 3. Routers with network interfaces that are known to serve

> battery-powered devices SHOULD NOT send multicast RAs too frequently
> unless the information in the RA packet has substantially changed.

>



Up until here I agree with the bullet point text, but I have a comme=
nt

for the below.



> The BCP value for MinRtrAdvInterval can be derived using the formula
> 0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the

> maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861<=
br>
> Section 6.2.1] suggesting MaxRtrAdvInterval =3D 1800 and MinRtrAdvInte=
rval

> =3D 600 seconds.



This part largely rephrases the text from RFC4861:



=C2=A0 =C2=A0 =C2=A0 MinRtrAdvInterval

....



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Default: 0.33 * MaxRtrAdvInterval If

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0MaxRtrAdvInterval >=3D 9 seconds; otherwise, the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Default is MaxRtrAdvInterval.



Why repeating it here ?



Also, I find the reasoning using the final effective RA interval to be

easier for the reader to get the spirit of the document, rather than

prescribing the Min/Max values.



Thus the suggested alternative wording above.



>

> 4. If there is a desire to ensure that hosts pick up configuration

> changes quickly, those router interfaces MAY send frequent multicast R=
A

> for a limited period of time immediately after a configuration change.=


>

> A suggested (arbritary) time limit for this behavior is one minute.


Splitting this into a separate bullet point for extra emphasis is
reasonable indeed, thanks!



--a



> /

>

>>> s/Networks that serve battery-powered devices /Routers with ne=
twork

>>> interfaces that are known to serve battery-powered devices/
>>>

>>

>> Thanks, noted!

>>

>> --a

>>

>>> --

>>> regards,

>>> RayH

>>> <https://www.postbox-inc.com/?utm_source=3Demail&utm_mediu=
m=3Dsiglink&utm_campaign=3Dreach>

>>>

>>

>

> --

> regards,

> RayH








--089e0160a5e6c68e61051e6f0481--


From nobody Sat Aug 29 13:55:04 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9A01B2F41; Sat, 29 Aug 2015 13:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csPN800Z4SPU; Sat, 29 Aug 2015 13:55:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F971B32F8; Sat, 29 Aug 2015 13:55:02 -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.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150829205502.9313.82329.idtracker@ietfa.amsl.com>
Date: Sat, 29 Aug 2015 13:55:02 -0700
Archived-At: 
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-pmtud-ecmp-problem-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Aug 2015 20:55:04 -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           : Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)
        Authors         : Matt Byerly
                          Matt Hite
                          Joel Jaeggli
	Filename        : draft-ietf-v6ops-pmtud-ecmp-problem-04.txt
	Pages           : 8
	Date            : 2015-08-29

Abstract:
   This document calls attention to the problem of delivering ICMPv6
   type 2 "Packet Too Big" (PTB) messages to the intended destination
   (typically the server) in ECMP load balanced or anycast network
   architectures.  It discusses operational mitigations that can be
   employed to address this class of failures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-pmtud-ecmp-problem-04


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Aug 30 11:00:07 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D021A1BE3 for ; Sun, 30 Aug 2015 11:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.611
X-Spam-Level: 
X-Spam-Status: No, score=-111.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IXHASH_X1=1.5, 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 yU_SMfbHT-j4 for ; Sun, 30 Aug 2015 11:00:05 -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 648231A1BD4 for ; Sun, 30 Aug 2015 11:00: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=1440957605; x=1442167205; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=jURAyhH52PfODhIE52RNOTYaA1eMAH8L4pdpZ9by0lYCei3l9eXV3fTR jQfsla4RqKbL2mVhiYRmzRhWoV779iYk42tQZOJ3TGIFW8AiN5ul8VY2+ /+6VVXydecrnrFnFsd7dliSMTR3uXzM2JWQwFPc/HRg2k0o/RIV3+YXgS I=;
X-IronPort-AV: E=Sophos;i="5.17,435,1437436800"; d="scan'208";a="22932912"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 30 Aug 2015 18:00:04 +0000
Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t7UI04De020550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Aug 2015 18:00:04 GMT
Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t7UI03lb019606; Sun, 30 Aug 2015 11:00:03 -0700
Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t7UI03s2019600; Sun, 30 Aug 2015 11:00:03 -0700
Date: Sun, 30 Aug 2015 11:00:03 -0700
From: fred@cisco.com
Message-Id: <201508301800.t7UI03s2019600@irp-lnx1.cisco.com>
To: v6ops@ietf.org
Archived-At: 
Subject: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 30 Aug 2015 18:00:06 -0000

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


From nobody Sun Aug 30 14:59: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 400DD1ACD98 for ; Sun, 30 Aug 2015 14:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level: 
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpY5BpLaHilu for ; Sun, 30 Aug 2015 14:59:12 -0700 (PDT)
Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id A00FC1ACD90 for ; Sun, 30 Aug 2015 14:59:12 -0700 (PDT)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Sun, 30 Aug 2015 16:59:09 -0500 (CDT)
X-Umn-Remote-Mta: [N] mail-ig0-f174.google.com [209.85.213.174] #+LO+TS+TR
X-Umn-Classification: local
Received: by igbuu8 with SMTP id uu8so16633346igb.1 for ; Sun, 30 Aug 2015 14:59:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=jjUBAXTNDSE09hGJanuilJUypSvZ1SN1gPtfDlBPuhw=; b=cUtUD3CgA8ljyrZvQLHKsdrGG2d/bt7Mk/QCe1CqXRcCPa2xbNudmR8Ee+vZMktKaI z20FWbIkOXbgzzRAnP0WIptvxgJYuCFmjoKTtjXLqIK+AHb9pgHJp0oNhQr/KxVCw/V/ k1lQMFxmYtMgiaTSrSj5IC5TCvbLbabAlYtr8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=jjUBAXTNDSE09hGJanuilJUypSvZ1SN1gPtfDlBPuhw=; b=Vkh1gNJXdWoXcXz9pE5lzeVqjnLmPlnzfvkvkMOuOiqVeqyQ3T4iv7c7RC3Yec/JH4 539+xl+WXUu4ISZOybXHZRPa9Td/orE4sMng0YRNakhJxYTBACRQ0wLJ0pBFvUGOCgoM cCo395RG6JNuTOvHzrdP6hFX0YSpIpl0zMGJsA3heIEVugR3ZYm05EpA4Rr5QBZ2AUtV VvhNOx6bJpX54wqFSgyGpFlSDmT2HoBBqM3Xo44vVcXO1SeGG0FnjYm3FclI1vvruAJg PXSFwWKLkr9zOlBp2cciMrhkPHHwI1Vd4Ud+R+Bfwj/Q0pbepZe/HgCSoVXyA1KnOmkv THFQ==
X-Gm-Message-State: ALoCoQm+mNOhWV3geJTubGUpRnNFGghnupzEvw1TUaYJ9j5Cq3rmR+scxFP4zDRkwexuPS00i+67dxiYTvMB1jJsTob7CEdUOcMzVP3/4TbJTk53Vy8IBiDprOnNA0EmR1zjXtiA9Tdx
X-Received: by 10.50.78.133 with SMTP id b5mr7657180igx.0.1440971948710; Sun, 30 Aug 2015 14:59:08 -0700 (PDT)
X-Received: by 10.50.78.133 with SMTP id b5mr7657163igx.0.1440971948260; Sun, 30 Aug 2015 14:59:08 -0700 (PDT)
Received: from ?IPv6:2601:449:8100:a59f:6c49:649b:2d21:b525? ([2601:449:8100:a59f:6c49:649b:2d21:b525]) by smtp.gmail.com with ESMTPSA id o15sm9152421igi.15.2015.08.30.14.59.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Aug 2015 14:59:06 -0700 (PDT)
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com>
In-Reply-To: <201508231800.t7NI011E029031@irp-lnx1.cisco.com>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=us-ascii
Message-Id: <6875692D-AD67-4B40-A635-047A8F7C1DFB@umn.edu>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (12H321)
From: David Farmer 
Date: Sun, 30 Aug 2015 16:59:06 -0500
To: "fred@cisco.com" 
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 30 Aug 2015 21:59:14 -0000

I've read the draft, think it is important work, and support it.

However, I have a few comments;

1. Section "3. Consequences" seems to express disapproval of ignoring RA's o=
r IPv6 traffic altogether while devices are asleep.  However, there are no r=
ecommendations regarding the proper behavior of host implementations in this=
 respect within Section 4.  Please clearly recommend RAs not be ignored, if t=
hat is the intent.  Otherwise, maybe suggest an upper limit on the period RA=
's or IPv6 traffic MAY be ignored by host implementations.

2. Section "4. Recommendations" currently intermixes recommendations for rou=
ter implementations and network operators.  I would like to see three sets o=
f recommendations that clearly delineate the recommendations for router impl=
ementations, host implementations, and network operators separately.  This m=
ay cause some slight repetition, however I think the clarity provided would b=
e very beneficial.=20

3. I think it should be noted somewhere, maybe in the introduction;

While not specifically considered in this document, too frequent multicast R=
outer Advertisement messages can negatively impact the performance of hosts a=
nd networks in many other ways than just energy consumption.

4. Section "7. Security Considerations" should note frequent sending of Roug=
e Router Advertisements could also severely impact power consumption on batt=
ery-powered hosts, see RFC6104, Section 3 and RA-Guard [RFC6105] for mitigat=
ion of Rouge Router Advertisements.


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



> On Aug 23, 2015, at 13:00, fred@cisco.com wrote:
>=20
> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption=
. =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


From nobody Sun Aug 30 22:12: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 C91C81A884B for ; Sun, 30 Aug 2015 22:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level: 
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G3ZVo66PGO8 for ; Sun, 30 Aug 2015 22:12:36 -0700 (PDT)
Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id B104F1A8893 for ; Sun, 30 Aug 2015 22:12:36 -0700 (PDT)
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 31 Aug 2015 00:12:30 -0500 (CDT)
X-Umn-Remote-Mta: [N] mail-ig0-f176.google.com [209.85.213.176] #+LO+TS+TR
X-Umn-Classification: local
Received: by igboj15 with SMTP id oj15so17151133igb.1 for ; Sun, 30 Aug 2015 22:12:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:from:subject:date:to; bh=w7Op+miraf9MLEgkj7ZO00LuECrj+9KMkRmmRFy4ik8=; b=EbeD2N9fAiDTfAtMD7iN9lo9kfPTudBYTBmnM4Ar/FF+ranYaZpWWg1C0P2kdPLYwc njfnYjAWVn+CRX+xILQWC7Jl4T/ONmK2y3pt1/eafKIxCQN02ErYdHECUyx7MSut2jqw Glr87/Kn+6qAs0AnHgIMgigQyms0r9uRUAulw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:from:subject:date:to; bh=w7Op+miraf9MLEgkj7ZO00LuECrj+9KMkRmmRFy4ik8=; b=XNfvHhZFCX64cJu0y89i25mEIIBWXqon4usPnZMWMCssu+zB42ar84ekbGydNKxVlZ 5+6dL6eobUHfzrkEHGr2t5w05en6Y7sx3BCSEqbLKp/YXg4Gd6rRhTogznIUE4f6RzDw RWwyN3E6fkJ56eKZrXw//AeF/3LLuyEQJwmvayyXkTzJWmzvMCZBLQp+YIGOa+dFh5JT ZGIdst+Rg8NZUlwH46ATx2vSGYSausaHl5Kfw3fHzILs6JfWknfjFxFDPK6Ra+OboxQq 9HLL52ITckMV+FRijquGPN6F3hyTQ71CzwaNOzPCwFCUSv5Zz03qlYg3PlqmbQmkv3eJ OzYA==
X-Gm-Message-State: ALoCoQnc7KALnNUZXNxlyrxv94UuyuAf0AsglZi5+LS1Cyvp1fJiFUIMrE9oeAxHg+1Ge91ZqBk5Zjj77yGfstFazD/rTt21qjuibeLxavsC86sHHAdICDMFWwqx1tmic/h/uiKSuQfz
X-Received: by 10.50.43.197 with SMTP id y5mr13294291igl.89.1440997950159; Sun, 30 Aug 2015 22:12:30 -0700 (PDT)
X-Received: by 10.50.43.197 with SMTP id y5mr13294269igl.89.1440997949725; Sun, 30 Aug 2015 22:12:29 -0700 (PDT)
Received: from ?IPv6:2601:449:8100:a59f:6c49:649b:2d21:b525? ([2601:449:8100:a59f:6c49:649b:2d21:b525]) by smtp.gmail.com with ESMTPSA id n8sm9879733igv.22.2015.08.30.22.12.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Aug 2015 22:12:28 -0700 (PDT)
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <6875692D-AD67-4B40-A635-047A8F7C1DFB@umn.edu>
In-Reply-To: <6875692D-AD67-4B40-A635-047A8F7C1DFB@umn.edu>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=us-ascii
Message-Id: <05C8F8F4-3515-47E1-8484-7CFF354B1C5B@umn.edu>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (12H321)
From: David Farmer 
Date: Mon, 31 Aug 2015 00:12:27 -0500
To: "v6ops@ietf.org" 
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 31 Aug 2015 05:12:38 -0000

> On Aug 30, 2015, at 16:59, David Farmer  wrote:
> ...
> 4. Section "7. Security Considerations" should note frequent sending of Ro=
uge Router Advertisements could also severely impact power consumption on ba=
ttery-powered hosts, see RFC6104, Section 3 and RA-Guard [RFC6105] for mitig=
ation of Rouge Router Advertisements.

Thinking about this a little bit more; most of the mitigation methods discus=
sed in section 3 of RFC6104 are not effective for the power consumption issu=
e, except 3.2 (which is RA-Guard) and 3.3 (ACLs).  The host would still see t=
he Rouge RA messages with the other mitigation methods.  I also think it is i=
mportant to note Rouge RAs can be caused by malicious activity or simply hos=
t misconfiguration.

So how about something like this;

7. Security Considerations

   The frequency of multicast Router Advertisement messages on a network wil=
l be=20
   significantly increased with the addition of Rouge Router Advertisements [=
RFC6104]
   either from malicious activity or simply host misconfiguration.  RA-Guard=
 [RFC6105]=20
   or ACLs, as discussed in section 3.3 of RFC6104, effectively mitigate inc=
reased=20
   power consumption on battery-powered hosts that would be caused by any Ro=
uge=20
   Router Advertisements. =20

   While effective at ensuring proper default router information is delivere=
d to hosts,=20
   most of the other mitigation methods discussed in section 3 of RFC6104 do=
 not=20
   prevent the additional Router Advertisement messages from getting to host=
s and=20
   therefore do not mitigate the power consumption issue.  Furthermore, some=
 of the=20
   methods deliver even more Router Advertisement messages to hosts, exasper=
ating=20
   the power consumption issue.


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




From nobody Mon Aug 31 01:41: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 5256C1B3B06 for ; Mon, 31 Aug 2015 01:41:43 -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 qAlDTR-Ne00d for ; Mon, 31 Aug 2015 01:41:42 -0700 (PDT)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 24EBB1B3B04 for ; Mon, 31 Aug 2015 01:41:42 -0700 (PDT)
Received: by ykey204 with SMTP id y204so39139345yke.3 for ; Mon, 31 Aug 2015 01:41: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=1dkusFadNzvmgYMPiyfu4mcJpYoJ/pTWVcZv+s4VUdo=; b=PlclxsUCibYqHki6dq6NAD7i52BE2seYTMVvRvKcnHUWEqveQBzhwhTjEytNIBsyEt QKLWFK2H6e31BcJ/116y+vLhfvCE+NYru2vg6X+x+YfveyiqWqwxOqi+0o2GsOtgSUgh bCqE5wDhJfQVIlrYCT+S6VHNSIoKwmFLR2bNdeOLYFQwbY1516cjA/IdF8XHCzQvwI6H sp5KwLfNG9XlShY/Vw8AErtfRy2qzxrrIu2vC8GDh8gqlOJnyYNcAvHbqXW0Xw5CkUnO jwWgyXDSqRR4aJUlYfsSJorcHdfr3WxP/5ORJpZlZL2drPPHmzh70b4HFAkYKp5cd9WZ 7A3A==
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=1dkusFadNzvmgYMPiyfu4mcJpYoJ/pTWVcZv+s4VUdo=; b=awqcvdRO03mqTuaAkOVg/Wu2KsGZyxILxoXKj1zE3xJusxBQDi3MlkMZOh6wxs8/y2 MubdsqrYNtitQaopDFhniuo0/TvZ6S0Uut+saUQTuCw3qOEwvvmDZby7O5O6vZd3MOlG jT5+HmNH4UI4zTEzKA02NwmWgCm1RgQFD5sPut+Zdbz91ro4rN2Ty27piesudB4gi91j zK6vCgAW94pr2qW/5rEXdyhtjkU1ibfvO9/jD4xlPX01MNtHbjaRpIPwvITKs0lU/bwo 68kiE1boTi0ltlcnHg/lzc1W/lNMMyzXZ8GEg7JmOs+yEwq2fqYyHuWR9jXSQNFTiPNe huFQ==
X-Gm-Message-State: ALoCoQkkw+GynT53WFei0iGW8xQXOkLnDu0jkW4/iU6/bJkK18rEQ3w+onWPWXnAkY0GeQpvsd+s
X-Received: by 10.129.44.139 with SMTP id s133mr19941765yws.161.1441010501402;  Mon, 31 Aug 2015 01:41:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.116.147 with HTTP; Mon, 31 Aug 2015 01:41:21 -0700 (PDT)
In-Reply-To: <05C8F8F4-3515-47E1-8484-7CFF354B1C5B@umn.edu>
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <6875692D-AD67-4B40-A635-047A8F7C1DFB@umn.edu> <05C8F8F4-3515-47E1-8484-7CFF354B1C5B@umn.edu>
From: Lorenzo Colitti 
Date: Mon, 31 Aug 2015 17:41:21 +0900
Message-ID: 
To: David Farmer 
Content-Type: multipart/alternative; boundary=001a1141e82a0e246b051e97674f
Archived-At: 
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 31 Aug 2015 08:41:43 -0000

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

On Mon, Aug 31, 2015 at 2:12 PM, David Farmer  wrote:

> 7. Security Considerations
>
>    The frequency of multicast Router Advertisement messages on a network
> will be
>    significantly increased with the addition of Rouge Router
> Advertisements [RFC6104]
>    either from malicious activity or simply host misconfiguration.
> RA-Guard [RFC6105]
>    or ACLs, as discussed in section 3.3 of RFC6104, effectively mitigate
> increased
>    power consumption on battery-powered hosts that would be caused by any
> Rouge
>    Router Advertisements.
>

I think this paragraph is much too long. If your network does not have RA
guard, you have *way* bigger problems than just increased power
consumption. We can certainly mention RA guard in passing though.


>    While effective at ensuring proper default router information is
> delivered to hosts,
>    most of the other mitigation methods discussed in section 3 of RFC6104
> do not
>    prevent the additional Router Advertisement messages from getting to
> hosts and
>    therefore do not mitigate the power consumption issue.  Furthermore,
> some of the
>    methods deliver even more Router Advertisement messages to hosts,
> exasperating
>    the power consumption issue.
>

I think this text is superfluous. A host can always cause another host to
chew up battery by sending it unicast packets.

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


On M=
on, Aug 31, 2015 at 2:12 PM, David Farmer <farmer@umn.edu> wrot=
e:
7. Security Considerations



=C2=A0 =C2=A0The frequency of multicast Router Advertisement messages on a =
network will be

=C2=A0 =C2=A0significantly increased with the addition of Rouge Router Adve=
rtisements [RFC6104]

=C2=A0 =C2=A0either from malicious activity or simply host misconfiguration=
.=C2=A0 RA-Guard [RFC6105]

=C2=A0 =C2=A0or ACLs, as discussed in section 3.3 of RFC6104, effectively m=
itigate increased

=C2=A0 =C2=A0power consumption on battery-powered hosts that would be cause=
d by any Rouge

=C2=A0 =C2=A0Router Advertisements.

I t=
hink this paragraph is much too long. If your network does not have RA guar=
d, you have *way* bigger problems than just increased power consumption. We=
 can certainly mention RA guard in passing though.
=C2=A0
=C2=A0 =C2=A0While effective at ensuring prope=
r default router information is delivered to hosts,

=C2=A0 =C2=A0most of the other mitigation methods discussed in section 3 of=
 RFC6104 do not

=C2=A0 =C2=A0prevent the additional Router Advertisement messages from gett=
ing to hosts and

=C2=A0 =C2=A0therefore do not mitigate the power consumption issue.=C2=A0 F=
urthermore, some of the

=C2=A0 =C2=A0methods deliver even more Router Advertisement messages to hos=
ts, exasperating

=C2=A0 =C2=A0the power consumption issue.

I think this text is superfluous. A host can always cause another host t=
o chew up battery by sending it unicast packets.


--001a1141e82a0e246b051e97674f--


From nobody Mon Aug 31 01: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 647A71ACE27 for ; Mon, 31 Aug 2015 01:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.088
X-Spam-Level: 
X-Spam-Status: No, score=-1.088 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, MIME_8BIT_HEADER=0.3, 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 CKPhiMA5OQnl for ; Mon, 31 Aug 2015 01:44:25 -0700 (PDT)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::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 30DFE1B2B5B for ; Mon, 31 Aug 2015 01:44:25 -0700 (PDT)
Received: by ykfw127 with SMTP id w127so20022008ykf.1 for ; Mon, 31 Aug 2015 01:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dcaFL2KNc8peVeTjcTRCrMtICe29BFtzILMVDLFenak=; b=J7Nl5ADfaoPXe++zHTi2ntwkW/W/oZFnnVVd2DQl6TmV46zHDQ3wwKBNEKPVWiw+Vj 31XyaIvfTfI6+EeiARnDQ815pBbOxzWWbS7mxuk4Z1qFMcmt/xQEZnV+p4dLuc27eX7p ik9hLRwlt/oIqY4pvjdH4ibifTzovFCpNISVX7xqTuVFDNhG5GOfaq5UQ5D5nLjVq8MC 6h+pQZAACtn7v4fY0urtFqv/3LVemeZOE5ew73d1ZQHmpkZeowEkXdZrThOCwmAbTNEJ aaBIn7gZ37AqRNAO/HfTMiI08DfIfUFFVMQDJG2xAuh4466peN5rPQE/drqc8v6VHiX9 Ye6g==
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=dcaFL2KNc8peVeTjcTRCrMtICe29BFtzILMVDLFenak=; b=C8pnpVpBoU7ErKeHpyaNhDp024De9IeasM5y3/R65euah6lJsnKf3FMYiFvR19Uwy3 JwAJ3QCw0Kx6S/OBzmxF7lcIjR76x2vTX6RfwfylFDI13vkymeCAarlUM+4Qg0HBkv2Q NsyuIBQYzI8O/wAzGrt9d5ddX3JdqC6eMaIoZxrE5+dQEBoDLizZveriA7VEaE3ukVT7 pG6FJ+sFajqzA5W703/+7hcCBALxBihqexLP6CWQze32lDbD3d5o4Ys6B+aC5Evl7dC0 UsASAL2ZZE+EU3DYoX5pBa4THNilgLGCOD8bObKX1zUsCL3fTEAG2zRMkvpwoiSN0b4N czag==
X-Gm-Message-State: ALoCoQkxXKLOAyZjg7UXvTnrCRjYr3Dvv5iodU4uV7KYTUpTO/MdWpj8r61/umUT8mhlMlzJ6zvJ
X-Received: by 10.170.186.131 with SMTP id c125mr19733096yke.25.1441010664465;  Mon, 31 Aug 2015 01:44:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.116.147 with HTTP; Mon, 31 Aug 2015 01:44:04 -0700 (PDT)
In-Reply-To: 
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>  <55E01757.7080208@globis.net> 
From: Lorenzo Colitti 
Date: Mon, 31 Aug 2015 17:44:04 +0900
Message-ID: 
To: =?UTF-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= 
Content-Type: multipart/alternative; boundary=001a113991d6c658aa051e9770d6
Archived-At: 
Cc: "Ray Hunter \(v6ops\)" , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 31 Aug 2015 08:44:26 -0000

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

On Fri, Aug 28, 2015 at 9:23 PM, Andrew =F0=9F=91=BD Yourtchenko 
wrote:

> Networks that serve battery-powered devices should try to maximize the
> interval between the  multicast RAs within the limits allowed by
> protocol - unless the information in the RA packet has changed. On the
> other hand, the maximum value should be bound to allow a sufficient
> number of RAs to be sent within the router/prefix lifetimes - to
> account for the potential packet loss in the wireless network. This
> packet loss will depend on the quality of the radio spectrum/coverage
> and may need to be decided on a per-network basis. In the best-case
> scenario one would ensure that at least 3 (a chosen arbitrary value)
> RAs are transmitted within the smallest of the lifetimes for the
> parameters contained within the RA.
>

I'd still prefer to have an absolute lifetime here, expressed in minutes.
Otherwise network administrators will do silly things like set max interval
=3D 12s, lifetime =3D 4s. I say "will" instead of "might" because I have
personally seen this happen on a network whose administrators should have
known better.

You make a very good point that text must be clear that this only applies
to periodic RAs, *not* to RAs sent when something has changed.

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


On F=
ri, Aug 28, 2015 at 9:23 PM, Andrew =F0=9F=91=BD  Yourtchenko <ayourtch@g=
mail.com> wrote:
Networks=
 that serve battery-powered devices should try to maximize the

interval between the=C2=A0 multicast RAs within the limits allowed by

protocol - unless the information in the RA packet has changed. On the

other hand, the maximum value should be bound to allow a sufficient

number of RAs to be sent within the router/prefix lifetimes - to

account for the potential packet loss in the wireless network. This

packet loss will depend on the quality of the radio spectrum/coverage

and may need to be decided on a per-network basis. In the best-case

scenario one would ensure that at least 3 (a chosen arbitrary value)

RAs are transmitted within the smallest of the lifetimes for the

parameters contained within the RA.

I&#=
39;d still prefer to have an absolute lifetime here, expressed in minutes. =
Otherwise network administrators will do silly things like set max interval=
 =3D 12s, lifetime =3D 4s. I say "will" instead of "might&qu=
ot; because I have personally seen this happen on a network whose administr=
ators should have known better.

You make a very go=
od point that text must be clear that this only applies to periodic RAs, *n=
ot* to RAs sent when something has changed.


--001a113991d6c658aa051e9770d6--


From nobody Mon Aug 31 01:46: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 7644E1B3823 for ; Mon, 31 Aug 2015 01:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.088
X-Spam-Level: 
X-Spam-Status: No, score=-1.088 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, MIME_8BIT_HEADER=0.3, 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 FvvG3b23BmWx for ; Mon, 31 Aug 2015 01:46:16 -0700 (PDT)
Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 3FA001B36BC for ; Mon, 31 Aug 2015 01:46:16 -0700 (PDT)
Received: by ykey204 with SMTP id y204so39221056yke.3 for ; Mon, 31 Aug 2015 01:46:15 -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=K+Cdc/XdHOJFvyK/+P44mNTXipvw0o9kA1Jp0nsA4Nk=; b=cxhx0arc/gEkuvRPvz+s3qNWhyTolwm7hehdKlrQ6LP77j2lBDT3RFiqJISVuL04uo cEwznGnj8GdhlIMETblsBzOPsaaYyCFhV1YYfnWErKCCudPV441HQsOPBVT2b0eHRLXP KtWJCGgCwZ+m1bjcs3f1MwpX+ZX32AOBus/eOdax0Qe7nmx5iXZxYdKJJXEbQdMBIMy3 PthmxCBXcNtEIKTAZtI1b+K47Gp3dMCEmwT3B5jmY6RNLAquC4lyhqrHFOnYvuNMeqpt RHLA1CJ9NC4gjmpfdJtxRSzgxsozEzBIqq5s9pV7rU3H9MRSK1X5XLiuvv/+tQD9RziQ aJpA==
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=K+Cdc/XdHOJFvyK/+P44mNTXipvw0o9kA1Jp0nsA4Nk=; b=K+hZv3mLDw3SbyWL7MOePw8ULTL8jOEpwsILVo7CQxStKX0p4BFe8DHHMlnZFRIyAn /vPU+4a8xHfqTLhDWjnvVkP1E0KthNd/ZxEPJLAuSBLhIK4u/UxlRvvVH4S/GfFlsKGp PdkWNtuNJOPSm85CFL7O7Q3kGDYyaAVrOiHY/fxGtSfjsmcKlweyO0Iy66qxVPdK+uR3 xhx25vWPr74FI94FsJWsCxiPFwjua+ChD4NKrdZmvje97EqwMh4ZP3NfQhWfotHsy7gM 5fovyKgTn6jQuGQG+JRTKbYq6eGm7rHo+yB9Y82qjNaZxggsWlGfe1yxOEaCixF7r8jL hlxg==
X-Gm-Message-State: ALoCoQm4apIDQjv3/Hn3WWlZabxukLSbMzAPC+0u+/5Y31S6R6rnFM8Dr2/Gn51Vl+cnI1nLjg4i
X-Received: by 10.13.198.71 with SMTP id i68mr18601590ywd.149.1441010775475; Mon, 31 Aug 2015 01:46:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.116.147 with HTTP; Mon, 31 Aug 2015 01:45:55 -0700 (PDT)
In-Reply-To: 
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net> <55DF12E0.6040603@gmail.com> 
From: Lorenzo Colitti 
Date: Mon, 31 Aug 2015 17:45:55 +0900
Message-ID: 
To: =?UTF-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= 
Content-Type: multipart/alternative; boundary=001a114e53da64308c051e97776d
Archived-At: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 31 Aug 2015 08:46:17 -0000

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

On Fri, Aug 28, 2015 at 12:31 AM, Andrew =F0=9F=91=BD Yourtchenko 
wrote:

> >   The sentence: "This is frustrating for users of   these networks."
> > does not convince me. The impact of a bad battery life is quite big, to
> > say it's just "frustrating" IMHO is not enough. I think it should be
> > remove or create a stronger sentence.
>
> If Lorenzo agrees, I'd opt for removing the sentence about the
> frustrated users.
>

Personally, I'd be more in favour of replacing "frustrating" with
"infuriating", but I guess removing it is fine too :-)

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


On F=
ri, Aug 28, 2015 at 12:31 AM, Andrew =F0=9F=91=BD  Yourtchenko <ayourtch@=
gmail.com> wrote:
>=C2=A0 =C2=A0The sentence: "This is frustrating for users=
 of=C2=A0 =C2=A0these networks."

> does not convince me. The impact of a bad battery life is quite big, t=
o

> say it's just "frustrating" IMHO is not enough. I think =
it should be

> remove or create a stronger sentence.



If Lorenzo agrees, I'd opt for removing the sentence about the
frustrated users.

Personally, I'd b=
e more in favour of replacing "frustrating" with "infuriatin=
g", but I guess removing it is fine too :-)


--001a114e53da64308c051e97776d--


From nobody Mon Aug 31 02:49: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 E48201B3F3B for ; Mon, 31 Aug 2015 02:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.749
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 zGUN7_Nx8sjj for ; Mon, 31 Aug 2015 02:49:54 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 2F4611B3EB3 for ; Mon, 31 Aug 2015 02:49:54 -0700 (PDT)
Received: by lbbtg9 with SMTP id tg9so57395580lbb.1 for ; Mon, 31 Aug 2015 02:49: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=deayTxRC9S67lwp6D6ebXckhcmh2PLGI69GXuVU6jos=; b=M9zDhatGqlOijNhx0X2Io6HQjkWR7L3qLy4QaFqmo0x97D4LzJT0b+6kehJ14pDW46 Ph612aCDCLCTqAEPxpJfvuT6O7jHkj+ZZwC55a7wVxcV6lnBtisjoZ4DUXLqRvGKvbSi n6Z1DS5UWbfRwHepKpRbK3Ql6K/otDz01WHyR2xXukMGqeHNm1SVecxlEy7BsaTBjqUs pMigc5gbkfEBSvrCRqRZAmiyXhXORtXXDmxsJH5DHrLfvVh9Wm+Ycwm8Ji7NG9mZtm51 HEHUGjuAAaANcKNddORb4yjo+AoaNpht7rwXInSKg0t1MIZYxknE0ZpSv3XYncbNhcnZ ryFQ==
MIME-Version: 1.0
X-Received: by 10.112.118.19 with SMTP id ki19mr10000857lbb.108.1441014592551;  Mon, 31 Aug 2015 02:49:52 -0700 (PDT)
Received: by 10.25.41.207 with HTTP; Mon, 31 Aug 2015 02:49:52 -0700 (PDT)
In-Reply-To: 
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>  <55E01757.7080208@globis.net>  
Date: Mon, 31 Aug 2015 10:49:52 +0100
Message-ID: 
From: Nabil Benamar 
To: Lorenzo Colitti 
Content-Type: multipart/alternative; boundary=047d7bfd001ee7c186051e985a2e
Archived-At: 
Cc: "Ray Hunter \(v6ops\)" , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 31 Aug 2015 09:49:56 -0000

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

It makes sens Lorenzo to have exact values...but these values should be
expressed using a formula not arbitrary !

Best regards
Nabil    =D9=86=D8=A8=D9=8A=D9=84



On Mon, Aug 31, 2015 at 9:44 AM, Lorenzo Colitti  wrote=
:

> On Fri, Aug 28, 2015 at 9:23 PM, Andrew =F0=9F=91=BD Yourtchenko  > wrote:
>
>> Networks that serve battery-powered devices should try to maximize the
>> interval between the  multicast RAs within the limits allowed by
>> protocol - unless the information in the RA packet has changed. On the
>> other hand, the maximum value should be bound to allow a sufficient
>> number of RAs to be sent within the router/prefix lifetimes - to
>> account for the potential packet loss in the wireless network. This
>> packet loss will depend on the quality of the radio spectrum/coverage
>> and may need to be decided on a per-network basis. In the best-case
>> scenario one would ensure that at least 3 (a chosen arbitrary value)
>> RAs are transmitted within the smallest of the lifetimes for the
>> parameters contained within the RA.
>>
>
> I'd still prefer to have an absolute lifetime here, expressed in minutes.
> Otherwise network administrators will do silly things like set max interv=
al
> =3D 12s, lifetime =3D 4s. I say "will" instead of "might" because I have
> personally seen this happen on a network whose administrators should have
> known better.
>
> You make a very good point that text must be clear that this only applies
> to periodic RAs, *not* to RAs sent when something has changed.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

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


It makes sens Lorenzo to have exa=
ct values...but these values should be expressed using a formula not arbitr=
ary !=C2=A0

Best regards
Nabil =C2=A0 =C2=A0=D9=86=
=D8=A8=D9=8A=D9=84




On Mon, Aug 31, 2015 at 9:44 AM, Lorenzo Col=
itti <lorenzo@google.com> wrote:
On Fri, Aug 28, 2015 at 9:23 PM, Andrew =F0=9F=91=BD  =
Yourtchenko <ayourtch@gmail.com> wrote:
Networks that serve battery-powered devices should try to ma=
ximize the

interval between the=C2=A0 multicast RAs within the limits allowed by

protocol - unless the information in the RA packet has changed. On the

other hand, the maximum value should be bound to allow a sufficient

number of RAs to be sent within the router/prefix lifetimes - to

account for the potential packet loss in the wireless network. This

packet loss will depend on the quality of the radio spectrum/coverage

and may need to be decided on a per-network basis. In the best-case

scenario one would ensure that at least 3 (a chosen arbitrary value)

RAs are transmitted within the smallest of the lifetimes for the

parameters contained within the RA.

<=
div>I'd still prefer to have an absolute lifetime here, expressed in mi=
nutes. Otherwise network administrators will do silly things like set max i=
nterval =3D 12s, lifetime =3D 4s. I say "will" instead of "m=
ight" because I have personally seen this happen on a network whose ad=
ministrators should have known better.

You make a =
very good point that text must be clear that this only applies to periodic =
RAs, *not* to RAs sent when something has changed.


_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops





--047d7bfd001ee7c186051e985a2e--


From nobody Mon Aug 31 10:24:49 2015
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B410E1B339D for ; Mon, 31 Aug 2015 10:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 sT8TpGf8xYpI for ; Mon, 31 Aug 2015 10:24:47 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCB41B3232 for ; Mon, 31 Aug 2015 10:24:47 -0700 (PDT)
Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t7VHOdJQ018601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Aug 2015 10:24:40 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_62F5AE08-81C2-40DC-AC1B-E1632AB2C198"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Owen DeLong 
In-Reply-To: 
Date: Mon, 31 Aug 2015 10:24:36 -0700
Message-Id: 
References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <55DF0CEB.5040500@globis.net>  <55E01757.7080208@globis.net>   
To: Nabil Benamar 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "Ray Hunter \(v6ops\)" , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption 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, 31 Aug 2015 17:24:48 -0000

--Apple-Mail=_62F5AE08-81C2-40DC-AC1B-E1632AB2C198
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes and no=E2=80=A6 A pure formula means that the output is entirely =
dependent on the input.

If we don=E2=80=99t provide good guidance on valid (arguably arbitrary) =
input value ranges, then
silliness in =3D silliness out as Lorenzo mentioned.

Owen

> On Aug 31, 2015, at 02:49 , Nabil Benamar  wrote:
>=20
> It makes sens Lorenzo to have exact values...but these values should =
be expressed using a formula not arbitrary !=20
>=20
> Best regards
> Nabil    =D9=86=D8=A8=D9=8A=D9=84
>=20
>=20
>=20
> On Mon, Aug 31, 2015 at 9:44 AM, Lorenzo Colitti > wrote:
> On Fri, Aug 28, 2015 at 9:23 PM, Andrew =F0=9F=91=BD Yourtchenko =
> wrote:
> Networks that serve battery-powered devices should try to maximize the
> interval between the  multicast RAs within the limits allowed by
> protocol - unless the information in the RA packet has changed. On the
> other hand, the maximum value should be bound to allow a sufficient
> number of RAs to be sent within the router/prefix lifetimes - to
> account for the potential packet loss in the wireless network. This
> packet loss will depend on the quality of the radio spectrum/coverage
> and may need to be decided on a per-network basis. In the best-case
> scenario one would ensure that at least 3 (a chosen arbitrary value)
> RAs are transmitted within the smallest of the lifetimes for the
> parameters contained within the RA.
>=20
> I'd still prefer to have an absolute lifetime here, expressed in =
minutes. Otherwise network administrators will do silly things like set =
max interval =3D 12s, lifetime =3D 4s. I say "will" instead of "might" =
because I have personally seen this happen on a network whose =
administrators should have known better.
>=20
> You make a very good point that text must be clear that this only =
applies to periodic RAs, *not* to RAs sent when something has changed.
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org 
> https://www.ietf.org/mailman/listinfo/v6ops =

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


--Apple-Mail=_62F5AE08-81C2-40DC-AC1B-E1632AB2C198
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes and no=E2=80=A6 A pure formula means that the output is =
entirely dependent on the input.

If we don=E2=80=99t provide good guidance on valid (arguably =
arbitrary) input value ranges, then
silliness in =3D =
silliness out as Lorenzo mentioned.

Owen

On =
Aug 31, 2015, at 02:49 , Nabil Benamar <benamar73@gmail.com>=
 wrote:

It =
makes sens Lorenzo to have exact values...but these values should be =
expressed using a formula not arbitrary ! 

Best =
regards
Nabil    =D9=86=D8=A8=D9=
=8A=D9=84


=


On Mon, Aug 31, 2015 at 9:44 =
AM, Lorenzo Colitti <lorenzo@google.com> wrote:
On Fri, Aug 28, 2015 at 9:23 PM, Andrew =F0=9F=91=BD  =
Yourtchenko <ayourtch@gmail.com> wrote:
Networks that serve =
battery-powered devices should try to maximize the

interval between the  multicast RAs within the limits allowed by

protocol - unless the information in the RA packet has changed. On =
the

other hand, the maximum value should be bound to allow a sufficient

number of RAs to be sent within the router/prefix lifetimes - to

account for the potential packet loss in the wireless network. This

packet loss will depend on the quality of the radio spectrum/coverage

and may need to be decided on a per-network basis. In the best-case

scenario one would ensure that at least 3 (a chosen arbitrary value)

RAs are transmitted within the smallest of the lifetimes for the

parameters contained within the RA.

I'd still prefer =
to have an absolute lifetime here, expressed in minutes. Otherwise =
network administrators will do silly things like set max interval =3D =
12s, lifetime =3D 4s. I say "will" instead of "might" because I have =
personally seen this happen on a network whose administrators should =
have known better.

You make a very good point that text must be clear that this =
only applies to periodic RAs, *not* to RAs sent when something has =
changed.


_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops




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

=

--Apple-Mail=_62F5AE08-81C2-40DC-AC1B-E1632AB2C198--


From nobody Mon Aug 31 18:20: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 A9D341B6F16 for ; Mon, 31 Aug 2015 18:20:24 -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 QW12ybrIygV2 for ; Mon, 31 Aug 2015 18:20:23 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 409C21B6732 for ; Mon, 31 Aug 2015 18:20:23 -0700 (PDT)
Received: by qkdv1 with SMTP id v1so25394730qkd.0 for ; Mon, 31 Aug 2015 18:20: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=PtOdvVaYuDiHpf6CpCanioBHR7rEUmRRTQIHYdpTsJw=; b=fGwnCjgLD2I8dEVqFIQVDayPXLt/nXXrc5K7jkjyFIPSlIP6fHnIQZzUHwlgxGeriJ QyP2jORWI6MzonQCpMrlHA/frTBgYoQv/1jlHKLnXZzPw8vlpS0OGg9oyozzCsYj9jWM /z2PMrtmME96/O0sZRzWYaeZCNXc6SAkJdx4QMntkkFe4RFeda5Kg7dzEQC9EVCgnaNa ZJYxzgMuDZyJIpffbFn/DRFJIr/jp6ZFym2PnqvE0r7/kUX+VoL5aNS+niCWQCj0+jGj C/YiYgpL6bSyz5KJ/zWhUTJd3vaxl/LT/3FmSLS/Qhr0vD7xKvZTXwZPSB/Si/n5NG+n fv7Q==
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=PtOdvVaYuDiHpf6CpCanioBHR7rEUmRRTQIHYdpTsJw=; b=T2zulWCaiA2Lj1FyI/hHlpQkR0D4NiJScozFIRtglpXiRVVSokNjSTJws/Z5g2QOZ4 7RBNa52RHwwFsKOPsa/uqST7QvgGMAG4G0u5aZiZXAg6uQZsAC2DmLAXvpncWMXBIJSP lajtWK/hbyflPZfzvaCgl5h7mnCiVaAQ/SYADNpD/1dHCkHIs/1ddeMEBUjXKEV05pYD 9IvU6HuCIqbE8q2eZ6hzraAzvWkPxsh9+/8EAN2MxP4DIwlNYC8+P++NfcSuimkEpcjs HDBoiA1wY7Cg973a5TASDWJJPYMlR3PQSysFC990IJzGyIsv5n3E7z0dYjyD9E132RmS GeSg==
X-Gm-Message-State: ALoCoQl1Qq7W+rdLbaDwyy5Z4r6mZWVTzJnxB7RNEB64PCdPLApjZ0jC+U8t5/bvOSR9ttCOf9gV
X-Received: by 10.13.220.131 with SMTP id f125mr23658374ywe.65.1441070422258;  Mon, 31 Aug 2015 18:20:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.116.147 with HTTP; Mon, 31 Aug 2015 18:20:02 -0700 (PDT)
In-Reply-To: 
References: 
From: Lorenzo Colitti 
Date: Tue, 1 Sep 2015 10:20:02 +0900
Message-ID: 
To: "Liushucheng (Will)" 
Content-Type: multipart/alternative; boundary=94eb2c08095e9dd905051ea55a2a
Archived-At: 
Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-host-addr-availability@tools.ietf.org" 
Subject: Re: [v6ops] Review for draft-ietf-v6ops-host-addr-availability
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 01 Sep 2015 01:20:24 -0000

--94eb2c08095e9dd905051ea55a2a
Content-Type: text/plain; charset=UTF-8

Will,

thanks for the review. Comments inline.

On Fri, Aug 28, 2015 at 12:51 PM, Liushucheng (Will)  wrote:

> >   Assigning a limited number of addresses per host implies that
> >   functions that require multiple addresses will either be unavailable
> >   (e.g., if the network provides only one IPv6 address per host, or if
> >   the host has reached the limit of the number of addresses available),
> >   or that the functions will only be available after an explicit
> >   request to the network is granted.  The necessity of explicit
>
> Could you explicitly point out which "functions" or add a reference?
>

The functions defined in the preceding section.


> Section 6:
> >    o  Using Stateless Address Autoconfiguration [RFC4862].  SLAAC allows
> >       hosts to create global IPv6 addresses on demand by simply forming
> >       new addresses from the global prefix assigned to the link.
>
> Traditional slaac only allows for a single stable address, since the
> address is generated by embedding the underlying mac address.
>

There are other ways to configure stable addresses as well, e.g., RFC7217.
Also, this discussion is not limited to only stable addresses.

>  It is also possible for a client to
> >       request additional addresses using a different DUID.
>
> Would this really comply with the spirit of DHCPv6?
>

Good question. RFC 3315 section 9 is not clear on this. One reading of that
section is that a host could run multiple "clients", each with a different
DUID. Reworded to note that this is technically possible but likely not
expected behaviour.


> > Immune to layer 3 on-  |    No   |    Yes     |   Yes   |   Yes   |
> >    | link resource          |         |            |         |         |
> >    | exhaustion attack
>
> What do you mean by "Immune to layer 3 on-link resource exhaustion attack"?
>

It means that a client cannot perform a state exhaustion attack on the
network by, e.g., configuring too many IP addresses. That's covered in
section 9.3.

Section 7:
> >In
> >   typical implementations, privacy addresses use up to 8 addresses (one
> >   per day).
>
> Any reference?
>

Added.

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


Will=
,

than=
ks for the review. Comments inline.

On Fri, Aug 28, 2015 at 12:51 PM, Liushucheng=
 (Will) <liushucheng@huawei.com> wrote:
>=C2=A0 =C2=A0Assigning a limited number of addresses=
 per host implies that

>=C2=A0 =C2=A0functions that require multiple addresses will either be u=
navailable

>=C2=A0 =C2=A0(e.g., if the network provides only one IPv6 address per h=
ost, or if

>=C2=A0 =C2=A0the host has reached the limit of the number of addresses =
available),

>=C2=A0 =C2=A0or that the functions will only be available after an expl=
icit

>=C2=A0 =C2=A0request to the network is granted.=C2=A0 The necessity of =
explicit



Could you explicitly point out which "functions" or add a referen=
ce?

The functions defined in the preced=
ing section.
=C2=A0
Section =
6:

>=C2=A0 =C2=A0 o=C2=A0 Using Stateless Address Autoconfiguration [RFC486=
2].=C2=A0 SLAAC allows

>=C2=A0 =C2=A0 =C2=A0 =C2=A0hosts to create global IPv6 addresses on dem=
and by simply forming

>=C2=A0 =C2=A0 =C2=A0 =C2=A0new addresses from the global prefix assigne=
d to the link.



Traditional slaac only allows for a single stable address, since the addres=
s is generated by embedding the underlying mac address.

There are other ways to configure stable addresses as well=
, e.g., RFC7217. Also, this discussion is not limited to only stable addres=
ses.


>=C2=A0 It is also possible for a client to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0request additional addresses using a differe=
nt DUID.



Would this really comply with the spirit of DHCPv6?
Good question. RFC 3315 section 9 is not clear on this. One re=
ading of that section is that a host could run multiple "clients"=
, each with a different DUID. Reworded to note=C2=A0that this is technicall=
y possible but likely not expected behaviour.




> Immune to layer 3 on-=C2=A0 |=C2=A0 =C2=A0 No=C2=A0 =C2=A0|=C2=A0 =C2=
=A0 Yes=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0Yes=C2=A0 =C2=A0|=C2=A0 =C2=A0Yes=
=C2=A0 =C2=A0|

>=C2=A0 =C2=A0 | link resource=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 =C2=A0 =C2=A0 =C2=A0|

>=C2=A0 =C2=A0 | exhaustion attack



What do you mean by "Immune to layer 3 on-link resource exhaustion att=
ack"?

It means that a client canno=
t perform a state exhaustion attack on the network by, e.g., configuring to=
o many IP addresses. That's covered in section 9.3.


Section 7:

>In

>=C2=A0 =C2=A0typical implementations, privacy addresses use up to 8 add=
resses (one

>=C2=A0 =C2=A0per day).



Any reference?

Added.
=



--94eb2c08095e9dd905051ea55a2a--


From nobody Mon Aug 31 18:20: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 6DD331B6F78 for ; Mon, 31 Aug 2015 18:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level: 
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T71gMr2g63Vx for ; Mon, 31 Aug 2015 18:20:54 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 D1A7A1A8894 for ; Mon, 31 Aug 2015 18:20:53 -0700 (PDT)
Received: from [181.46.190.53] (helo=[172.16.17.13]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZWaEj-0005sQ-Hq; Tue, 01 Sep 2015 03:19:45 +0200
To: IPv6 Operations 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <55E4FCB6.8040407@gont.com.ar>
Date: Mon, 31 Aug 2015 22:17:42 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org
Subject: [v6ops] Why operators filter IPv6 packets with extension headers?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Sep 2015 01:20:55 -0000

Folks,

The topic of operators dropping IPv6 packets containing extension
headers has been raised quite a few times on this list and elsewhere.

A month ago or so we published a document trying to summarize the
reasons for which operators filter IPv6 packets containing extension
headers. The document is available at:


We're currently working on a revision of this document, and would like
to hear feedback from the working group regarding our document. e.g.,

* Did we get anything wrong?
* Is there anything missing?

Or, if you like the document and agree with its content, that's also
interesting feedback to have.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1