|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Some thoughts on 240/4
Dear all,
Thanks to Vince for presenting at NANOG. Everyone should recognize by
now that this is a provocative topic. Even the authors of
draft-fuller-240space-00.txt do not altogether agree on what should
happen in the medium term. The one thing we do agree on, and we hope
you do to, is that the future is now, and that code changes need to
occur quickly if this space is to be useful for ANYTHING. I would agree
with the many people who have pointed out that there are a billion
devices out there, many of which might not ever understand 240.0.0.0/4.
But this issue is complex. There are many possibilities and I believe
it requires a bit of study before the community jumps in with both feet
as to the best answer for this space.
By way of background, and you'll see why this becomes relevant later
down in this message, I am no fan of private address space, and less a
fan of NATs. I think both add complexity into an already complex
environment and should generally be avoided. I am a co-author of both
RFC 1617 and RFC 1918, so I have some idea bout what I am talking
about. I also have enough formal training in economics to know that the
issues surrounding 240.0.0.0/4 are not simply a matter of computer
science, but not enough training to really help me drive to a conclusion
on the matter.
Having said all of this, let's talk about some possible uses for
240.0.0.0/4. When doing so, let's ask three questions:
* Who would benefit?
* What effort is involved to realize the benefit?
* What is the risk of not devoting the address space to this use?
* Are there alternatives that would equally satisfy the need in this
case?
Let's first suppose that 240.0.0.0/4 or some portion of it is made
private. This is what draft-wilson-class-e-01.txt proposed. There are
two distinct groups who could potentially benefit from private address
space. Big cable providers require a substantial number of IP addresses
just for management purposes. As Alain has already pointed out, not
every provider would want to make use of this space, but rather simply
go to IPv6. Still, some might. The effort involved in making this
space useful would be a change to cable modems, CMTS hardware, and back
end systems that need to process the address. By comparison, many cable
modems and CMTSes already have an IPv6 capability for this purpose.
Only individual providers know who their vendors are and what their back
end systems look like in order to understand just how much work is
involved. The risk of not devoting address space to this use would be a
need for large providers to bite the bullet and deploy v6 for this
purpose (n.b., this says nothing of end user use). Another alternative
to would be to mark an additional /8 or two out of the OTHER remaining
unicast space (< 224.0.0.0) as private.
Some large organizations are said to be running out of RFC 1918 space.
These organizations could benefit from some portion of 240/4 being
marked as private. The perceived benefit would be that it forestalls an
infrastructure upgrade to IPv6 that might require an out-of-cycle
depreciation hit. As a case and point, some account and billing systems
have knowledge of addresses, and the first provider to jump could end up
bearing the full brunt of the cost of the upgrade, while other providers
coast. This is the typical early adopter charge, when one finds oneself
on the left side of the Rogers Curve. Randy has spoken some to this
point, and could probably do so more eloquently than I. The problem
here is the effort required to realize the benefit. Because large
organizations have large amounts of hardware, large number of vendors to
interact with, and a large amount of management software, the cost of
using 240.0.0.0/4 is likely to approach that of upgrading to IPv6.
Worse, if someone eats the cost of doing this, they will still need to
eat the cost of moving to IPv6 later, so this would be almost a double
hit. This says nothing of actual product development costs to remove
the few lines of code that mark 240.0.0.0/4 as a martian. Another
alternative to would be to mark an additional /8 or two out of the OTHER
remaining unicast space (< 224.0.0.0) as private, as no code changes
would be necessary. I believe someone already mentioned this on the list.
As you heard at NANOG, Dino, Vince, Scott, and many others, including
myself, are investigating LISP. Another potential use of this address
space would be as RLOC space. To remind you, this would be essentially
PA space that is only seen in the network core. If widely deployed,
this would free up space outside the 240/4 block for other uses. The
effort to deploy as RLOC space would be roughly similar to our first use
case, except it will depend on what transition mechanisms are made
available. If as a matter of transition, the entire Internet has to
understand 240.0.0/4 in their FIBs and RIBs, that in itself may require
an upgrade of some software EVERYWHERE. An alternative would be to use
IPv6 address space or to continue to use IPv4 blocks as providers do
today. This use really bridges between public and private addressing,
although the astute might argue that a little public is like being a
little pregnant.
So let's talk about public use cases. If the IANA were to simply
allocate these addresses out after a time the way they do today, the
benefit would be to push out the run-out date by about 10 months. This
would require every public system on the Internet to upgrade. The
alternatives here are complex. One could move to IPv6, or use multiple
layers of NAT (although gamers would find this highly objectionable).
Arguably this where we all stand up and in a grand chorus say, "There is
no Plan B to IPv6". But here is the case for completeness' sake.
This leaves one final possible use. There can be no doubt that a market
exists today for IP address space. It is simply a black market. There
have been discussions on mailing lists such as PPML and in other forums
of what happens if a market is structured for IP address space. Putting
aside whether you believe this to be a good idea or a bad idea, should
it happen, the possibility of speculation to drive up prices would be
something that we would have to contend with. Having a big block of
addresses concentrated in some authority could well dissuade the use of
the IP address market for generating capital gain. The transition to
IPv6 will be bumpy enough without speculators. To say there are many
complex issues with this case would be a MASSIVE understatement. First
of all, it has many if not all of the problems of the previous case. It
could be that the addresses are made usable to some portion of upgraded
equipment, and that this would be sufficient to ward off speculators.
Also, the network effect and IPv6 *could* represent a price cap that
further deters speculators. The risk, however, of not considering
this use could be a very serious disruption to those who are least able
to move to IPv6. Consider for the moment any industry that requires
certification of their devices. That will take a while. In such
circumstances, a firm cannot simply move. And there are shades of gray
here. It might well be that portions of a firm are moved to IPv6 and
portions remain on v4. This will depend on service provider offerings
and vendor tool sets.
So. There are mine. You probably have others you would add to the
list. I think I can speak for Vince and Dave when I say that we should
consider these cases as we are actually removing 240.0.0.0/4 from our
bogon filters, because it's all academic if we don't change our code now.
We'll be talking more about this at the IETF in Vancouver in the
int-area meeting.
Eliot
|