It's not just host stacks and routers that would be impacted by this change. Some applications recognize RFC 1918 addresses and treat them specially, realizing that they don't work like ordinary IP addresses. Such applications would need to be updated if another block of private addresses were created. It seems like the last thing we need is another set of private addresses in IPv4 space, especially when use of such addresses is likely to result in even more flakiness because of stack, router, and application assumptions. The existing arrangement with RFC 1918 addresses and NATs (sometimes multiple layers of NATs) is already flaky enough, and reuse of addresses already makes diagnosis of problems more difficult than it needs to be. (of course, that might make IPv4 so unusable that people would be forced to migrate to IPv6, which would be a Good Thing. but I don't like the idea of deliberately making IPv4 flakier.) If these addresses are going to be reclassified, they should either be public addresses (so that when problems did occur the nature of the problem would be relatively clear), or reserved for very limited uses that won't impact legacy hosts and applications. Keith > > If the IETF published an RFC that reassigned 240/4 to private address > space usage today, it would likely be possible for enterprises to use > it within a reasonably short period, perhaps a year or so, depending > on how many vendors they work with, and their ability to assert pressure. > > Let's look at the reality of software stacks in the present time. > Micorosoft updates desktops and servers weekly or more often, and > people are fearful enough of security matters that they do apply them. > Linux vendors similarly release patches quite often. Router vendors > seem to have new software for one fix or another daily. > > If enterprises started working toward a deployment of pieces of 240/4, > vendors would make it possible. > > A few of us looked at the Class-E issue some years ago, and thought it > was worthwhile at that time to reclassify the space. Everyone > understood it would take some time before the space was widely usable. > > If there's to be any use of the space, ever, a scenario that would get > us to usability might be: > > - Reclassify Class-E space as usable address space > > - Enable a few pieces of 240/4 as private address space use. Let > people start using that. > > - Enterprises, if there's interest will push vendors to make changes > to stacks > > - In a few years, evaluate whether the space is viable for public > assignment by ARIN, et. al. > > Even if the initial use of such space is limited to a few platforms > and routers, it may be sufficiently useful to enterprises to use in > private interconnects between companies, an area where significant > difficulties are encountered today due to address re-use. > > There will of course be a chorus of responses that if changes are > required anyway, folks should just migrate to IPv6. The > counter-argument I'd make is simple: the changes required in IP stacks > to enable Class-E as valid addressing is minimal, resulting in little > new code, and thus little risk from untested code. Initially allowing > blocks from this space as additional RFC1918-style space would provide > a playground where enterprises, users and vendors could test their > wares, without risk to the public Internet. > > For enterprises, the migration to IPv6 will be slow. The protocol > stacks from all of the vendors are largely untested. I don't mean they > haven't run code coverage, had QA teams and even interoperability > testing. I mean there is limited experience with wide scale networks, > high traffic volumes, exposure to denial of service and probing > attacks. There will be vulnerabilites, just as there is with any code > that's relatively new. > > As I believed several years ago, reclassifying 240/4 is worthwhile. > Leveraging the need of enterprises for additional, sanctioned, private > IPv4 space for interconnects may result in widescale implementation. > Or it might not. The point is, it would be relatively simple to find > out, and would not be overly distracting to the IETF or to efforts to > migrate to IPv6 . _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf