From nobody Sat Aug 1 02:33:09 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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: [BEHAVE] [v6ops] protocols without need for ALG ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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 Sun Aug 2 08:25:07 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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: [BEHAVE] [v6ops] protocols without need for ALG ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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 Tue Aug 4 10:47:45 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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 , Mikael Abrahamsson , "Heatley, Nick" , touch@isi.edu Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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 Tue Aug 4 14:58:25 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31601ACF07 for ; Tue, 4 Aug 2015 14:58:23 -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, 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 vz2aeuLv6-nu for ; Tue, 4 Aug 2015 14:58:22 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB211ACEF7 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-10v.sys.comcast.net with comcast id 0lx91r0044tLnxL01lyKhG; 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 Archived-At: Subject: Re: [BEHAVE] protocols without need for ALG ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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 Wed Aug 5 01:36:46 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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" , Mark Smith Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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 09:59:25 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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" , Mark Smith , touch@isi.edu Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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 Tue Aug 11 05:40:11 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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: [BEHAVE] New features in Legacy IPv4 (was Re: [v6ops] protocols without need for ALG ?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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:31 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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: Toerless Eckert , "behave@ietf.org" , "v6ops@ietf.org" Subject: Re: [BEHAVE] New features in Legacy IPv4 (was Re: [v6ops] protocols without need for ALG ?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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 18:47:36 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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" , "George, Wes" Subject: Re: [BEHAVE] [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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:26 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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: [BEHAVE] [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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:57 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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: Ca By , "behave@ietf.org" , "v6ops@ietf.org" Subject: Re: [BEHAVE] [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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:11 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093E11B2E1E 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=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGwLSLTE5AvL 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 8DB211B2E1B for ; Wed, 12 Aug 2015 06:52:06 -0700 (PDT) Received: by obbhe7 with SMTP id he7so12980734obb.0 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=Ozf8MAlRc9J2QQCz+qOst/pWKb3i6yrHo3xgMgouPIQW+ndUy8/HCEJTCMVhDQhjjw aGecW8oRSzsLyoJqc93OQiBhCWlHtucF+ircFnMgijR3SDQcf8bR6Qq4IjzUSr+NrghT jgm0s7G8msklBgXLqZFTkyPRoslzgMyYBheOpNec9lK7fT2kWIitJuf9BDtrn6CwG7Bj oFoHB8coSi1AXIr5gcoksuM0d6murx73SEFJxrOvuf1h9brZl6/hIRd/mNWBQ1bPdmiX VITniI+O5QZYYbN/g+QV1lHe8V5NEJ3fytT8Dp/uHFNS/Q7JqMAkoItCU+jFqULg/ECt q8sA== X-Gm-Message-State: ALoCoQnCWq20y9fgC3kD078hD4tgp39hFnYmPvbWW1snDkcoSa5Cz9X5AH9vx4yQPB7Y7UXCcNT5 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: [BEHAVE] [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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:10 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@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: [BEHAVE] [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG 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 16:10:07 2015 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA38E1ACE9C for ; Thu, 13 Aug 2015 16:10:05 -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=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLFTzoWGNoDX for ; Thu, 13 Aug 2015 16:10:03 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9A1ACEA2 for ; Thu, 13 Aug 2015 16:10:03 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by vs-w.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-f177.google.com [209.85.223.177] #+LO+TS+TR X-Umn-Classification: local Received: by iodv127 with SMTP id v127so52545280iod.3 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=T1urnJURNbbEOZxeWwqNIHydCspeXXnx4Gt7aAlAY7vZBum2NQDbKQhMsEfsTBsx/G 3RLKviCLx3iiE1CNde+yvR5DRS7cC9R2OKExLOlCQzZeWV0+XH48eJXMTZoID2cWPW+k 9VI3k9SG3ygLbkCJvcF2ejMr/gTvrvAAUfQLvlnM6YFu4GggvdKEpmmWQDjiQLXbZszj fodp3pnQysWoW7C911VR3kB2taSNfWPXDg1GIkxqih9N2wztb6P1WrkrAIQ1ADcIcEUx ZS07/meF3ULFb6Ur+g5d1FafJ07+7Yzldq2tzW72ojKjDd0MvEvlAGHAXjJeKPNmV2zZ ncKg== X-Gm-Message-State: ALoCoQnTHBQycw1YKGtLJxRkraaHvqbl0rnd3vAvNYFbGZ1WNm6ZaoXsd/xKuXamk6YYQgZruJmGsK3Es6gUw5bI9XCVfdh71UVs9jupULF2EOK6pbFkQOT5yiHKjfI8dwjagxVrPSJs X-Received: by 10.107.138.87 with SMTP id m84mr13223695iod.115.1439507401943; 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: Ca By , "behave@ietf.org" , Mark Smith , "v6ops@ietf.org" Subject: Re: [BEHAVE] [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 23:10:05 -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

On Aug 12, 2015, at 08:25, Howard, Lee <lee.howard@twcable.com> wrote:
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--