Re: [sunset4] Declaring IPv4 Historic

"George, Wes" <wesley.george@twcable.com> Tue, 22 March 2016 12:21 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC8F12D588 for <sunset4@ietfa.amsl.com>; Tue, 22 Mar 2016 05:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kFLt_k6au7Wv for <sunset4@ietfa.amsl.com>; Tue, 22 Mar 2016 05:21:05 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 88CED12D5A4 for <sunset4@ietf.org>; Tue, 22 Mar 2016 05:21:05 -0700 (PDT)
X-SENDER-IP: 10.64.163.145
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.24,376,1454994000"; d="scan'208,217";a="1019379432"
Received: from unknown (HELO exchpapp04.corp.twcable.com) ([10.64.163.145]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 22 Mar 2016 08:20:07 -0400
Received: from EXCHPAPP03.corp.twcable.com (10.64.163.144) by exchpapp04.corp.twcable.com (10.64.163.145) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 22 Mar 2016 08:21:03 -0400
Received: from EXCHPAPP03.corp.twcable.com ([10.64.163.144]) by exchpapp03.corp.twcable.com ([10.64.163.144]) with mapi id 15.00.1156.000; Tue, 22 Mar 2016 08:21:03 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Greg Skinner <gregskinner0@icloud.com>, Lee Howard <Lee@asgard.org>
Thread-Topic: [sunset4] Declaring IPv4 Historic
Thread-Index: AQHRhDVNmlX3EgRMcEKVvfrf0BJPlw==
Date: Tue, 22 Mar 2016 12:21:03 +0000
Message-ID: <D316A883.82BB7%wesley.george@twcable.com>
References: <e91a7c30-b9c1-4da0-bc1c-b7fc1babd691@me.com>
In-Reply-To: <e91a7c30-b9c1-4da0-bc1c-b7fc1babd691@me.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.64.163.239]
x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22208.004
x-tm-as-result: No--45.289400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_D316A88382BB7wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sunset4/bvuqbcPPazA9WF1I3hye7envYRU>
Cc: "sunset4@ietf.org" <sunset4@ietf.org>
Subject: Re: [sunset4] Declaring IPv4 Historic
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sunset4/>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2016 12:21:08 -0000


From: sunset4 <sunset4-bounces@ietf.org<mailto:sunset4-bounces@ietf.org>> on behalf of Greg Skinner <gregskinner0@icloud.com<mailto:gregskinner0@icloud.com>>
Date: Monday, March 21, 2016 at 9:09 PM

It occurred to me that there might be some people who have an active interest in updating the IPv4
standard in the not too distant future, such as those who want to use 240.0.0.0/4<http://www.gossamer-threads.com/lists/nanog/users/181046>.

WG] I'd argue that they've missed their window, repeatedly. This comes up [1] every [2] few [3] years [4]. It keeps failing to gain enough momentum to go anywhere, for one primary reason: a large number of IP stacks have hard-coded rules that disallow or otherwise treat 240/4 as invalid IP space, so interfaces can't be configured with it, or will drop packets they see with those addresses in the src/dst field. Even if we changed the records tomorrow, there would be significant code and configuration work necessary to enable it for any use on most platforms, punch holes in firewalls, martian lists, etc. The same reason that it's been difficult to get broader IPv6 deployment (it's expensive and time-consuming to update legacy hardware and software and get to ubiquitous enough deployment to make it broadly useful) is the same thing that limits doing anything with Class E space today. In other words, if people are willing to put in time to make changes to an IP stack, especially on older gear, that's time better spent enabling the current protocol version, rather than delaying the inevitable. The further out on the IPv6 deployment curve we get, the less sense doing something with 240/4 makes.


Has an Historic RFC ever been put back on the standards track?  Is there even a process for doing that?  (I couldn't find one offhand.)  If the IPv4 standard was reclassified as Historic, and there was some desire from an active group to update it, that could become a big mess.

WG] There probably isn't one, because declaring a standards document historic is done via consensus just like declaring a document a standard. If there are groups that desire to update IPv4, their opportunity to express that desire is while this document is being discussed and gaining consensus to proceed. That's part of the reason this discussion is happening - it's looking for rough consensus from the IETF that we are done making changes to IPv4. If there are a few changes identified that need to be made prior to IPv4 being declared historic, I don't think that's necessarily a problem, but I think it's time for those to be identified and completed, rather than holding this out indefinitely on the change that someone might need to do something in the future.
Additionally, the IETF is not the protocol police; adhering to the standards that we generate is wholly voluntary. If a group, business, individual wishes to use 240/4 for an off–label use, and is able to convince the vendors in their particular implementation to modify the stack so that they can do so, IPv4 moving to historic status does not impact their ability to do this, any more than it impacts their ability to continue using the rest of IPv4 indefinitely.

Thanks,

Wes

[1] https://tools.ietf.org/html/draft-fuller-240space-02
[2] http://www.muada.com/drafts/draft-van-beijnum-v6ops-esiit-00.txt
[3] https://tools.ietf.org/html/draft-wilson-class-e-02
[4] http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/

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

________________________________

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