Subject: Re: [sunset4] Declaring IPv4 Historic

From: Greg Skinner <[email-masked]>
Date: Fri, 2 Aug 2019 23:04:23 -0700

On Mar 22, 2016, at 5:21 AM, George, Wes <[email-masked]> wrote:
> 
> From: sunset4 <[email-masked] <mailto:[email-masked]>> on behalf of Greg Skinner <[email-masked] <mailto:[email-masked]>>
> 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.
>  
> […]
> 
> Thanks,
>  
> Wes
> 
> [1] https://tools.ietf.org/html/draft-fuller-240space-02 <https://tools.ietf.org/html/draft-fuller-240space-02>
> [2] http://www.muada.com/drafts/draft-van-beijnum-v6ops-esiit-00.txt <http://www.muada.com/drafts/draft-van-beijnum-v6ops-esiit-00.txt>
> [3] https://tools.ietf.org/html/draft-wilson-class-e-02 <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/ <http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/>
> 
> 

For what it’s worth, the IPv4 Cleanup Project [5] aims to tackle this issue.  Arguably, they’re doing code and configuration work.

[5] https://github.com/dtaht/unicast-extensions <https://github.com/dtaht/unicast-extensions>