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