vince, thanks for your presentation on 240/4. i agree with it all. two points do not hard-code address boundaries and special addresses, as we are likely to regret doing so. two sub-lessons, ula and any other bright ideas. "Those who cannot remember the past are condemned to repeat it." -- George Santayana my first thought on how to use it revolved around the idea that the devices inside my site are more diverse than those on the transit internet. therefore, if i can use 240/4 internally, certainly we will all be able to transit it. where this died was the realization that, if i want to transit 240/4, i am expecting all the devices in *your* network to be able to handle 240/4, which is not reasonable. so i guess i come down on the private use side of the how-to-use decision. i would be interested in hearing counter-arguments. again, thanks for the preso and the work. and i presume my ciscos will soon be able to handle 240/4 at no additional hardware cost. :) randy
240/4 is tainted. The fact that some code exist somewhere to make it work is good, but the reality is that there are tons of equipment that do not support it. Deploying a large network with 240/4 is a problem of the same scale as migrating to IPv6, you need to upgrade code, certify equipment, etc... Randy pointed out rightly, this is not only your network that needs upgrading, this is all the networks who communicate with you that needs upgrading. So, classifying 240/4 as public use is unrealistic now and will remain unrealistic in the near future. Classifying it as private use should come with the health warning "use this at your own risk, this stuff can blow up your network". In other words, this is for experimental use only. - Alain. On 10/16/07 9:42 AM, "Randy Bush" <randy@psg.com> wrote:
vince,
thanks for your presentation on 240/4. i agree with it all. two points
do not hard-code address boundaries and special addresses, as we are likely to regret doing so. two sub-lessons, ula and any other bright ideas. "Those who cannot remember the past are condemned to repeat it." -- George Santayana
my first thought on how to use it revolved around the idea that the devices inside my site are more diverse than those on the transit internet. therefore, if i can use 240/4 internally, certainly we will all be able to transit it. where this died was the realization that, if i want to transit 240/4, i am expecting all the devices in *your* network to be able to handle 240/4, which is not reasonable. so i guess i come down on the private use side of the how-to-use decision. i would be interested in hearing counter-arguments.
again, thanks for the preso and the work. and i presume my ciscos will soon be able to handle 240/4 at no additional hardware cost. :)
randy
Randy pointed out rightly, this is not only your network that needs upgrading, this is all the networks who communicate with you that needs upgrading.
So, classifying 240/4 as public use is unrealistic now and will remain unrealistic in the near future.
agree
Classifying it as private use should come with the health warning "use this at your own risk, this stuff can blow up your network". In other words, this is for experimental use only.
disagree. as you point out, this is analogous to deploying ipv6; i do not think you would want us to put an "experimental" warning on that. if you certify your kit to handle it, then it will work in production. randy
On 10/16/07 11:56 AM, "Randy Bush" <randy@psg.com> wrote:
Classifying it as private use should come with the health warning "use this at your own risk, this stuff can blow up your network". In other words, this is for experimental use only.
disagree. as you point out, this is analogous to deploying ipv6; i do not think you would want us to put an "experimental" warning on that. if you certify your kit to handle it, then it will work in production.
I'm trying to avoid setting the expectation that 240/4 is just a simple extension to 10/8 and thus people should use it *today* when they run out of space in RFC1918. Thus the health warning. - Alain.
I'm trying to avoid setting the expectation that 240/4 is just a simple extension to 10/8 and thus people should use it *today* when they run out of space in RFC1918.
I don't believe you. If you were really trying to "avoid setting the expectation" then you would be communicating with the authors of http://www.ietf.org/internet-drafts/draft-fuller-240space-00.txt to see that the IETF gets their wording right. This is IETF work and IANA work at this point, not NANOG work. --Michael Dillon
An interesting tidbit of information: While traveling home via phx last night their free wireless was using 1.1.1.1 as the web auth portal. Perhaps this means that 1/8 is tainted as well? Jared Mauch On Oct 17, 2007, at 5:42 PM, <michael.dillon@bt.com> wrote:
If you were really trying to "avoid setting the expectation" then you would be communicating with the authors of http://www.ietf.org/internet-drafts/draft-fuller-240space-00.txt to see that the IETF gets their wording right.
This is IETF work and IANA work at this point, not NANOG work.
--Michael Dillon
While traveling home via phx last night their free wireless was using 1.1.1.1 as the web auth portal. Perhaps this means that 1/8 is tainted as well?
Leo Vegoda mentioned this at the last UKNOF meeting: http://www.uknof.org.uk/uknof8/Vegoda-Unallocated.pdf Cheers, Rob
On 18 Oct 2007, at 15:09, Rob Evans wrote:
While traveling home via phx last night their free wireless was using 1.1.1.1 as the web auth portal. Perhaps this means that 1/8 is tainted as well?
Leo Vegoda mentioned this at the last UKNOF meeting:
There's an article about this in the latest IPJ: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ ipj_10-3/103_awkward.html Of course, these issues aren't new: http://www.merit.edu/mail.archives/nanog/2006-05/msg00290.html But I wouldn't be surprised if the number of problems increases as we near the point that all the unicast IPv4 space is allocated. Regards, Leo Vegoda
On Tue, 16 Oct 2007, Alain Durand wrote:
Classifying it as private use should come with the health warning "use this at your own risk, this stuff can blow up your network". In other words, this is for experimental use only.
Do we need to classify anything (yet)? I say the proof is in the pudding. Once some major user decides they'll need 240/4 for something, they'll end up knocking their vendors' (probably dozens) and their own ops folks' doors. Once they get those vendors fixed up to support 240/4 in all the releases that they're interested in, and ops to change configs, they can deploy something in 240/4 for whatever (most likely private use, or private use with a NAT to the outside). If the users decide that maybe doing the legwork is too difficult.. well, maybe that's a sign that deploying 240/4 isn't worth the trouble (yet) and reclassifying would also be premature. It's not like the IETF or any other body is holding 240/4 hostage or something. It's what the vendors' code and what ops folks have configured that matters. If the code and configs can be changed and widely deployed, we have some proof that doing this might make sense at least in some context. Prior to that, there is no need to do anything. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
At 02:29 PM 10/16/2007, Pekka Savola wrote:
On Tue, 16 Oct 2007, Alain Durand wrote:
Classifying it as private use should come with the health warning "use this at your own risk, this stuff can blow up your network". In other words, this is for experimental use only.
Do we need to classify anything (yet)?
Yes.
I say the proof is in the pudding. Once some major user decides they'll need 240/4 for something, they'll end up knocking their vendors' (probably dozens) and their own ops folks' doors. Once they get those vendors fixed up to support 240/4 in all the releases that they're interested in, and ops to change configs, they can deploy something in 240/4 for whatever (most likely private use, or private use with a NAT to the outside).
It would behoove us to allocate SOME of 240/4 as private address space, and mark the rest as "future, allocatable if it's deemed possible." If all of 240/4 is given over without guidance to private address use, a huge mess will follow, should we later decide it safe to use on the public network.
If the users decide that maybe doing the legwork is too difficult.. well, maybe that's a sign that deploying 240/4 isn't worth the trouble (yet) and reclassifying would also be premature.
It's not like the IETF or any other body is holding 240/4 hostage or something.
Yes, actually, it's specifically reserved, and it's in a block above multicast. I'm sure I was not the only one who saw that and said "this probably won't be 'normal' address space." If it's going to be used as unicast space, then it'd be helpful for an RFC to say so. However, I doubt that would happen, as it will likely be shouted down by those who see it as a threat to IPv6 deployment.
It's what the vendors' code and what ops folks have configured that matters. If the code and configs can be changed and widely deployed, we have some proof that doing this might make sense at least in some context. Prior to that, there is no need to do anything.
Make a few /8's out of it available for experimental, private use. See what happens. But don't just throw the entire /4 out there for private use. We may later find it actually usable (or we may not) and want to visit that possibility later.
Daniel Senie wrote:
If all of 240/4 is given over without guidance to private address use, a huge mess will follow, should we later decide it safe to use on the public network.
Nobody would allow that to happen. Once it goes RFC1918, it would never go back. Adding four /8's to the IPv4 RIR assignable space (as you suggest) isn't buying anyone any time before we run out. The effort someone would spend figuring out if 204/4 is reachable and not-pain-inducing in their infrastructure is better spent figuring out how to make IPv6 work within their sphere of responsibilities. -David
On Tue, 16 Oct 2007 14:20:54 PDT, David Ulevitch said:
The effort someone would spend figuring out if 204/4 is reachable and not-pain-inducing in their infrastructure is better spent figuring out how to make IPv6 work within their sphere of responsibilities.
After the pain felt by 69/8, 70/8, 71/8, and others, you'd think it would almost be enough to make a provider say "screw it" and go IPv6-only. :)
On Tue, 16 Oct 2007, David Ulevitch wrote:
The effort someone would spend figuring out if 204/4 is reachable and not-pain-inducing in their infrastructure is better spent figuring out how to make IPv6 work within their sphere of responsibilities.
I agree. The current rate at which blocks of IPv4 space are being allocated to the RIRs suggests that releasing a chunk from, say, 240/5 or 248/5 for consumption gets you about 1 year, tops. jms
On 10/16/07, Justin M. Streiner <streiner@cluebyfour.org> wrote:
The effort someone would spend figuring out if 204/4 is reachable and not-pain-inducing in their infrastructure is better spent figuring out how to make IPv6 work within their sphere of responsibilities. I agree. The current rate at which blocks of IPv4 space are being allocated to the RIRs suggests that releasing a chunk from, say, 240/5 or 248/5 for consumption gets you about 1 year, tops.
A year is good. My recommendation would be to adamantly refuse to let the RIRs assign it for public space and insist that it's for experimental use only, even though these days the place for research is IPv6 or its interaction with IPv4, and maybe even put out some interesting but not actually useful piece of researchware such as RFC1149bis (homeland security emergency warning notification via location-agile mobile distribution of audio recordings using peer-to-peer avian carriers.) Then when we actually do run out of IPv4 space and major players start complaining that they're Just Not Ready for IPv6, because you know that's going to happen, have the RFC author grudgingly agree to release the space and retarget the research, giving the carriers and other players one more year to get serious. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
--- "Justin M. Streiner" <streiner@cluebyfour.org> wrote:
I agree. The current rate at which blocks of IPv4 space are being allocated to the RIRs suggests that releasing a chunk from, say, 240/5 or 248/5 for consumption gets you about 1 year, tops.
How about releasing a /6 or two in /23 increments or so with the idea of jumpstarting a market in IPv4 space explicitly stated? If clear title were granted (or at least clear 99-year lease with transferability), that might be a far more interesting IPv4 experiment than a lot of the technical projects, which should probably be moved to IPv6 by now (or if they haven't, would they please hurry up? I'd like more stuff to work). -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
At 05:20 PM 10/16/2007, David Ulevitch wrote:
Daniel Senie wrote:
If all of 240/4 is given over without guidance to private address use, a huge mess will follow, should we later decide it safe to use on the public network.
Nobody would allow that to happen. Once it goes RFC1918, it would never go back.
Adding four /8's to the IPv4 RIR assignable space (as you suggest) isn't buying anyone any time before we run out.
No. It would provide a play space where this could be explored further, and may be of use for private interconnects between some companies. It would not hurt anything to allocate this space.
The effort someone would spend figuring out if 204/4 is reachable and not-pain-inducing in their infrastructure is better spent figuring out how to make IPv6 work within their sphere of responsibilities.
The code changes to solid, proven IPv4 stacks to allow 240/4 to work are likely to expose enterprises to very little risk. Certainly we can expect it to be a lot less risk than IPv6 stacks which are at this point largely unproven. Adding additional IPv4 space from 240/4 may well buy enterprises enough time in the IPv4 world for IPv6 to receive sufficient code coverage and native deployment for corporations to accept the risk of introducing IPv6 on a broad scale. I know you're trying to beat the drum that everyone should get off their posteriors and roll out IPv6, but every time I go research another product that'd be needed, it's not ready. The latest was in reading the release notes for firewalls from one vendor. Sure the boxes will handle IPv6 in some fashion, but oh, sorry, you wanted to deploy a redundant pair of firewalls? The stateful synchronization isn't ready yet. Given the relative simplicity of the code change to activate 240/4 in an IPv4 stack, it's likely all major vendors could have patches out for allowing its use in private networks with little risk and little expendature of time. It's quite likely such changes could be out a very long time before IPv6 stacks in firewalls, routers and hosts receive sufficient testing to be deemed safe.
On Tue, Oct 16, 2007, Daniel Senie wrote:
Given the relative simplicity of the code change to activate 240/4 in an IPv4 stack, it's likely all major vendors could have patches out for allowing its use in private networks with little risk and little expendature of time. It's quite likely such changes could be out a very long time before IPv6 stacks in firewalls, routers and hosts receive sufficient testing to be deemed safe.
Remind me again how long A.B.C.0 and A.B.C.255 took to be "fixed" to be usable as IP addresses? Adrian
On Tue, 16 Oct 2007, Daniel Senie wrote:
Yes, actually, it's specifically reserved, and it's in a block above multicast.
First, my primary assumption here is that it's never reasonable to expect that 240/4 would work as a publically routed address space (cf. Randy's mail on imposing demands on others). If there is agreement so far, and the addresses would be used in non-public contexts or NATted along the way, no experiment coordination is required. You seem to be under the illusion that the IETF or IANA controls the Internet or private internets (e.g., experiments, private use, contexts not visible to the public Internet). The operators who want to do something private with this space don't need the IETF or IANA approval to do so. So they should just go ahead and do it. If they can manage to get it to work, and live to tell about it, maybe we can consider that sufficient proof that we can start thinking about reclassification. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Thus spake "Pekka Savola" <pekkas@netcore.fi>
The operators who want to do something private with this space don't need the IETF or IANA approval to do so. So they should just go ahead and do it. If they can manage to get it to work, and live to tell about it, maybe we can consider that sufficient proof that we can start thinking about reclassification.
There are, fortunately, a number of vendors that don't like to go against existing RFCs. We're one of them. Regardless of customer demand, I will block any attempt inside our development group to allow 240/4 until the IETF reclassifies it from experimental to unicast address space. Note that doing that would _not_ automatically imply that the IETF would direct IANA to delegate that space to the RIRs; the IETF could direct IANA to mark one /8 as private and the rest reserved. Releasing the rest to the RIRs shouldn't be done until it is observed that a non-trivial number of hosts on the public network support it -- if that ever happens. I can see cases for using 240/4 on private networks where one has more control over patches getting deployed (or is using OSes one can patch themselves or bully vendors to patch), but that's all that's worth discussing now. Short of someone from Microsoft indicating they'd post a patch on Windows Update for Vista, XP, and possibly earlier systems, any discussion of _when_ these addresses _might_ be usable on a public network is a waste of bits. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Thu, 18 Oct 2007, Stephen Sprunk wrote:
Thus spake "Pekka Savola" <pekkas@netcore.fi>
The operators who want to do something private with this space don't need the IETF or IANA approval to do so. So they should just go ahead and do it. If they can manage to get it to work, and live to tell about it, maybe we can consider that sufficient proof that we can start thinking about reclassification.
There are, fortunately, a number of vendors that don't like to go against existing RFCs.
So.. can you clarify. Which RFCs require routers or hosts to reject 240/4? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
* Pekka Savola:
Do we need to classify anything (yet)?
I say the proof is in the pudding. Once some major user decides they'll need 240/4 for something, they'll end up knocking their vendors' (probably dozens) and their own ops folks' doors.
If there's risk that we'll see end user assignments from 240/4 at any time in the future, this certainly reduces the set of possible experiments even further. So I think it makes sense to designate part of it as "private use, not subject to allocation" if anybody sees any benefit from encouraging experimentation.
240/4 is tainted. The fact that some code exist somewhere to make it work is good, but the reality is that there are tons of equipment that do not support it.
If you believe that, then don't use it. But don't dictate to me and everyone else what we can and cannot use in our networks. If somebody, somewhere, wants to use 240/4 then they should be allowed to do so without putting additional BUREAUCRATIC roadblocks in their way. IANA's failure to allocate 240/4 to RIRs is a bureaucratic roadblock. ARIN's failure to allocate 240/4 space to THOSE WHO DESIRE IT is a bureaucratic roadblock. IETF's failure to un-reserve 240/4 space is a bureaucratic roadblock. Investigation has shown that the router code and O/S code only requires a very simple change to enable 240/4 to function as normal IPv4 unicast addresses. Vendors have no excuse for not including this change in their next software releases. The impending exhaustion of the IPv4 space is the reason why it is an imperative for vendors to make this change. You might not use it, and I might not use it, but I believe that there will be enough people who can find some use for it that the pressure on the remaining IPv4 space will be diminished. And every extra day that we can buy before IPv4 exhaustion helps people get their IPv6 planning and deployment up to the same "carrier-level" standards as we currently enjoy with IPv4.
Deploying a large network with 240/4 is a problem of the same scale as migrating to IPv6, you need to upgrade code, certify equipment, etc...
Yes we know that, as with any other tecnological change, there is a set of ifs ands and buts that engineers need to deal with in order to use 240/4 addresses. It is good to document what these conditions are so that people don't do something stupid and just treat them as normal IPv4 unicast addresses. But, in general, the people who would request 240/4 addresses are not stupid and will do the right thing.
So, classifying 240/4 as public use is unrealistic now and will remain unrealistic in the near future.
RFC 1918 addresses are not public use yet I will bet that you see them in packets hitting the edge of your network. So you filter them. If you can't handle 240/4 then do the same, just don't tell other CONSENTING networks what they can do.
Classifying it as private use should come with the health warning "use this at your own risk, this stuff can blow up your network". In other words, this is for experimental use only.
This is ridiculous and untrue. There is no evidence that 240/4 addresses will blow up anything. A while back people reported on the NANOG list what happened when they tried to use them. Short answer, nothing happened. That's why vendors need to take out the one line of code that disables these addresses. And the buggy-whip manufacturers like you can just safely ignore the whole business. --Michael Dillon
On 10/17/07 3:38 PM, "michael.dillon@bt.com" <michael.dillon@bt.com> wrote:
240/4 is tainted. The fact that some code exist somewhere to make it work is good, but the reality is that there are tons of equipment that do not support it.
If you believe that, then don't use it.
But don't dictate to me and everyone else what we can and cannot use in our networks. If somebody, somewhere, wants to use 240/4 then they should be allowed to do so without putting additional BUREAUCRATIC roadblocks in their way. IANA's failure to allocate 240/4 to RIRs is a bureaucratic roadblock. ARIN's failure to allocate 240/4 space to THOSE WHO DESIRE IT is a bureaucratic roadblock. IETF's failure to un-reserve 240/4 space is a bureaucratic roadblock.
If you use this stuff internally and don't tell anybody about it and nobody ever know, you're fine. You do not need IANA, ARIN nor IET permission to do that. I suggest respectfully you re-read Randy's initial email. If you release 240/4 as public space, there are transitive issues. I care about having one Internet, so this matters.
Classifying it as private use should come with the health warning "use this at your own risk, this stuff can blow up your network". In other words, this is for experimental use only.
This is ridiculous and untrue. There is no evidence that 240/4 addresses will blow up anything. A while back people reported on the NANOG list what happened when they tried to use them. Short answer, nothing happened.
This is not my recollection. I, and others, tried it on many platforms and it did not work. Try it again on a windows XP box.
That's why vendors need to take out the one line of code that disables these addresses.
This is not enough to put it safely into production. All equipment & software will have to be tested and certified. This takes time & energy.
And the buggy-whip manufacturers like you can just safely ignore the whole business.
I'd appreciate if you did not insult me. - Alain.
bureaucratic roadblock. ARIN's failure to allocate 240/4 space to THOSE WHO DESIRE IT is a bureaucratic roadblock. IETF's failure to un-reserve 240/4 space is a bureaucratic roadblock.
If you use this stuff internally and don't tell anybody about it and nobody ever know, you're fine. You do not need IANA, ARIN nor IETF permission to do that.
There you go, putting another roadblock in people's way. Now they have to hack Cisco's and Microsoft's code to install their own patches. It would be a heck of a lot more efficient for the IETF to approve use of 240/4 so that vendors add support for it, and the RIRs allocate it to those who want it.
I suggest respectfully you re-read Randy's initial email. If you release 240/4 as public space, there are transitive issues. I care about having one Internet, so this matters.
Anybody who buys into this argument is living in cloud cuckoo land. There is no "ONE" Internet and probably never has been since UUNet started in the TCP/IP networking business. I know companies who use 1/8 through 8/8, and 126/8 for internal networks. In one cases there are multiple networks using 1/8 and they all interconnect through various layered NAT schemes. You think double-NAT is bad? All organizations that use IPv4 technology for any purpose, on or OFF the Internet, are eligible to go to an RIR and get globally unique addresses. Their harebrained networks impact your supply of IPv4 addresses. If you can get some of them to use globally unique addresses from 240/4 that you don't want to use, then it is to your benefit because your supply is bigger than it would have been. Please don't try to engineer other people's networks because they are not going to listen to you. It is a fact that 240/4 addresses work fine except for one line of code in IOS, MS-Windows, Linux, BSD, that explicitly disallows packets with this address. People have already provided patches for Linux and BSD so that 240/4 addresses work normally. Cisco would fix IOS if the IETF would unreserve these addresses, and likely MS would follow suit, especially after Cisco makes their changes. This is a trivial engineering challenge. Admittedly there is an interesting project management challenge in making sure that whatever network wants to use these does not have a rogue box filtering the traffic, but I'm not aware of any networking project that was not challenging to project managers.
This is ridiculous and untrue. There is no evidence that 240/4 addresses will blow up anything. A while back people reported on the NANOG list what happened when they tried to use them. Short answer, nothing happened.
This is not my recollection. I, and others, tried it on many platforms and it did not work. Try it again on a windows XP box.
"Not work" is nowhere near "blow up".
This is not enough to put it safely into production. All equipment & software will have to be tested and certified. This takes time & energy.
And is done routinely and regularly when a patch set is released. --Michael Dillon
Please don't try to engineer other people's networks because they are not going to listen to you. It is a fact that 240/4 addresses work fine except for one line of code in IOS, MS-Windows, Linux, BSD, that explicitly disallows packets with this address. People have already provided patches for Linux and BSD so that 240/4 addresses work normally. Cisco would fix IOS if the IETF would unreserve these addresses, and likely MS would follow suit, especially after Cisco makes their changes.
Now, please explain the magic method you're going to use to cause that "one line of code" to be removed from more than a billion devices that are currently able to use the Internet. Remember that a lot of these devices are deployed in spots such as little gateway NAT devices owned by John Doe at 123 Anydrive, and so when he is unable to get to some website because some brilliant hosting service has chosen to place a bunch of servers on 241.2.3.0/24, his reaction is most likely going to be "so and so sucks" and move onto a competitor's web site. Further, when one of your magic clients with the "updated" version of Windows XP that supports "IPv4-240+" and the misfortune to actually *BE* on one of those decides to contact pretty much any existing website on a VPS that's on "auto pilot", and there's a ton of those, dontchaknow, we are talking a problem significantly worse than "failed to update bogon filters". Not only does the hosting company have to fix their bogon filters, but they also have to fix the TCP stack on every server under their control, which is going to be extremely labor intensive. Do we want to start discussing all the other places that knowledge of network classes is built into software, and the subtle ways in which things may break, even if they appear to "work" for some crappy definition of "work"? Please don't try to re-engineer the entire IPv4 Internet because you'd like a small additional allocation of IP space that isn't currently usable. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Tue, Oct 16, 2007 at 11:48:00AM -0600, Alain Durand wrote:
240/4 is tainted. The fact that some code exist somewhere to make it work is good, but the reality is that there are tons of equipment that do not support it. Deploying a large network with 240/4 is a problem of the same scale as migrating to IPv6, you need to upgrade code, certify equipment, etc...
Sorry, but this is a completely bogus argument. The edits necessary to allow 240/4 took about 10 minutes on Linux (figuring out the kernel build/install process took longer, but I'm out of practice). OSX (and perhaps FreeBSD) doesn't require any changes - you can already configure 240.1.1.1/24 on your Mac today. For someone familiar with deploying binary patches on Windows, Linux, etc., I'm guessing that appropriate changes could be available in a matter of days. Compared to the substantial training (just getting NOC monkeys to understand hexidecimal can be a challenge), back office system changes, deployment dependencies, etc. to use ipv6, the effort involved in patching systems to use 240/4 is lost in the noise. Saying "deploying a large network with 240/4 is a problem of the same scale as migrating to ipv6" is like saying that trimming a hangnail is like having a leg amputated; both are painful but one is orders of magnitude more so than the other. --Vince
I hadn't intended to post any further replies, but given the source and the message here, felt this warranted it:
Compared to the substantial training (just getting NOC monkeys to understand hexidecimal can be a challenge), back office system changes, deployment dependencies, etc. to use ipv6, the effort involved in patching systems to use 240/4 is lost in the noise. Saying "deploying a large network with 240/4 is a problem of the same scale as migrating to ipv6" is like saying that trimming a hangnail is like having a leg amputated; both are painful but one is orders of magnitude more so than the other.
So is this a statement that Cisco is volunteering to provide free binary patches for its entire product line? Including the really old stuff that happens to be floating around out there and still in use? Because if it's not, your first stop should be to get your own shop in order and on board, because for a major router vendor to not make free binary patches available for its entire product line certainly does represent a huge roadblock with adoption of IPv4-240+. The day you guys release a set of free binary patches for all your previous products, including stuff like the old Compatible Systems line, old Cisco gear like the 2500, and old Linksys products, then I'll be happy to concede that I could be wrong and that vendors might actually make it possible for IPv4-240+ to be usable. Until then, this doesn't carry much credibility, and continuing this thread is a waste of time. Nobody cares if you're able to patch a current Linux system so that you can make one measly node on the Internet work with IPv4-240+. It's getting the rest of them to be patched - including all the hosts and networking gear - that's the problem. If you just want to discuss your clever Linux patches, the Linux mailing lists are >>> thataway. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Fri, Oct 19, 2007, Joe Greco wrote:
So is this a statement that Cisco is volunteering to provide free binary patches for its entire product line? Including the really old stuff that happens to be floating around out there and still in use?
Considering there's forklift upgrades required to support changes in technology anyway, I see this as not a problem. People can choose if they'd like to use that space. People -chose- to use some new IP space which had once been bogon space and then spent quite a bit of time figuring out why the hell customers couldn't reach the general internet. People adapted.
The day you guys release a set of free binary patches for all your previous products, including stuff like the old Compatible Systems line, old Cisco gear like the 2500, and old Linksys products, then I'll be happy to concede that I could be wrong and that vendors might actually make it possible for IPv4-240+ to be usable.
You know, Cisco do release updates to old IOS software periodically. ISTR seeing a Cisco 2500 IOS update -this year-. Yup: c2500-is-l.123-23.bin 16 16 25-JUL-2007 Its so not out of the realm of possibility Cisco, just as an example of one vendor of $LOTS, would do a software rebuild run just for this particular issue. All IETF "has to do" is possibly reclassify 240/4 from "experimental/future use" to "experimental unicast space" to satisfy the vendors that would block on 240/4 being routable and satisfy those who are worried that putting it on the public internet is bad (and I'm one of them for now); then let the market decide what they want to do. Adrian
On Fri, 19 Oct 2007, Adrian Chadd wrote:
People -chose- to use some new IP space which had once been bogon space and then spent quite a bit of time figuring out why the hell customers couldn't reach the general internet. People adapted.
We didn't choose it. ARIN and other RIRs started handing out that space, and if you didn't like it you were welcome to not have any more IP space. There's a huge difference between getting a handful of networks to fix their outdated filters and getting "the internet" to all upgrade their software or replace old non-upgradable gear.
You know, Cisco do release updates to old IOS software periodically. ISTR seeing a Cisco 2500 IOS update -this year-. Yup:
c2500-is-l.123-23.bin 16 16 25-JUL-2007
Lots of 2500s can't run that code. Where can I get a 240/4 compatible update of c5200-is-l.113-11a.AA.bin? Interestingly, my unpatched Ubuntu 7.04 notebook would let me install routes for networks in 240/4, but would not let me configure an interface IP in 240/4. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Fri, Oct 19, 2007 at 12:35:52PM -0400, Jon Lewis wrote:
Interestingly, my unpatched Ubuntu 7.04 notebook would let me install routes for networks in 240/4, but would not let me configure an interface IP in 240/4.
although this is not linux-l@ , here is a hint for those who keep trying: # /sbin/ifconfig eth1 240.1.2.3 netmask 255.255.255.0 SIOCSIFADDR: Invalid argument SIOCSIFNETMASK: Cannot assign requested address SIOCGIFADDR: Cannot assign requested address SIOCSIFBROADCAST: Cannot assign requested address # /sbin/ip add add 240.1.2.3/24 dev eth1 # /sbin/ip add show eth1 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:48:5d:0a:af brd ff:ff:ff:ff:ff:ff inet 240.1.2.3/24 scope global eth1 Now using this IP with the binaries that are of the same vintage as ifconfig(), that's really a discussion for linux-l@ . -andreas -- Andreas Ott K6OTT andreas@naund.org
On 16 Oct 2007, at 09:42, Randy Bush wrote:
my first thought on how to use it revolved around the idea that the devices inside my site are more diverse than those on the transit internet. therefore, if i can use 240/4 internally, certainly we will all be able to transit it. where this died was the realization that, if i want to transit 240/4, i am expecting all the devices in *your* network to be able to handle 240/4, which is not reasonable. so i guess i come down on the private use side of the how-to-use decision. i would be interested in hearing counter-arguments.
yup, this was my conclusion when i had a debate on this a while back think of all the OS protocol stacks out there that may or may not work (you can test it now, try a trace from your windows/linux/bsd/ osx box and see the different results) then even if all vendors start releasing fixed stacks, imagine how many non-upgradable network devices ($20 dsl routers, nat devices etc) are out there that wont work unfortunately i think this is a non-started for all except private deployments the other point as was mentioned later in the thread is that this buys you very little in terms of time before v4 is gone. Steve
the other point as was mentioned later in the thread is that this buys you very little in terms of time before v4 is gone.
On average, it buys everybody very little time. But that assumes that 240/4 is being released as a general solution for everybody. This is not the case. We want to release 240/4 as a solution for those organizations that are in a position to control enough variables to make it useful. For those organizations, 240/4 space could buy a LOT of time, maybe even years. And for the rest of us, the IPv4 addresses that are NOT used by those organizations, do indeed buy only a little extra time. But the point is that we are not gods. We cannot foresee all the variables. We cannot engineer a set of solutions that will work for everybody. Therefore, even if 240/4 only gives us a few extra months before IPv4 is exhausted, it is still worthwhile because it is likely to help some more organizations get their IPv6 transition completed before hitting the brick wall. Since the value of the Internet, IPv4 or IPv6, is in the near universality of access, it is to the benefit of everyone's bottom line for more organizations to complete the transition to IPv6 before IPv4 runs out. We cannot cop out on releasing 240/4 just because it is no magic bullet. How would you feel if your arguments against 240/4 and other half-measures resulted in them not being carried out. And then we hit the brick wall of IPv4 exhaustion and some businesses start to lose serious money? --Michael Dillon P.S. and how will you feel if those businesses trawl the record on the Internet to discover that you, and employee of one of their competitors, caused 240/4 to not be released and thereby harmed their businesses. You will be explaining in front of a judge. We should do everything we can to remove roadblocks which would cause IPv4 to run out sooner, or would cause some people to delay IPv6 deployment.
On Thu, 18 Oct 2007 00:41:39 BST, michael.dillon@bt.com said:
This is not the case. We want to release 240/4 as a solution for those organizations that are in a position to control enough variables to make it useful. For those organizations, 240/4 space could buy a LOT of time, maybe even years.
Those organizations will find ways to buy themselves years even without 240/4.
P.S. and how will you feel if those businesses trawl the record on the Internet to discover that you, and employee of one of their competitors, caused 240/4 to not be released and thereby harmed their businesses. You will be explaining in front of a judge.
They caused a resource that was never *planned* for release to, in fact, not be released. 240/4 has been in "reserved" ever since rfc790 in 1981. And the IPV6 RFCs have been out for a decade as well, so it isn't like they haven't had years to plan. But hey, the SCO lawsuit is still alive too (if on life support after it was stayed by their filing Chapter 11 to escape from their own lawsuits), so what do I know? Maybe there's an actual chance that would fly.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of michael.dillon@bt.com
We want to release 240/4 as a solution for those organizations that are in a position to control enough variables to make it useful. For those organizations, 240/4 space could buy a LOT of time, maybe even years.
If this block was to be released to an RIR, who could possibly have a use for it? You can control your own variables, but if I'm an ISP/customer, I'm going to find an address allocation that leaves 99% of the Internet as a whole unreachable as pretty useless. I might was well just use RFC1918 space. Asking the whole internet to support 240/4 is going to tie up valuable resources that would be far better off working on IPv6. Keep in mind that it's not just software patches. Software vendors don't do stuff for free. I doubt ISPs are going to pay huge amounts of money to support a peer crazy enough to try this. And until tested, there is no guarantee that hardware based routing platforms (your PFCs, etc) can route Class E addresses as if they're unicast. Just my .02 though.... Chuck
Asking the whole internet to support 240/4 is going to tie up valuable resources that would be far better off working on IPv6. Keep in mind that it's not just software patches. Software vendors don't do stuff for free. I doubt ISPs are going to pay huge amounts of money to support a peer crazy enough to try this. And until tested, there is no guarantee that hardware based routing platforms (your PFCs, etc) can route Class E addresses as if they're unicast.
So how about pulling a reachability test and announcing a few /19's from 240/4, stick a website on it and get people to report back? Adrian
On 18.10 10:48, Adrian Chadd wrote:
Asking the whole internet to support 240/4 is going to tie up valuable resources that would be far better off working on IPv6. Keep in mind that it's not just software patches. Software vendors don't do stuff for free. I doubt ISPs are going to pay huge amounts of money to support a peer crazy enough to try this. And until tested, there is no guarantee that hardware based routing platforms (your PFCs, etc) can route Class E addresses as if they're unicast.
So how about pulling a reachability test and announcing a few /19's from 240/4, stick a website on it and get people to report back?
If there was serious community interest in this, I am sure the RIPE NCC could be persuaded to test this as part of the well-oiled de-bogonising machinery. this immediately provides automated measurements as well. It may take a little longer than sual to set up as we may want to ask all our de-bogonising peers whether they are OK with this just to be sure. Daniel PS: Personally I am not convinced that this space will ever become useful for global routing. But we won't know for sure until we have tried it.
Okay, this has descended to a point where we need some fact injection. This very morning, I have done some simple research. My research focused on the question, "what if 240/4 were released for use on the public Internet." I am not interested in the question of "what if 240/4 were released for RFC1918 use behind NAT devices," though implementors may find some of the same problems that I did. I attempted(!) to configure: Windows XP FreeBSD 4 FreeBSD 6 Mandriva Linux for use with 240/4 on a standard Ethernet interface. Both Windows XP and Mandriva Linux refused to accept 240 as a valid first octet. Both FreeBSD 4 and FreeBSD 6 accepted the 240 address, but would not put traffic on the wire, and did not answer a local ping of the address (i.e. "ping 240.0.0.2" on the box with 240.0.0.2). I use a FreeBSD based router here at the house, and I had configured it as 240.0.0.1. It does not answer a local ping for 240.0.0.1. However, from a directly connected client on a normally addressed IP network, I am actually able to ping 240.0.0.1: % ping 240.0.0.1 PING 240.0.0.1 (240.0.0.1): 56 data bytes 64 bytes from 240.0.0.1: icmp_seq=0 ttl=64 time=0.371 ms 64 bytes from 240.0.0.1: icmp_seq=1 ttl=64 time=0.379 ms 64 bytes from 240.0.0.1: icmp_seq=2 ttl=64 time=0.445 ms 64 bytes from 240.0.0.1: icmp_seq=3 ttl=64 time=0.255 ms ^C --- 240.0.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.255/0.363/0.445/0.068 ms However, pings for 240.0.0.2 do not result in any traffic on the 240.0.0.* wire. Quagga did not seem to be interested in propagating the route to the other router, though I did not bother to investigate this. Looking to this bright point of success, I proceeded to ask Windows XP to ping 240.0.0.1, hoping that perhaps it would be acceptable as a destination. Windows XP responded with "Destination specified is invalid." I then tried with the Mandriva, which responded with "connect: Invalid argument." So. We can draw some interesting and useful conclusions. A number of major client and server operating systems do not currently work with "IPv4-240+". It is certainly possible to make any given major client or server operating system work with "IPv4-240+", but doing so only fixes one endpoint. The Internet works because there's a general property that any node can talk to any other node. Introducing nodes that can only talk to other nodes with shiny new IP stacks introduces a problem similar to the transition to IPv6, except that the transition to IPv6 is at least a fairly obvious and readily- identifiable issue. If you ask someone "do you support IPv6", it's pretty easy to know. If you ask someone "do you support IPv4-240+", that's less easy to know. Getting all nodes to upgrade to "IPv4-240+" is simply not possible. I have no idea where I'd get the upgrade for the Ascend GRF's (okay, well, they're not in production, but point remains). The ROI on the move to v6 is immense compared to the ROI on the move to v4-240+, which will surely only benefit a few. Do the math. This is stupid. If you happen to have all WinXP clients, a patch to make 240 work, and you stick them all behind NAT, well, golly, by all means, have fun.
the other point as was mentioned later in the thread is that this buys you very little in terms of time before v4 is gone.
On average, it buys everybody very little time. But that assumes that 240/4 is being released as a general solution for everybody.
This is not the case. We want to release 240/4 as a solution for those organizations that are in a position to control enough variables to make it useful. For those organizations, 240/4 space could buy a LOT of time, maybe even years. And for the rest of us, the IPv4 addresses that are NOT used by those organizations, do indeed buy only a little extra time.
The problem is that it's not useful space if it can't talk to most of the Internet. And if you're proposing it as NAT space, then it isn't really relevant if the space is "released" or not. Just use it. It's a virtual certainty that Class E space will never find some new magic use.
But the point is that we are not gods. We cannot foresee all the variables.
Yeah, well, maybe YOU can't, but *I* can see enough of the variables to reliably predict a "doomed to failure." I don't need to see all the variables.
We cannot engineer a set of solutions that will work for everybody.
Therefore, you want to engineer a solution that'll work for mostly nobody? Great.
Therefore, even if 240/4 only gives us a few extra months before IPv4 is exhausted, it is still worthwhile because it is likely to help some more organizations get their IPv6 transition completed before hitting the brick wall.
So, what's your game plan to replace all these broken IPv4 stacks?
Since the value of the Internet, IPv4 or IPv6, is in the near universality of access, it is to the benefit of everyone's bottom line for more organizations to complete the transition to IPv6 before IPv4 runs out.
Certainly. So why would we distract them with an intermediate transition to "IPv4-240+"? Remember, I was not able to find any case that successfully worked; even if there are some cases that work without patching, it seems that the vast majority of sites will need to change to move from IPv4 to your transition "IPv4-240+".
We cannot cop out on releasing 240/4 just because it is no magic bullet.
But we could cop out on releasing 240/4 because it's just too much work for a small benefit to a few sites on the Internet, at a huge cost to the rest of the Internet. That's not fair.
How would you feel if your arguments against 240/4 and other half-measures resulted in them not being carried out. And then we hit the brick wall of IPv4 exhaustion and some businesses start to lose serious money?
I'm fine with that, especially since it appears that implementing "IPv4-240+" will incur even more serious money for every participating network on the Internet, in upgrades, adminitrative time and effort, etc.
--Michael Dillon
P.S. and how will you feel if those businesses trawl the record on the Internet to discover that you, and employee of one of their competitors, caused 240/4 to not be released and thereby harmed their businesses. You will be explaining in front of a judge.
Whatever. I can sue you for having blue skin. Doesn't make me right, and doesn't mean I'll win. I could even sue you for releasing 240/4 and causing me economic harm by forcing me to upgrade a bunch of infrastructure. Funny how that blade can cut both ways.
We should do everything we can to remove roadblocks which would cause IPv4 to run out sooner,
Where practical. This ... isn't.
or would cause some people to delay IPv6 deployment.
And this ... would cause some people to delay IPv6. So it's bad. Hey, I have an idea, how about we recycle all that dead air up in 224/4? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Okay, this has descended to a point where we need some fact injection.
You get a D on those facts because you did not review the "literature", did not attempt reasonable coverage of the problem space, and did not investigate whether or not there were other versions of the software that have been patched to support 240/4.
We cannot engineer a set of solutions that will work for everybody.
Therefore, you want to engineer a solution that'll work for mostly nobody?
No, therefore we should not attempt to engineer a solution that will work for everybody but merely remove the barriers that allow others to engineer solutions for their situation.
So, what's your game plan to replace all these broken IPv4 stacks?
Again, we are not the gods of the Internet. It is not our reponsibility to fix every problem out there, but neither do we have to sit on our hands when we could enable others to deal with the issue.
Certainly. So why would we distract them with an intermediate transition to "IPv4-240+"?
I believe that people are not that stupid. The only organizations that go after the 240/4 solution space will have good reasons for doing so. We do not have a good reason to deny them that possibility.
Remember, I was not able to find any case that successfully worked;
Your investigation showed that the software appears to have an extra line of code here and there which explicitly disallows 240/4 addresses. This is easy for vendors to fix.
But we could cop out on releasing 240/4 because it's just too much work for a small benefit to a few sites on the Internet, at a huge cost to the rest of the Internet. That's not fair.
It is a trivial amount of work for the IETF to release the address space and for ARIN to add an extra question to their allocation forms "Do you want 240/4 addresses?". As for fixing code, given the level of code patching that is already done on a regular basis, removing the 240/4 blockages could also be considered a trivial level of effort. After that, it is not a public problem any more, and those of us who do not want or need 240/4 addresses can ignore it.
I'm fine with that, especially since it appears that implementing "IPv4-240+" will incur even more serious money for every participating network on the Internet, in upgrades, adminitrative time and effort, etc.
There are only two reasons that we would do such an upgrade. First, if it is bundled up in a patch release with other stuff. And secondly if a customer requests it. The cost is effectively zero in the first case, and in the second case it will be covered by revenue.
We should do everything we can to remove roadblocks which would cause IPv4 to run out sooner,
Where practical. This ... isn't.
What is impractical with asking the IETF to revise an RFC? What is impractical in asking ARIN to add a question to their forms just as they have already done for 32-bit AS numbers? What is impractical in asking vendors to remove the code blocks in their next patch release cycle?
And this ... would cause some people to delay IPv6. So it's bad.
IPv6 is not a universal good. The Internet is far more complex with far more dark corners than you realize. But for the owners of those dark corners it makes economic sense so why should anyone try and convert them to the one true Internet architecture? --Michael Dillon
On 18 Oct 2007, at 09:34, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
Okay, this has descended to a point where we need some fact injection.
You get a D on those facts because you did not review the "literature", did not attempt reasonable coverage of the problem space, and did not investigate whether or not there were other versions of the software that have been patched to support 240/4.
step awaaaay from the crack pipe... Joe's facts were excellent. I read his email and thought "wow, this will kill this thread for sure" why on earth would you want to go and hack this stuff together, knowing that it WILL NEVER WORK so, as using these IPs publically isnt feasible why bother privately. you may as well use RFC1918 or IPv6. the latter whilst not without issues is at least being rolled out as part of a series of standards that are 10+yrs old i am really struggling with some of the logic being given here. more specifically the omissions in that logic are glaring.
not attempt to engineer a solution that will work for everybody .. not our reponsibility to fix every problem out there .. I believe that people are not that stupid. .. We do not have a good reason to deny them that possibility. .. This is easy for vendors to fix. .. It is a trivial amount of work for the IETF to release the address space .. removing the 240/4 blockages could also be considered a trivial level of effort. .. those of us who do not want or need 240/4 addresses can ignore it. .. The cost is effectively zero in the first case, .. why should anyone try and convert them to the one true Internet architecture?
i think you are somewhat deluded. Steve
On Thu, 18 Oct 2007, Stephen Wilcox wrote:
You get a D on those facts because you did not review the "literature", did not attempt reasonable coverage of the problem space, and did not investigate whether or not there were other versions of the software that have been patched to support 240/4.
step awaaaay from the crack pipe...
I almost wrote a message similar to Joe's (actually did, and then canceled it). I think (realy hope) that there's a misunderstanding here about exactly what 240/4 space would be used for. I think Michael's point is that it can be allocated as "unique space for internal use". i.e. kind of like 1918 space, but you know your slice of 240/4 is only used on your network[1]. For that purpose, it's fine, as long as you determine that all your gear allows it. If anyone really thinks it can be announced into the global routing table and expected to function, I'm afraid they've swallowed the crack pipe so far down that this thread is pointless for them. Too many devices will never (can never[2]) be upgraded and are unlikely to go away in the forseeable future. You just can't expect 240/4 (regardless of how trivial the code change would be) to ever work as globally & reliably as people expect the internet to work. I could see bits of 240/4 perhaps being of use to large cable companies for whom there just isn't enough 1918 space to address all their CPE gear...and/or they really want unique addressing so that if/when networks merge IP conflicts are avoided. 1) As much as this can ever be known...you can't stop random IP squatters from picking random IP space out of their hats for use as "private" networks behind NAT. Eventually, they realize some bit of the internet is unreachable...because it's their LAN. The various squatters using 1/8 and the other "not-yet-allocated" /8s will all get the rude awakenings they deserve in time. 2) Anyone care to guess how much network gear is deployed that either won't or can't be upgraded? i.e. Old cisco gear without the RAM and/or flash to handle a newer code train...the old one in use long since unsupported, or gear from vendors that no longer exist? As long as this stuff generally works, nobody's likely to replace it. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 10/18/07 12:53 PM, "Jon Lewis" <jlewis@lewis.org> wrote:
I could see bits of 240/4 perhaps being of use to large cable companies for whom there just isn't enough 1918 space to address all their CPE gear...and/or they really want unique addressing so that if/when networks merge IP conflicts are avoided.
I do work for one of those "large cable companies" and no, 240/4 is not useable for us either for the exact same reasons that you pointed out to explain why 240/4 will not work in public space: there are just too many devices that can't easily be upgraded. - Alain.
On 10/18/07, Alain Durand <alain_durand@cable.comcast.com> wrote:
On 10/18/07 12:53 PM, "Jon Lewis" <jlewis@lewis.org> wrote:
I could see bits of 240/4 perhaps being of use to large cable companies for whom there just isn't enough 1918 space to address all their CPE gear...and/or they really want unique addressing so that if/when networks merge IP conflicts are avoided.
I do work for one of those "large cable companies" and no, 240/4 is not useable for us either for the exact same reasons that you pointed out to explain why 240/4 will not work in public space: there are just too many devices that can't easily be upgraded.
- Alain.
Alain, Correct me if I'm wrong, but Comcast started moving to IPv6 addressing *because* they ran out of 10. space. My 0.02: Hacking together IPv4 solutions involving retasking previously reserved address space simply delays the inevitable exhaustion of said address space. -brandon
On 10/18/07 2:17 PM, "Brandon Galbraith" <brandon.galbraith@gmail.com> wrote:
Alain,
Correct me if I'm wrong, but Comcast started moving to IPv6 addressing *because* they ran out of 10. space.
Absolutely. I made the point earlier, making 240/4 work is about the same order of magnitude as moving to IPv6. Not worth it for us. - Alain.
Consider an auto company network. behind firewalls and having thousands and thousands of robots and other factory floor machines. Most of these have IPv4 stacks that barely function and would never function on IPv6. One company estimated that they needed 40 million addresses for this purpose. Cutler On Oct 18, 2007, at 2:53 PM, Jon Lewis wrote:
2) Anyone care to guess how much network gear is deployed that either won't or can't be upgraded? i.e. Old cisco gear without the RAM and/or flash to handle a newer code train...the old one in use long since unsupported, or gear from vendors that no longer exist? As long as this stuff generally works, nobody's likely to replace it.
James R. Cutler james.cutler@consultant.com
Consider an auto company network. behind firewalls and having thousands and thousands of robots and other factory floor machines. Most of these have IPv4 stacks that barely function and would never function on IPv6. One company estimated that they needed 40 million addresses for this purpose.
I guess I have a certain amount of skepticism that an auto company's robotic control network needs to have public IP addresses. In an ideal world, where it's like it was 20 years ago and we tell everyone "register some space," yeah, it was a grand idea. Now, with space running out, we need IPv6 for that, and in ten years, all those little robots will begin to find themselves having their controller boards replaced. There may not be a perfect path forward for them, but it seems likely that they can actually deal with the problem in suboptimal ways until they're actually capable of IPv6. It is in no way thrilling, but it doesn't seem likely that IPv4-240+ is going to be a grand solution for devices where the IP stacks are already admittedly barely functional, or that public IP addresses are necessary, in which case there's a certain amount of freedom to recycle as much of the existing IP space as is needed. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Consider an auto company network. behind firewalls and having thousands and thousands of robots and other factory floor machines. Most of these have IPv4 stacks that barely function and would never function on IPv6. One company estimated that they needed 40 million addresses for this purpose.
I guess I have a certain amount of skepticism that an auto company's robotic control network needs to have public IP addresses.
Of course they don't need public addresses, but they do need to have non-private globally unique IP addresses. And RFC 2050 does allow such companies to go to an RIR and get an allocation of globally unique IPv4 addresses. You may not have noticed it, but IP addresses are *NOT* Internet addresses, they are internet-protocol addresses, and can be used on or off the Internet wherever IP stacks are used. --Michael Dillon
I think Michael's point is that it can be allocated as "unique space for internal use". i.e. kind of like 1918 space, but you know your slice of 240/4 is only used on your network[1]. For that purpose, it's fine, as long as you determine that all your gear allows it.
Not quite. I don't want to see 240/4 space considered to be like RFC 1918 space in any way shape or form. I just want it available for use between consenting partners which is why I suggest that the RIRs only give it to people who ask for it. Eventually I expect that some ISPs will support this due to customer demand and because it isn't that hard to install the patches required in routers. Anyone who doesn't want to support it need not do anything because the packets will fall on the floor as soon as they hit a router that doesn't support 240/4 addresses. Depending on how the IPv6 transition pans out, there might be a day when 240/4 addressing is widely supported on the Internet. Or there might not. I would just like to see the "reserved" status removed for 240/4 because it is no longer appropriate or necessary.
If anyone really thinks it can be announced into the global routing table and expected to function, I'm afraid they've swallowed the crack pipe so far down that this thread is pointless for them. Too many devices will never (can never[2]) be upgraded and are unlikely to go away in the forseeable future.
Agreed. Routing between consenting networks is not the same as universal routing (if that even exists anymore). Unfortunately, many people do not understand that Internet connectivity is not an all-or-nothing proposition. There are many extranets that function using only a small group of certified ISPs, for instance.
I could see bits of 240/4 perhaps being of use to large cable companies for whom there just isn't enough 1918 space to address all their CPE gear...and/or they really want unique addressing so that if/when networks merge IP conflicts are avoided.
I think that RFC 1918 exhaustion is a separate issue and can only be solved by setting aside another /8 for RFC 1918 space. Either take 125/8 or else see if Softbank Japan is willing to allow 126/8 to be set aside for that purpose.
1) As much as this can ever be known...you can't stop random IP squatters from picking random IP space out of their hats for use as "private" networks behind NAT. Eventually, they realize some bit of the internet is unreachable...because it's their LAN.
Not necessarily. In many cases they only want to reach a subnet of the Internet so they never see the unreachability problem. Or they don't route packets into or out of the public Internet and use split-horizon DNS.
2) Anyone care to guess how much network gear is deployed that either won't or can't be upgraded? i.e. Old cisco gear without the RAM and/or flash to handle a newer code train...the old one in use long since unsupported, or gear from vendors that no longer exist? As long as this stuff generally works, nobody's likely to replace it.
That's why we will see IPv4 in widespread use for at least the next 20 years. --Michael Dillon
why on earth would you want to go and hack this stuff together, knowing that it WILL NEVER WORK
Because I have read reports from people whose technical expertise I trust. They modified the TCP/IP code of Linux and FreeBSD and were able to freely use 240/4 address space to communicate between machines. This means that IT WILL WORK. The reports stated that the code patch was simple because it involved simply removing a line of code that disallowed 240/4 addresses. This demonstrates that enabling 240/4 is a very simple technical issue. The only real difficulty here is getting the right people to act on it. Companies like Cisco don't even need to wait for the IETF in order to implement a command like ip class-e as long as they ship it with a default of no ip class-e --Michael Dillon
Guys, this thread has gone over 50 posts, and doesn't seem to want to end. By now, everyone has had a chance to advance their argument (at least once), and we are just going in circles, increasing noise and not contributing to signal. I'd like to summarize arguments advanced - and if you don't have something new (not listed here) to say, can you please avoid posting to this thread? If you disagree with me, please take it to nanog-futures. Summary of arguments: In favor of experimental use only: Alain Durand: at your own risk, this stuff can blow up your network In favor of private use: Randy Bush: if it works for you, why mark it experimental Dillon: why shouldn't people use it if they can In favor of no use at all: Joe Greco: "it doesn't work now (today) on current-generation OSes, there is no chance to get it to work in any shape of form by the time v4 space is exhausted". Steve Wilcox: "it will never work" Mixed: Daniel Senie: Allocate some as private, reserve rest as 'allocatable' once vendors get the gear fixed to accomodate those who use as private Additional points: David Ulevitch: If it is ever designated rfc1918, it cannot ever become public. Many: It will buy us some time before v4 address space is exhausted, and much less painful than v6 deployment Many: Old gear cannot be v6-enabled, but it can be 240-enabled Dillon: This is not our decision, this is IETF/IANA decision. -alex [mlc chair]
Did you all miss this post? Thanks. Alex Pilosov wroteth on 10/18/2007 3:26 PM:
Guys, this thread has gone over 50 posts, and doesn't seem to want to end.
By now, everyone has had a chance to advance their argument (at least once), and we are just going in circles, increasing noise and not contributing to signal.
I'd like to summarize arguments advanced - and if you don't have something new (not listed here) to say, can you please avoid posting to this thread?
If you disagree with me, please take it to nanog-futures.
Summary of arguments:
In favor of experimental use only: Alain Durand: at your own risk, this stuff can blow up your network
In favor of private use: Randy Bush: if it works for you, why mark it experimental Dillon: why shouldn't people use it if they can
In favor of no use at all: Joe Greco: "it doesn't work now (today) on current-generation OSes, there is no chance to get it to work in any shape of form by the time v4 space is exhausted". Steve Wilcox: "it will never work"
Mixed: Daniel Senie: Allocate some as private, reserve rest as 'allocatable' once vendors get the gear fixed to accomodate those who use as private
Additional points: David Ulevitch: If it is ever designated rfc1918, it cannot ever become public.
Many: It will buy us some time before v4 address space is exhausted, and much less painful than v6 deployment
Many: Old gear cannot be v6-enabled, but it can be 240-enabled
Dillon: This is not our decision, this is IETF/IANA decision.
-alex [mlc chair]
why on earth would you want to go and hack this stuff together, knowing that it WILL NEVER WORK
Because I have read reports from people whose technical expertise I trust. They modified the TCP/IP code of Linux and FreeBSD and were able to freely use 240/4 address space to communicate between machines. This means that IT WILL WORK.
The reports stated that the code patch was simple because it involved simply removing a line of code that disallowed 240/4 addresses.
This demonstrates that enabling 240/4 is a very simple technical issue. The only real difficulty here is getting the right people to act on it.
Companies like Cisco don't even need to wait for the IETF in order to implement a command like ip class-e as long as they ship it with a default of no ip class-e
I don't even know where to begin. Well, maybe here: "The only real difficulty here is getting the right people to act on it." That neatly sums up the problem. When you can round up: 1) All the programmers for all the tens of thousands of different IP devices that are out on the market, have them dig up the source code for these devices (some of which may have been a few employers ago), and you get them all to agree to post updated copies of their firmware, which might be problematic for those companies that went T.U., You still have the giant problem of: 2) Getting over 100 MILLION users to all update the BILLIONS of devices that are out there with that firmware. Once you have a game plan for getting those hundred million people to do this, then we may have something to talk about. Until then, not so much. Your "people whose technical expertise <you> trust" clearly figured out that there are cases where you can make moving an IPv4-240+ packet work. Anyone can make that happen. However, they apparently failed to impress upon you that what they were (hopefully) saying is that "enabling IPv4- 240+ on a single device is a very simple technical issue." Deploying it on a wider scale ... not so simple. What kind of customer would actively solicit an IP address assignment that won't reach random segments of the Internet? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Thu, Oct 18, 2007 at 11:00:42PM +0100, michael.dillon@bt.com wrote:
why on earth would you want to go and hack this stuff together, knowing that it WILL NEVER WORK
Because I have read reports from people whose technical expertise I trust. They modified the TCP/IP code of Linux and FreeBSD and were able to freely use 240/4 address space to communicate between machines. This means that IT WILL WORK.
The reports stated that the code patch was simple because it involved simply removing a line of code that disallowed 240/4 addresses.
Actually, to do the job right, you have to change a handful of conditionals in about five different files in the Linxux kernel: in.h (really just cleanup to remove unused macros), devinet.c, fib_frontend.c, ipconfig.c, and route.c. Attached are the diffs for a 2.6 kernel (implemented and tested on an Ubuntu 7.04 system) and for a 2.4 kernel (implemented and tested on a Linksys WRT45GL running OpenWRT whiterussian 0.9). As mentioned in an earlier message, Mac OSX, at least the version that came with a Powerbook G4 that I have, will accept a 240/4 address without any modifications - I used it to test the Linux patches. There does appear to be a one line change needed to FreeBSD and/or OSX for it to act as a router. Have fun. --Vince
Okay, this has descended to a point where we need some fact injection.
You get a D on those facts because you did not review the "literature", did not attempt reasonable coverage of the problem space, and did not investigate whether or not there were other versions of the software that have been patched to support 240/4.
And what's your grade, because you aren't displaying a realistic worldview that takes into account that there are tons (tons!) of sites where these "patched" versions of software simply will never run. We've been UNABLE to get the vast majority of customers to automatically patch their Windows installs. There are still deployed fleets of Cobalt Raq's. There's a TON of problems on both the client and server sides of this. I'm not sure what magic "literature" I'm supposed to review which describes how this will all magically fix itself. I have no idea why you are unable to see the extent of the problem space. I am confused as to why you would think that patches make a difference, when we're talking about a need to patch billions of devices. That you might someday be able to get an IP packet from one 240.* net to another halfway around the globe isn't unthinkable. You can patch devices under your control and make clients and servers under your control work. You just won't get the global interoperability that is what the Internet is famous for.
We cannot engineer a set of solutions that will work for everybody.
Therefore, you want to engineer a solution that'll work for mostly nobody?
No, therefore we should not attempt to engineer a solution that will work for everybody but merely remove the barriers that allow others to engineer solutions for their situation.
Unless you have some magic wand that can update a few billion IPv4-capable devices to be IPv4-240+ capable, it would appear that you have no method to remove these barriers. That would seem to be a showstopper bug.
So, what's your game plan to replace all these broken IPv4 stacks?
Again, we are not the gods of the Internet. It is not our reponsibility to fix every problem out there, but neither do we have to sit on our hands when we could enable others to deal with the issue.
There's a vast difference between enabling others to deal with an issue, and requiring everyone else on the Internet to change something for your convenience to fix your issue so that you don't break catastrophically.
Certainly. So why would we distract them with an intermediate transition to "IPv4-240+"?
I believe that people are not that stupid. The only organizations that go after the 240/4 solution space will have good reasons for doing so. We do not have a good reason to deny them that possibility.
The problem, then, is that if they go after that space, and nobody else does, then they don't reach about.... oh... well, by my (admittedly small) sample set, 100% of the Internet. Let's be generous and say that even 90% of the Internet is upgraded, somehow. Does 10% unreachability sound good? How do the customers you put onto that address space feel about not being able to reach (at least many parts of) the rest of the 'net?
Remember, I was not able to find any case that successfully worked;
Your investigation showed that the software appears to have an extra line of code here and there which explicitly disallows 240/4 addresses. This is easy for vendors to fix.
When the vendor still exists, and the user is willing to upgrade, and the user actually does upgrade, but in many cases, that's not true.
But we could cop out on releasing 240/4 because it's just too much work for a small benefit to a few sites on the Internet, at a huge cost to the rest of the Internet. That's not fair.
It is a trivial amount of work for the IETF to release the address space and for ARIN to add an extra question to their allocation forms "Do you want 240/4 addresses?". As for fixing code, given the level of code patching that is already done on a regular basis, removing the 240/4 blockages could also be considered a trivial level of effort. After that, it is not a public problem any more, and those of us who do not want or need 240/4 addresses can ignore it.
Yes, but then when you get allocated space out of 240/4, what's going to happen is that one of your customers is going to try to reach my web site, and when your customer contacts you, you're going to tell them that I'm broken, because heaven knows it's not your problem . So then I get to be called broken, and I'm coerced into doing something to upgrade services, or, worse, I have no idea because I'm just a guy running a web site, and therefore I don't (or maybe even can't) do anything.
I'm fine with that, especially since it appears that implementing "IPv4-240+" will incur even more serious money for every participating network on the Internet, in upgrades, adminitrative time and effort, etc.
There are only two reasons that we would do such an upgrade.
Mmm.
First, if it is bundled up in a patch release with other stuff.
Oh. So, um, like, you're talking about Flag Day! Party like it's 1983?
And secondly if a customer requests it. The cost is effectively zero in the first case, and in the second case it will be covered by revenue.
That seems very self-centered. There's no cost to anyone else to have to make this work? Really? Because the minute the words "you have to patch" utter forth from your mouth telling me how I have to patch my stuff, that's taking time away from me, which I value in dollars.
We should do everything we can to remove roadblocks which would cause IPv4 to run out sooner,
Where practical. This ... isn't.
What is impractical with asking the IETF to revise an RFC?
Asking the IETF to revise an RFC is not impractical. Asking the IETF to revise an RFC, however, has no effect on the installed base. We have all kinds of RFC's out there for services that flopped and failed and no longer are in use anywhere. The existence of an RFC is fairly meaningless. The BEST RFC's document things that either currently /are/, or that /could be/, where we're trying to guide new creation. They don't try to /change/ the installed base in some radical way. Actually, though, I have a better solution. Let's ask the IETF to revise an RFC, and define the first octet of an IPv4 address as being from 0- 65535. That's asking the IETF to revise an RFC, too, such request being just as practical as what you suggest, and yet I'd say that the overall solution is just as likely to work well as IPv4-240+. It'd probably also solve the transition to IPv6 issue; we wouldn't need to.
What is impractical in asking ARIN to add a question to their forms just as they have already done for 32-bit AS numbers? What is impractical in asking vendors to remove the code blocks in their next patch release cycle?
Because it's not backwards compatible in the least, and it is a major distraction from making forward progress. You want this? Run it on your network. Have fun. Once you put it on the public Internet, it's not going to work. Have more juicy funness.
And this ... would cause some people to delay IPv6. So it's bad.
IPv6 is not a universal good.
No, but it's a path forward that doesn't rely on all of the badness we have today.
The Internet is far more complex with far more dark corners than you realize.
I'm not sure that's true. I'm aware of a *lot* of dark corners that have a *huge* amount of stuff and I can tell you that the *vast* *majority* of it will not be upgraded to handle IPv4-240+. That there may be more dark corners above and beyond the ones I am actually aware of is a fact that I'm also aware of; my inability to quantify all possible dark corners doesn't mean that there's some magic dark corner where all the dark corners I'm aware of will be transformed to be IPv4-240+ capable.
But for the owners of those dark corners it makes economic sense so why should anyone try and convert them to the one true Internet architecture?
Possibly because they want to be connected to it? Just a thought. If you want to be part of the community, it is probably a good idea to go along with the basic rules agreed upon by the community. If it makes economic sense for you to use IPv4-240+ internally, by all means, allocate and NAT it. I tried that just this morning. I'm sure that given enough hammering and patching, it could be made to work for some limited use, but it's going to require a significant amount of work. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On 10/18/07 2:24 PM, "Joe Greco" <jgreco@ns.sol.net> wrote:
Actually, though, I have a better solution. Let's ask the IETF to revise an RFC, and define the first octet of an IPv4 address as being from 0- 65535. That's asking the IETF to revise an RFC, too, such request being just as practical as what you suggest, and yet I'd say that the overall solution is just as likely to work well as IPv4-240+. It'd probably also solve the transition to IPv6 issue; we wouldn't need to.
Or simply ask IANA to open up 256/5. After all, this is just an entry in a table, should be easy to do, especially if it is done on Apr 1st. ;-) - Alain.
Or simply ask IANA to open up 256/5. After all, this is just an entry in a table, should be easy to do, especially if it is done on Apr 1st. ;-)
DOH! Point: you. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Joe, On Oct 18, 2007, at 8:49 AM, Joe Greco wrote:
The ROI on the move to v6 is immense compared to the ROI on the move to v4-240+, which will surely only benefit a few.
I am told by people who have inside knowledge that one of the issues they are facing in deploying IPv6 is that an IPv6 stack + IPv4 stack have a larger memory footprint that IPv4 alone in devices that have essentially zero memory for code left (in fact, they're designed that way). Fixing devices so that they can accept 240/4 is a software fix that can be done with a binary patch and no additional memory. And there are a _lot_ of these devices. Regards, -drc
Joe, On Oct 18, 2007, at 8:49 AM, Joe Greco wrote:
The ROI on the move to v6 is immense compared to the ROI on the move to v4-240+, which will surely only benefit a few.
I am told by people who have inside knowledge that one of the issues they are facing in deploying IPv6 is that an IPv6 stack + IPv4 stack have a larger memory footprint that IPv4 alone in devices that have essentially zero memory for code left (in fact, they're designed that way). Fixing devices so that they can accept 240/4 is a software fix that can be done with a binary patch and no additional memory. And there are a _lot_ of these devices.
Sure, I agree there are. How does that number compare to the number of devices which can't or won't be upgraded to IPv4-240+? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Joe, On Oct 18, 2007, at 3:22 PM, Joe Greco wrote:
Fixing devices so that they can accept 240/4 is a software fix that can be done with a binary patch and no additional memory. And there are a _lot_ of these devices.
Sure, I agree there are. How does that number compare to the number of devices which can't or won't be upgraded to IPv4-240+?
I'm not sure what the problem is. If a machine isn't upgraded to support 240/4, then you can't talk to it. I would imagine an ISP could (for example) ensure its routers could handle 240/4 and then configure those routers to use 240/4 for their loopback addresses, thereby reducing that ISP's need of "regular" space (be it public or private). If someone is suggesting IANA allocate 240/4 to the RIRs as "regular" /8s for subsequent allocations to ISPs or end users, they're deeply confused. Regards, -drc
Stephen Wilcox wrote:
unfortunately i think this is a non-started for all except private deployments
the other point as was mentioned later in the thread is that this buys you very little in terms of time before v4 is gone.
I can see a reasonable amount of demand for 240/4 with carriers in a post-v4 exhaustion world. This would reduce the issues of having overlapping RFC1918 space (e.g. multiple VRFs of 10/8) and allow for simple contiguous networks in private clouds. A particularly interesting example is for numbering IPTV STBs. This may also be useful for service providers wanting to do effectively 'site NAT' when they can't gain any more v4 resource, but still need to get v4 clients access to the v4 net somehow. Again this prevents duplicate or overlapping addresses internally. I definitely support handing 240/4 into private network use; but as many have pointed out it is too tainted for public Internet use. While the RIRs never guaranteed reachability, I think this would be taking it a little too far. aj.
participants (29)
-
Adrian Chadd -
Alain Durand -
Alastair Johnson -
Alex Pilosov -
Andreas Ott -
Bill Stewart -
Brandon Galbraith -
Church, Charles -
Daniel Karrenberg -
Daniel Senie -
David Barak -
David Conrad -
David Ulevitch -
Florian Weimer -
James R. Cutler -
jared mauch -
Joe Greco -
Jon Lewis -
Justin M. Streiner -
Leo Vegoda -
michael.dillon＠bt.com -
Pekka Savola -
Randy Bush -
Rob Evans -
S. Ryan -
Stephen Sprunk -
Stephen Wilcox -
Valdis.Kletnieks＠vt.edu -
Vince Fuller