On Mar 22, 2016, at 5:21 AM, George, Wes <[email protected]> wrote: > > From: sunset4 <[email protected] <mailto:[email protected]>> on > behalf of Greg Skinner <[email protected] > <mailto:[email protected]>> > 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>
_______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
