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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf