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
In a message written on Fri, Oct 19, 2007 at 10:20:43AM +0200, Eliot Lear wrote:
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.
I have avoided the longer thread, so I thought replying to yours might be a better option. I think the discussion of what to do with 240.0.0.0/4 is premature. We need to get the code fixed, that is the most important item at this time. When we get closer to needing 240.0.0.0/4 we can evaluate at that time how much of the code has been fixed, and what the risk is to deployment. By the time we need it we may find 95% of the devices have been fixed, or we may find 5%. The problem is we neither know the timeframe in which we need it, nor do we know how fast vendors can get it fixed. In order to have the most options I applaud Vince for running this through the IETF, and I would ask everyone on this list to make it a checklist item for your very next vendor meeting. This is a small change, vendors will make it, but only if customers ask for it. Ask for patched software today and we'll be much better off tomorrow. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, 19 Oct 2007 11:00:02 EDT, Leo Bicknell said:
devices have been fixed, or we may find 5%. The problem is we neither know the timeframe in which we need it, nor do we know how fast vendors can get it fixed.
OK, everybody who thinks 240/4 is a Good Idea: How much ship date slip for the IPv6 features you need are you willing to accept when 240/4 updates blow the schedule? You can have all the IPv6 features you asked for on date X, or you can have it all plus 240/4 on date <X+N days>. What value of N are you willing to accept?
In a message written on Fri, Oct 19, 2007 at 11:19:57AM -0400, Valdis.Kletnieks@vt.edu wrote:
How much ship date slip for the IPv6 features you need are you willing to accept when 240/4 updates blow the schedule?
Why would the 240/4 updates blow the schedule? I ask this for two reasons: 1) The majority of the machines that need to be fixed are not run by the ISP. The real issue here is Microsoft, Apple, DLink, Linksys, Netgear and so on. They can ship patches without a lot of ISP involvement. 2) The change in this case has been documented to be excessively minimal. Patches for FreeBSD and Linux have been produced, and I believe both are under 5 lines. They consist of removing something to the effect: if (240/4) error ("Not allowed to be used yet."); There's no new code in 99% of the platforms, there's just removing the "IANA hasn't told us how it will be used" message and, I guess for completeness retesting. It will take longer for most vendors to have the meeting to decide it's the right thing to do than to do it. So while ISP's push forward on the IPv6 front, Microsoft, Apple and others can push out this change via normal software update mechanisms. I'm not seeing why one has any real impact on the other. Later we can evaluate success and see if it can be used. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, 19 Oct 2007 11:48:57 EDT, Leo Bicknell said:
In a message written on Fri, Oct 19, 2007 at 11:19:57AM -0400, Valdis.Kletnieks@vt.edu wrote:
How much ship date slip for the IPv6 features you need are you willing to accept when 240/4 updates blow the schedule?
Why would the 240/4 updates blow the schedule?
More code, more regression testing, same number of programmers. Do the math. Take it as a given that it *will* slip the schedule some amount, because the resources for a 240/4 feature will have to come from somewhere. So how much slippage are you willing to accept?
In a message written on Fri, Oct 19, 2007 at 12:24:44PM -0400, Valdis.Kletnieks@vt.edu wrote:
Why would the 240/4 updates blow the schedule?
More code, more regression testing, same number of programmers. Do the math.
Less code, every patch produced to date /removes/ code. More regression testing, same number of programmes, ok.
Take it as a given that it *will* slip the schedule some amount, because the resources for a 240/4 feature will have to come from somewhere. So how much slippage are you willing to accept?
Ok, I'll accept a month slippage in IPv6 "features". (What are we still waiting on, anyway?) I also believe that's also about 29 more days than most vendors should need to do the job. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, 19 Oct 2007 13:08:08 EDT, Leo Bicknell said:
Less code, every patch produced to date /removes/ code.
More regression testing, same number of programmes, ok.
I also believe that's also about 29 more days than most vendors should need to do the job.
The fun is trying to prove you in fact nailed *every* reference. Notice the mention today of an Ubuntu box that had different results for adding a route and binding an IP to an interface. Obviously, it's more than a one-line tweak, it's a one-line tweak in an unknown number of places. Bind a 240/4 address to an interface? Set a route? Set a *default* route? H.323 NAT code that grovels around inside the packets? The list goes on... And of course, you *do* need to regression test - just in case somebody's code does something insane like define an array [0..239] because they "know" that 240..255 Can Never Happen because there's the one-line check - that you just removed. Quite frankly, I'd be leery of running *any* code from a vendor that actually thinks that 30 days is probably 29 too many.
In a message written on Fri, Oct 19, 2007 at 01:23:17PM -0400, Valdis.Kletnieks@vt.edu wrote:
The fun is trying to prove you in fact nailed *every* reference. Notice the mention today of an Ubuntu box that had different results for adding a route and binding an IP to an interface. Obviously, it's more than a one-line tweak, it's a one-line tweak in an unknown number of places.
This depends highly on your OS and the quality of your previous code. Now that I'm back at my home computer, I was able to find the FreeBSD patch (and, I'm actually fairly sure there's a more offical one, from a FreeBSD core team member floating around now), which I don't think has been circulated before. I posted it originally on the ARIN PPML mailing list, and Mr Vixie made a small correction. My post: http://lists.arin.net/pipermail/ppml/2007-May/006865.html Vixie's correction: http://lists.arin.net/pipermail/ppml/2007-May/006866.html And actually, after reflection with some other people I think the correct thing to do is keep the IN_EXPERIMENTAL macro as is, and make IN_BADCLASS return 0. Some people have been looking at FreeBSD and this fixes the kernel and virtually all of the OS utilities (I won't say all, because I don't know that they have all been tested). But back to your original response. I find it offensive to suggest this should make IPv6 features "slip". If this change impacts time lines for a vendor I would expect they would pull something much less important than IPv6 support in order to make it happen. The better a job a vendor has done doing things like the FreeBSD folks have with macros and the like, the simpler the change is to make. What we need in this case is for vendors to make the change sooner rather than later, so we have a high probability of having it when we need it. While the resource impact is not zero, I strongly suggest that sending a message to a vendor that we're willing to wait years for this change, or that they can put off supporting IPv6 if they offer up this feature is the wrong message to send to vendors. They need to follow their internal processes, change it, and do it right. There's no excuse in this case for that to have impact on major features like IPv6 support; and only minimal excuse for it to impact minor features. This change has no impact on IPv6, so they should be able to do this in parallel with different resources. If we want to be ready when the time comes we all need to send the right messages to our vendors. Pick the time line your comfortable with, 3 months; 6 months; a year and tell them after that you won't purchase code without this fix. My point here is that when you pick that time line don't feel bad for your vendor giving them 6 or 12 months, it's plenty of time to do the work at hand. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Valdis,
More code, more regression testing, same number of programmers. Do the math.
Take it as a given that it *will* slip the schedule some amount, because the resources for a 240/4 feature will have to come from somewhere. So how much slippage are you willing to accept?
Let's not go too far here. As Vince pointed out, the work required is fairly minimal. It's not nothing. Particularly in IOS we do a parser check for Bogons, and this is done in other platforms as well. But still- the code involved is typically removing an entry from one or several tables. Regression will vary by platform, but that usually isn't done on a feature by feature case, and so the costs are not linear as you suggest. Eliot
Take it as a given that it *will* slip the schedule some amount, because the resources for a 240/4 feature will have to come from somewhere. So how much slippage are you willing to accept?
OK, assuming on the order of 5 lines of code, let's allow 1 day for meetings to decide to do this, one day to change the code and get the change signed off, and 1 day to do regression testing. That makes a total of 3 days slippage for IPv6 features in the worst case. Earlier in the thread we were told that releasing 240/4 could only buy us an extra year of time. Let's assume that was overly optimistic and it will only buy one twelfth of that, i.e. an extra month before IPv4 exhaustion. Seems to me that spending 3 days to get back 30 days is a very profitable proposition. Clearly, slippage of IPv6 features is not a problem and it is not a problem precisely because the proposal is to release these 240/4 addresses to have exactly the same default unicast behavior as the majority of the IPv4 space. --Michael Dillon P.S. I hope that the issues discussed on this thread will be picked up by the authors of draft-fuller because I think there is enough here to make an update to the draft worthwhile.
Leo,
We need to get the code fixed, that is the most important item at this time.
This is absolutely true. The purpose of my note was to provide an understanding of why we're splitting the process into two by demonstrating that picking the correct use requires more work. Each of the possible uses I described require much more detail and understanding. We can gain that understanding as we're changing our code since the uses are ALL unicast. Also:
I would ask everyone on this list to make it a checklist item for your very next vendor meeting.
This always helps. It would also help if you made your opinions known to "int-area@ietf.org", where this discussion continues.\ Eliot
participants (4)
-
Eliot Lear
-
Leo Bicknell
-
michael.dillon@bt.com
-
Valdis.Kletnieks@vt.edu