Re: quietly....
On Feb 1, 2011, at 4:31 AM, Jeremy wrote: Has there been any discussion about allocating the Class E blocks? If this doesn't count as future use what does? (Yes, I realize this doesn't *fix* the problem here) yes. The bottom line is that it only gives you a few more /8s, and every host and router in the net has to be updated to accept them. Doesn't actually solve the problem.
Re: quietly....
On 1 feb 2011, at 4:55, Jimmy Hess wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. IPv4 is very dead in the sense that it's not going to go anywhere in the future. The rest is just procrastination.
Re: quietly....
On Jan 31, 2011, at 10:43 PM, George Bonser wrote: 3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. jms If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it. If they could do code updates on the CPE, then, they could use RFC-1918. The problem is that code-updating that much CPE is, well, impractical to say the least. Owen
Re: quietly....
On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote: On 1 feb 2011, at 4:55, Jimmy Hess wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. IPv4 is very dead in the sense that it's not going to go anywhere in the future. The rest is just procrastination. taking the long view - your statement applies equally to IPv6. of course YMMV --bill
Re: quietly....
On Jan 31, 2011, at 11:41 PM, George Bonser wrote: There are negligible benefits as far as I can tell from the vantage points of end systems to creating new private scope ipv4 regions at this late date. Here, yes. In other places, maybe there are other factors. I am not saying I favor such a thing, just going through the exercise of thinking through how to deal with one when/if it appears and recognizing that such a thing could happen. Imagine The Repressive Republic of Slobovia wants to absolutely control who talks to whom over that country's internet infrastructure (or, more accurately, who doesn't talk to whom). That is a fairly easy way of doing it. They absolutely control the entire addressing spectrum and if desired, nothing leaks. Now that isn't to say people don't find ways out, as they always will. That's a really good reason NOT to provide this ability. There's no advantage to the global internet for facilitating such a thing. Owen
Re: quietly....
I think the ship has sailed for the class E /8s. Using them will require significant effort and that effort, both time and money, is better spent on deploying IPv6. regards Carlos On 2/1/11 9:45 AM, Owen DeLong wrote: On Jan 31, 2011, at 10:43 PM, George Bonser wrote: 3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. jms If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it. If they could do code updates on the CPE, then, they could use RFC-1918. The problem is that code-updating that much CPE is, well, impractical to say the least. Owen
Re: quietly....
On Feb 1, 2011, at 3:53 AM, bmann...@vacation.karoshi.com wrote: On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote: On 1 feb 2011, at 4:55, Jimmy Hess wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. IPv4 is very dead in the sense that it's not going to go anywhere in the future. The rest is just procrastination. taking the long view - your statement applies equally to IPv6. of course YMMV --bill I disagree. I think there is little, if any, innovation that will continue to be put into IPv4 hence forth. I think there will be much innovation in IPv6 in the coming years. Owen
Re: quietly....
On 1 feb 2011, at 13:01, Owen DeLong wrote: IPv4 is very dead in the sense that it's not going to go anywhere in the future. taking the long view - your statement applies equally to IPv6. IPv6 has many places to go in the future. Of course the future is long, and there will be a point when IPv6 is no longer what's needed. But we're nowhere close to that point now. I disagree. I think there is little, if any, innovation that will continue to be put into IPv4 hence forth. I think there will be much innovation in IPv6 in the coming years. I'm afraid it may be the other way around: lots of IPv4 innovation just so IPv6 can be avoided a few more years.
Re: quietly....
s/IPv6/ATM/g Just saying... Adrian On Tue, Feb 01, 2011, Iljitsch van Beijnum wrote: On 1 feb 2011, at 13:01, Owen DeLong wrote: IPv4 is very dead in the sense that it's not going to go anywhere in the future. taking the long view - your statement applies equally to IPv6. IPv6 has many places to go in the future. Of course the future is long, and there will be a point when IPv6 is no longer what's needed. But we're nowhere close to that point now. I disagree. I think there is little, if any, innovation that will continue to be put into IPv4 hence forth. I think there will be much innovation in IPv6 in the coming years. I'm afraid it may be the other way around: lots of IPv4 innovation just so IPv6 can be avoided a few more years. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Re: quietly....
In message AANLkTinrhPYXvtS5wtA0PuhtEmi3f4tN9J5KOCBF1a=5...@mail.gmail.com, Mart in Millnert writes: Jeremy, I have not heard of any IP stack that is built to accept 240/4. Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think about all routers, including CPE:s, out there. The logic goes: You are many orders of magnitudes more likely to get v6 off the ground, than 240/4 or 224/4 as unicast IPv4. 224/3 will never be very usable as public v4 space since every non-upgraded host on the Internet will be unable to send packets to them, eg, for every additional host you introduce with these addresses the worse the reachability situation becomes for the v4 Internet. Notably, this is the inverse of what happens when you introduce more hosts with native, proper IPv6, in the IPv6-Internet. Cheers, Martin The lines of code to make 240/4 work as unicast loc to add IPv6 and will usually fit into the amount of flash already on the CPE box. It's a surgical change rather than add a whole new stack. It might even be possible to convice the CPE vendors to make new images for old hardware. You also don't need to make it work with the whole world. Just between the CPE and the LSN and/or 6rd border router. 15 /8's (leave 255 alone) is a lot of space for a ISP to use. The CPE would signal support (e.g. a DHCP option) and the ISP would only return class E addresses if it was sure the path was clean. Those that need a public address would clear the option. It would default on. With luck the asic will support unicast in 240/4 space so you get fast path for IPv6 using 6rd on IPv4 only routers. This model also allows it to be deployed incrementally. This is a software upgrade rather than a hardware upgrade. If you constrain the problem space it becomes more managable problem. The question is do you want to have to deploy the same address space multiple times or is it worth a little bit of co-ordinated effort to do this. IPv4 + IPv6 [NAT/6RD] E space + public IP4 [NAT/6RD] RFC 1918 space + IPv6 It can also be used to deliver IPv6 only over 6rd. IPv4 + IPv6 [AFTR/6RD] E space [B4/6RD] RFC 1918 + IPv6 (double encap) IPv4 + IPv6 [NAT64/6RD] E space [6RD] IPv6 (single encap) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
On 1/31/2011 10:29 PM, Owen DeLong wrote: 1. Layering NAT beyond 2 deep (one provider, one subscriber) doesn't help. yep 2. NAT444 will break lots of things that work in current NAT44. To be honest, ds-lite, despite being single layer still breaks most things that a NAT44 with upnp won't. 3. Users subjected to this environment after experiencing the limited brokenness of NAT44 or full access to the internet will not be happy. Neither would an engineer, which is why we have real IPs at our house. :) 4. Maintaining NAT444 environments will be a support headache and a costly arms race of deployments and management. Even maintaining dual stack is costly. NAT444 just makes it worse. 5. IPv6 will cost a lot less than NAT444 as soon as they can get their subscribers fully deployed and is a much more desirable alternative. Yep. Once the NSPs get their stuff done and we have decent routing paths, the eyeballs will either already be done or quickly behind them, and then the content can start switching over without the fears they currently have. Jack
Re: quietly....
On Feb 1, 2011, at 9:50 AM, Jack Bates wrote: On 1/31/2011 10:29 PM, Owen DeLong wrote: 1. Layering NAT beyond 2 deep (one provider, one subscriber) doesn't help. yep 2. NAT444 will break lots of things that work in current NAT44. To be honest, ds-lite, despite being single layer still breaks most things that a NAT44 with upnp won't. 3. Users subjected to this environment after experiencing the limited brokenness of NAT44 or full access to the internet will not be happy. Neither would an engineer, which is why we have real IPs at our house. :) 4. Maintaining NAT444 environments will be a support headache and a costly arms race of deployments and management. Even maintaining dual stack is costly. NAT444 just makes it worse. 5. IPv6 will cost a lot less than NAT444 as soon as they can get their subscribers fully deployed and is a much more desirable alternative. Yep. Once the NSPs get their stuff done and we have decent routing paths, the eyeballs will either already be done or quickly behind them, and then the content can start switching over without the fears they currently have. Honestly, if you can't get native wholesale IP, you are buying from the wrong carriers. - Jared
Re: quietly....
On Feb 1, 2011, at 7:01 AM, Owen DeLong wrote: On Feb 1, 2011, at 3:53 AM, bmann...@vacation.karoshi.com wrote: On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote: On 1 feb 2011, at 4:55, Jimmy Hess wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. IPv4 is very dead in the sense that it's not going to go anywhere in the future. The rest is just procrastination. taking the long view - your statement applies equally to IPv6. of course YMMV --bill I disagree. I think there is little, if any, innovation that will continue to be put into IPv4 hence forth. I think there will be much innovation in IPv6 in the coming years. I think that this is what will finally drive true v6 adaptation (as opposed to having it as some sort of super NAT). As v6 innovation continues, v4 will be seen as something obsolete that needs constant work (and v4 innovation will be more and more about patching it to work and keep up with v6). Regards Marshall Owen
Re: quietly....
On 2/1/2011 9:13 AM, Marshall Eubanks wrote: As v6 innovation continues, v4 will be seen as something obsolete that needs constant work (and v4 innovation will be more and more about patching it to work and keep up with v6). If it continues. The sad thing is, transition would have been a lot smoother if not for IETF politics. You can't have these features! It's not IPv4! They would work perfectly fine, but we don't want you to do that! I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. Jack
Re: quietly....
On 2/1/2011 8:53 AM, Jared Mauch wrote: Honestly, if you can't get native wholesale IP, you are buying from the wrong carriers. I agree. I did up the $5 million budget to light dwdm ring with 8x10GE to Dallas where I could connect to any provider I wanted, but it was unfortunately declined. However, that's not the point. The point is that IPv6 routing paths through the largest networks are not the same as IPv4 routing paths. There are still many unoptimized routes and even a lack of peering. General latency and bandwidth availability for IPv6 is a QOS nightmare compared to IPv4. The weirdest one I came across is that, at one point, I had the best connectivity with limelight (for netflix streams) by sending packets out L3, and having them return via a HE tunnel. It was, of course, well below IPv4 standards. Jack
Re: quietly....
On 1 feb 2011, at 16:21, Jack Bates wrote: I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? If you like NAT IPv4 is the place to be, it'll only get more and more.
Re: quietly....
On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote: On 1 feb 2011, at 16:21, Jack Bates wrote: I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? Bigger addresses. People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. Telling them they have to do it your way because their way is stupid is just going to keep them from changing and increases a chance of a NATernet. -Dave
Re: quietly....
On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote: What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? If you like NAT IPv4 is the place to be, it'll only get more and more. It's argument like this that has lead to this moment. Instead of discussing how can the next generation addressing scheme support the needs of Internet consumers today and tomorrow we tell people if you don't like it, use v4 Guess what? We're still using v4. ..david -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: quietly....
On 2/1/2011 3:10 PM, Randy Carpenter wrote: - Original Message - On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote: On 1 feb 2011, at 16:21, Jack Bates wrote: I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? Bigger addresses. People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. Telling them they have to do it your way because their way is stupid is just going to keep them from changing and increases a chance of a NATernet. -Dave So, we should just have no rules or standards at all, and just let people do whatever they want. How well would that work? We should, and do, have rules and standards for how networks communicate with each other. We can, and should, publish advice on how a network can be built to work properly, internally and externally. We should not say, you must run your internals the way we think a network should be run internally. Every network operator's network is their concern, and making it work is their responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. -Dave
Re: quietly....
On 02/01/2011 10:08 AM, david raistrick wrote: On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote: What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? If you like NAT IPv4 is the place to be, it'll only get more and more. It's argument like this that has lead to this moment. Instead of discussing how can the next generation addressing scheme support the needs of Internet consumers today and tomorrow we tell people if you don't like it, use v4 Guess what? We're still using v4. ..david We're still using v4 because we can, because there has been no compelling business case to justify spending time on something that isn't necessary just right now, especially given the not insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either. We can all sit here and say Hey we're running out of addresses, we must switch but until we've run out you're not going to convince the large majority of operators, who lets face it are traditionally lazy^W^W cautious people , to do anything. Paul
Re: quietly....
On 1 feb 2011, at 21:03, Dave Israel wrote: People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. The problem is that their stupidity impacts ME. If I want to talk to Microsoft from behind a 1500 byte MTU link: too bad, not going to happen. They stupidly send packets with DF=1 but filter incoming packet too big messages. So I'm all in favor of the IETF blocking stupidity whenever possible.
Re: quietly....
On Tue, Feb 01, 2011 at 10:27:45AM -1000, Paul Graydon wrote: insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either. Paul, You're speaking for yourself here, as some of us have hosts with no A record. If your business requires connectivity, you're not going to have a choice, so you might as well get with the program. It's less about making a business case for v6, and more about risk management at this point. It's not as if we haven't had 15 years to get it together... Cheers, --msa
Re: quietly....
On Tue, 1 Feb 2011, Dave Israel wrote: responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback. -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: quietly....
On Tue, Feb 1, 2011 at 3:32 PM, Majdi S. Abbas m...@latt.net wrote: If your business requires connectivity, you're not going to have a choice, so you might as well get with the program. It's less about making a business case for v6, and more about risk management at this point. +1 Regards, Martin
Re: quietly....
On 2/1/2011 3:32 PM, Iljitsch van Beijnum wrote: On 1 feb 2011, at 21:03, Dave Israel wrote: People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. The problem is that their stupidity impacts ME. If I want to talk to Microsoft from behind a 1500 byte MTU link: too bad, not going to happen. They stupidly send packets with DF=1 but filter incoming packet too big messages. So I'm all in favor of the IETF blocking stupidity whenever possible. I completely agree that, when interoperating, you have to follow the rules, and I would (naively) hope that customers cannot reach me because of my configuration choice is sufficient incentive to fix the problem for the majority of network operators. But what I am arguing against was the stance some people take against DHCPv6, or prefix lengths longer than /64, or other internal-to-my-network, why-should-you-care choices I might make. Telling me it is dumb is fine; implementing software/hardware/protocols such that I can't do it simply because you think it is dumb is a problem. -Dave
Re: quietly....
On Tue, 1 Feb 2011, Dave Israel wrote: I completely agree that, when interoperating, you have to follow the rules, and I would (naively) hope that customers cannot reach me because of my configuration choice is sufficient incentive to fix the problem for the majority of network operators. But what I am arguing against was the stance some people take against DHCPv6, or prefix lengths longer than /64, or other internal-to-my-network, why-should-you-care choices I might make. Telling me it is dumb is fine; implementing software/hardware/protocols such that I can't do it simply because you think it is dumb is a problem. DHCPv6 can have a very valid and useful place in the overall scheme of things, in terms of managing address assignments. I've been somewhat disappointed that it's taken this long to see the light of day. jms
Re: quietly....
On Tue, 01 Feb 2011 10:27:45 -1000, Paul Graydon said: We're still using v4 because we can, because there has been no compelling business case to justify spending time on something that isn't necessary just right now, especially given the not insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either. And if you're not working on deploying IPv6 now, will you be able to survive the delay when something critical *does* come online and you need 18 months or whatever to deploy? Heck - we started deploying in Feb 1997 or so, and as I write this, MRTG is reporting that about 5% of our off-campus traffic is via IPv6 - probably due to the fact that we hit Google and Youtube that way. But we *still* have gear and software that doesn't play nice (though almost all of that is our own internal headaches and not very visible to end users - their connectivity works). pgpXAg3dBiNoU.pgp Description: PGP signature
Re: quietly....
On 02/01/2011 10:32 AM, Majdi S. Abbas wrote: On Tue, Feb 01, 2011 at 10:27:45AM -1000, Paul Graydon wrote: insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either. Paul, You're speaking for yourself here, as some of us have hosts with no A record. If your business requires connectivity, you're not going to have a choice, so you might as well get with the program. It's less about making a business case for v6, and more about risk management at this point. It's not as if we haven't had 15 years to get it together... Cheers, --msa I should emphasise I'm a sysadmin rather than a service provider, and I'm mostly speaking generically based on conversations with a number of sysadmins. I've been trying to get my service provider to sort out IPv6 for a while now (they tell me their infrastructure is ready, but they're being lazy about getting blocks sorted out) and already done as much preparation as I can with my infrastructure to ensure its ready for it. That said there are no services we use that are IPv6 only, nor are there likely to be for a while that I can tell as none of our service partners are talking about it, and nor are we getting reports of anyone unable to access our services due to lack of IPv6 on the front end. I know how ugly that sounds, I really do, but that's the way most people will see it. You have to provide incentive to make a change, and It's better rarely is enough. People won't be able to access our site sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.). People bury their heads in the sand and will continue to pretend there is nothing wrong until they're /forced/ to change. As much as it was a hideous and inaccurate article, that Fox news story that was posted on list the other day came up was great for fighting for change. The grossly inaccurate end-of-the-world text provides a good hook for getting the lumbering beast moving in the right direction. The White House's push for IPv6 amongst federal agencies is currently my best guess at what will probably see the first thing to transition to it from my perspective at work, though I sincerely hope we'll be on IPv6 long before that happens. As for when we'll switch internally? No idea.. all machines have IPv6 so some local traffic probably uses it, but most are still based on IPv4 and until I have time / money to make some other infrastructure changes will remain that way (our office environment equipment can't handle IPv6, unlike our production environment) I'm sure there are some cases with IPv6, yourself as an example, and I know an ISP I worked for in the UK had a customer several years ago who had a critical need for it, but that's still in the minority. In every case as soon as there is a business reason for it and its compelling enough people will take the time to make the transition. Paul
Re: quietly....
In message 4d4870b8.4010...@otd.com, Dave Israel writes: On 2/1/2011 3:32 PM, Iljitsch van Beijnum wrote: On 1 feb 2011, at 21:03, Dave Israel wrote: People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wa nted. The problem is that their stupidity impacts ME. If I want to talk to Microsof t from behind a 1500 byte MTU link: too bad, not going to happen. They stupid ly send packets with DF=1 but filter incoming packet too big messages. So I'm all in favor of the IETF blocking stupidity whenever possible. I completely agree that, when interoperating, you have to follow the rules, and I would (naively) hope that customers cannot reach me because of my configuration choice is sufficient incentive to fix the problem for the majority of network operators. But what I am arguing against was the stance some people take against DHCPv6, or prefix lengths longer than /64, or other internal-to-my-network, why-should-you-care choices I might make. Telling me it is dumb is fine; implementing software/hardware/protocols such that I can't do it simply because you think it is dumb is a problem. -Dave It just doesn't work with Microsoft, ATT, AOL, They make up their own rules and you have to figure them out. Microsoft set TC on DNS replies but doesn't have DNS open on TCP. Then there is the anti-spam measures which break RFC compliance. Or all the people that have GLB's that don't give correct answers to queries. How had is it to return the SOA record of the delegated zone rather than the parent zone. Some GLB vendors documentation gets this wrong. The Alexa top 100 has a 1.4% failure rate on queries (SERVFAIL, TIMEOUT to the client when NOERROR or NXDOMAIN is returned for A). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
On Feb 1, 2011, at 12:08 PM, david raistrick wrote: On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote: What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? If you like NAT IPv4 is the place to be, it'll only get more and more. It's argument like this that has lead to this moment. Instead of discussing how can the next generation addressing scheme support the needs of Internet consumers today and tomorrow we tell people if you don't like it, use v4 Guess what? We're still using v4. ..david Enjoy that. Let's see how that goes in 5-7 years. If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be. Owen
Re: quietly....
On Feb 1, 2011, at 12:36 PM, david raistrick wrote: On Tue, 1 Feb 2011, Dave Israel wrote: responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback. NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. It does not solve any other problem(s). As such, taking it away when giving you a large enough address space that there is no longer a shortage doesn't strike me as taking away a tool that solves a problem. It strikes me as giving you a vastly superior tool that solves rather than working around a problem. Owen
Re: quietly....
On Tue, 1 Feb 2011, Owen DeLong wrote: NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. It does not solve any other problem(s). Sure it does. It obfuscates internal addressing. This wasn't the original goal, but it's a feature that some groups of users have come to require. -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: quietly....
On Feb 1, 2011, at 3:38 PM, Owen DeLong wrote: NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. It does not solve any other problem(s). In all fairness, that's not really true. It just doesn't solve other problems in an optimal way. Also, NAT44 implies address oversubscription while NAT66 doesn't necessarily have such a requirement. Not that I love NAT66, but let's at least be honest about it. Cheers, -Benson
Re: quietly....
On 1 feb 2011, at 23:03, david raistrick wrote: It obfuscates internal addressing. This wasn't the original goal, but it's a feature that some groups of users have come to require. Creating a new random address every 24 hours (or more often if needed, I assume) goes a long way towards that, too. There's still proxies with IPv6, those also make everything nice and obscure, also hide your TCP seqnums and IP IDs etc.
Re: quietly....
From: Owen DeLong o...@delong.com David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be. Lack of NAT may or may not continue to be a barrier to IPv6 adoption. However, it certainly *has* been a barrier to IPv6 adoption - I have had customers tell me that explicitly, and I have no reason to doubt them.
Re: quietly....
On Feb 1, 2011, at 4:38 PM, Owen DeLong o...@delong.com wrote: NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. It does not solve any other problem(s). That's a bold statement. Especially as you said NAT and not PAT.
Re: quietly....
On 2/1/2011 2:32 PM, Majdi S. Abbas wrote: It's not as if we haven't had 15 years to get it together... And failed to do so properly. jack
Re: quietly....
On 2/1/2011 3:38 PM, Owen DeLong wrote: As such, taking it away when giving you a large enough address space that there is no longer a shortage doesn't strike me as taking away a tool that solves a problem. It strikes me as giving you a vastly superior tool that solves rather than working around a problem. Interestingly enough, there is a draft for NAT66, specifically NPTv6, but no draft for NAPTv6. So someone though it was okay to start allowing some NAT66, but everyone's still trying to fight NAPTv6, as businesses might use it. Oh noes. The other concern was perhaps home routers, but let's be honest. There is a v6-cpe-router draft, and it easily could forbid the use of NAPTv6. It's already missing most of the stuff required to make home networks work in v6 the same way they do in v4 (prefix delegation added new problems that NAT didn't have, which they still haven't solved). Jack
Re: quietly....
On Feb 1, 2011, at 2:43 PM, David Barak wrote: From: Owen DeLong o...@delong.com David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be. Lack of NAT may or may not continue to be a barrier to IPv6 adoption. However, it certainly *has* been a barrier to IPv6 adoption - I have had customers tell me that explicitly, and I have no reason to doubt them. I'm sure there are a few isolated places where IPv6 might have been adopted if it hadn't been for the fact that nobody has educated them on the alternatives. However, I'm not convinced there are very many of them. Most of the people I have had more detailed conversations with go something like this: X: We con't implement IPv6 because there's no NAT and we depend on NAT. O: Why do you depend on NAT? All it does is conserve addresses? X: We use it for address obfuscation and security. We have to meet PCI-DSS and other audit criteria. O: Well, the latest PCI-DSS doesn't require NAT. Additionally, you can get better address obfuscation with privacy addresses. All the security in NAT comes from stateful inspection. You can still do that in IPv6, you just don't rewrite the address in the packet. X: You've got an answer for everything, don't you? O: Well, I've been doing IPv6 for a few years now. It works pretty well for me and I'm really glad I don't have to deal with the problems caused by NAT. X: Well, OK, but, even if we ignore NAT, we're still not ready to do IPv6. Then we discuss their real issues stopping them from going to IPv6. So... I think there are a lot more people using NAT as an excuse than there are people that would actually implement IPv6 if we just gave them NAT. In any case, I think as they find their NATv4 environment becoming an island disconnected from the internet, they'll probably reconsider that decision. I'm OK with waiting until that time for those people to connect to IPv6. Owen
Re: quietly....
On Feb 1, 2011, at 2:09 PM, Benson Schliesser wrote: On Feb 1, 2011, at 3:38 PM, Owen DeLong wrote: NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. It does not solve any other problem(s). In all fairness, that's not really true. It just doesn't solve other problems in an optimal way. Also, NAT44 implies address oversubscription while NAT66 doesn't necessarily have such a requirement. Not that I love NAT66, but let's at least be honest about it. Cheers, -Benson Perhaps a better way to put it is: There are better solutions in IPv6 to any of the problems NAT44 is alleged to solve, regardless of whether you are talking about overloaded NAT44 (which some people refer to as PAT) or any other form of NAT. Owen
Re: quietly....
On Tue, 2011-02-01 at 13:38 -0800, Owen DeLong wrote: NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. The side effects of that are not necessarily desirable (loss of end-to-end connectivity, performance issues, limitations on simultaneous connections etc etc). It seems to me that it is this property of NAT that people are most loath to lose. And why ULA looks tantalisingly delicious. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 signature.asc Description: This is a digitally signed message part
RE: quietly....
People won't be able to access our site sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.). Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change. Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented. Oh, and when I said to pick your RIR, I meant the RIR of users who access your content. Lee
Re: quietly....
Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later no. arin is out, not an isp Will users be unable to reach your content on $RIR_runout_date + 3? yes, of course randy
Re: quietly....
On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: On Tue, 2011-02-01 at 13:38 -0800, Owen DeLong wrote: NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. Which is a bug, not a feature. The side effects of that are not necessarily desirable (loss of end-to-end connectivity, performance issues, limitations on simultaneous connections etc etc). Exactly. It seems to me that it is this property of NAT that people are most loath to lose. And why ULA looks tantalisingly delicious. Yeah, but, if we take a step back and look for what they actually want that they are willing to give up everything else to get, it usually boils down to two things: 1. Obfuscation of host addresses 2. Ability to move an entire topology from one number space to another without reconfiguring the topology. IPv6 solves 1 with privacy addresses. These are horrible and I hope nobody really uses them, but, they're better than NAT. The solution to number 2 depends again on the circumstance. IPv6 offers a variety of tools for this problem, but, I have yet to see an environment where the other tools can't offer a better solution than NAT. Owen
Re: quietly....
On Feb 1, 2011, at 3:54 PM, Lee Howard wrote: People won't be able to access our site sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.). Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change. Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented. Oh, and when I said to pick your RIR, I meant the RIR of users who access your content. Lee I think there is a key problem with Geoff's graph. I think it fails to take into account the transitive probability of requests among the largest 3 regions. I agree that APNIC will probably run just about exactly as he predicts. I think, however, that the runout at APNIC will create a higher demand in ARIN and RIPE. Once that happens, their runout dates will get moved up much closer to the runout date of APNIC. As soon as the second of the three runs out, the remaining one will get another burst of acceleration. It does not appear to me that this probability is accounted for in the plots. Owen (Including Geoff because it's not fair to criticize his work behind his back)
Re: quietly....
Once upon a time, Owen DeLong o...@delong.com said: On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. Which is a bug, not a feature. That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people I'm right, you're wrong over and over again leads to them going away and ignoring IPv6. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: quietly....
On 02/01/2011 04:11 PM, Owen DeLong wrote: On Feb 1, 2011, at 3:54 PM, Lee Howard wrote: People won't be able to access our site sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.). Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change. Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented. Oh, and when I said to pick your RIR, I meant the RIR of users who access your content. Lee I think there is a key problem with Geoff's graph. I think it fails to take into account the transitive probability of requests among the largest 3 regions. I agree that APNIC will probably run just about exactly as he predicts. I think, however, that the runout at APNIC will create a higher demand in ARIN and RIPE. Once that happens, their runout dates will get moved up much closer to the runout date of APNIC. As soon as the second of the three runs out, the remaining one will get another burst of acceleration. It does not appear to me that this probability is accounted for in the plots. Owen (Including Geoff because it's not fair to criticize his work behind his back) Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. Paul
Re: quietly....
On Feb 1, 2011, at 6:24 PM, Chris Adams wrote: Once upon a time, Owen DeLong o...@delong.com said: On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. Which is a bug, not a feature. That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people I'm right, you're wrong over and over again leads to them going away and ignoring IPv6. Using this definition of bug from Wikipedia: A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. I argue that breaking the end-to-end model which is a documented fundamental tenant of the internet protocol and the internet addressing system is, by definition, within the definition above. Q.E.D. it is, in fact, a bug, not merely my opinion. Others are welcome to consider said bug to be a feature, but, it is, by definition, factually, a bug. Owen
Re: quietly....
On 02/01/2011 08:27 PM, Paul Graydon wrote: Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. I've heard that it's already started at ARIN. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 x203 Fax: 312-602-2688 Cell: 312-320-5867 signature.asc Description: OpenPGP digital signature
Re: quietly....
On Tue, Feb 1, 2011 at 6:24 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Owen DeLong o...@delong.com said: On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. Which is a bug, not a feature. That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people I'm right, you're wrong over and over again leads to them going away and ignoring IPv6. +1 Somebody should probably get a blog instead of sending, *39 and counting*, emails to this list in one day.
Re: quietly....
On Feb 1, 2011, at 9:39 PM, Kevin Stange wrote: On 02/01/2011 08:27 PM, Paul Graydon wrote: Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. I've heard that it's already started at ARIN. We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a rush. FYI, /John John Curran President and CEO ARIN
Re: quietly....
On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a rush. Any trending on the rate of requests for IPv6 prefixes? pgp34QnafcYIJ.pgp Description: PGP signature
Re: quietly....
On 2/1/2011 9:33 PM, Owen DeLong wrote: On Feb 1, 2011, at 6:24 PM, Chris Adams wrote: Once upon a time, Owen DeLongo...@delong.com said: On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. Which is a bug, not a feature. That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people I'm right, you're wrong over and over again leads to them going away and ignoring IPv6. Using this definition of bug from Wikipedia: A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. I argue that breaking the end-to-end model which is a documented fundamental tenant of the internet protocol and the internet addressing system is, by definition, within the definition above. Q.E.D. it is, in fact, a bug, not merely my opinion. Others are welcome to consider said bug to be a feature, but, it is, by definition, factually, a bug. I apologize in advance for the strong wording, and will apologize for it in person (with a beer) at some point. But: A NATed client connects to a server, and they speak end to end. A NATed server receives connections directly from clients. It is more or less end to end, communications-wise, and so it is the same or less of a bug, by your definition, than a proxy server, or a web cache, or ipv4 anycast DNS, or inspecting/fixup capable firewalls. And those are all things people want. If you are advocating that IPv6 should not be capable of performing tasks people want it to perform, then you are advocating for IPv6 to follow the path of the OSI protocols as a could have been the new Internet protocol, and you are pushing the world toward the NATernet, and you are actually, unintentionally, one of IPv6's worst enemies. Look back across all the big arguments over the years that had people turning purple and calling each other names and declaring that IPv6 was broken. They are all about features in IPv6 that operators did not want, because directly or indirectly, they either disabled features people use now, or they told people how hey had to build their networks. They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. You can blame sloth, ignorance, and heads in the sand all you want for the long wait for IPv6 adoption, but the insistence by IPv6 evangelists that IPv4-think is necessarily evil and that they are going to force everybody to conform to their perfect paradigm is also a big factor. And this isn't just a perception issue, or rebellion at being told what to do. Part of what made IPv4 so successful was that its simplicity made it inherently flexible, and even operators who are wrong about what things like NAT give them are right to rebel against restricting flexibility to meet certain people's perception of what network purity means today. -Dave
Re: quietly....
On Tue, Feb 1, 2011 at 7:46 PM, valdis.kletni...@vt.edu wrote: On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a rush. Any trending on the rate of requests for IPv6 prefixes? More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates. Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag. -- -george william herbert george.herb...@gmail.com
Re: quietly....
On Feb 1, 2011, at 10:46 PM, valdis.kletni...@vt.edu wrote: On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a rush. Any trending on the rate of requests for IPv6 prefixes? A quick review shows no significant change in IPv6 request rate January through today, although I would point out that the second of half of 2010 had a fairly significant ramp up in IPv6 requests (both assignments and allocations). You can view all the 2010 charts are online here: https://www.arin.net/knowledge/statistics/index.html. FYI, /John John Curran President and CEO ARIN
Re: quietly....
On Feb 1, 2011, at 11:05 PM, George Herbert wrote: More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates. Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag. I don't believe we've had an IPv6 additional request yet (but I look forward to it happening at some point :-). I will check and get back to the list with the definitive answer. /John John Curran President and CEO ARIN
Re: quietly....
Not necessarily. There was a proposal passed at ARIN and I have a similar one proposed for APNIC where you can request a second allocation should you need it for a variety of justification. For example: disparate non-connected networks under a different AS's. This is the one that is bothering me at the moment. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists ske...@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - On 2/02/11 3:05 PM, George Herbert george.herb...@gmail.com wrote: On Tue, Feb 1, 2011 at 7:46 PM, valdis.kletni...@vt.edu wrote: On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a rush. Any trending on the rate of requests for IPv6 prefixes? More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates. Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag. -- -george william herbert george.herb...@gmail.com
Re: quietly....
On Tue, Feb 1, 2011 at 11:32 PM, Skeeve Stevens ske...@eintellego.net wrote: Not necessarily. There was a proposal passed at ARIN and I have a similar one proposed for http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html (I think you mean, or the one dave farmer's been working on for a time now) -chris
Re: quietly....
On 2/1/2011 9:51 PM, Dave Israel wrote: They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. You mean like the lack of Default Router in DHCPv6? Don't get me wrong. I love RA. However, it is NOT a universal tool, and there are cases where Default Router via DHCPv6 would be more appropriate and easier to manage. Case in point. If I hand out IA_NA or IA_TA to directly connected DSL hosts or CPEs, I have no need of RA. In addition, the load on my router is increased by having to send RA to 3000+ interfaces, something that is absolutely not necessary in my deployment. I would even go as far to say that Default Router would be a good stateless option to hand out along with the DNS servers when customers do SLAAC with me. I have also now seen 2 different vendor DSL modems which when not using PPPoE require a manually entered default router (ie, no RA support). Jack
Re: quietly....
On 2/1/2011 10:19 PM, John Curran wrote: I don't believe we've had an IPv6 additional request yet (but I look forward to it happening at some point:-). I will check and get back to the list with the definitive answer. I believe that the changing of IPv6 policy leads to redo's, and I expect to see expansions again if current proposals are accepted. I don't believe enough eyeballs have been assigned address space yet with current policy to draw necessity yet. Further expansions would likely reduce that necessity even further. Jack
Re: quietly....
Somebody should probably get a blog instead of sending, *39 and counting*, emails to this list in one day. procmail is your friend
Re: quietly....
On 02/02/2011, at 1:11 PM, Owen DeLong wrote: On Feb 1, 2011, at 3:54 PM, Lee Howard wrote: People won't be able to access our site sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.). Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change. Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented. Oh, and when I said to pick your RIR, I meant the RIR of users who access your content. Lee I think there is a key problem with Geoff's graph. I think it fails to take into account the transitive probability of requests among the largest 3 regions. I agree that APNIC will probably run just about exactly as he predicts. I think, however, that the runout at APNIC will create a higher demand in ARIN and RIPE. Once that happens, their runout dates will get moved up much closer to the runout date of APNIC. As soon as the second of the three runs out, the remaining one will get another burst of acceleration. It does not appear to me that this probability is accounted for in the plots. Owen (Including Geoff because it's not fair to criticize his work behind his back) Yes - a certain (X) percent of demand will shift out from a region once that region's stocks are depleted. What value X realistically takes is not something I can factor into these models, nor can I predict where this unmet demand may surface in the remaining regions. The future of IPv4 contains many uncertainties. Geoff
Re: quietly....
On Mon, Jan 31, 2011 at 3:25 PM, bill manning bmann...@isi.edu wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED ... whimper ... Almost a sigh, actually; though in a moment of horrid thread convergence and poor taste, there was some question being tossed around as to whether Egypt's space could be reused, if they're not going to use it after all... :/ Matt
Re: quietly....
That was it :-) so long IPv4! It's been a great ride! As good old Frank said, And now, the end is near, we face the final curtain... cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush ra...@psg.com wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
RE: quietly....
I thought there are still 5 /8's left in IANA. -Original Message- From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly That was it :-) so long IPv4! It's been a great ride! As good old Frank said, And now, the end is near, we face the final curtain... cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush ra...@psg.com wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: quietly....
I seem to recall there is an automatic endgame for those...? On Mon, Jan 31, 2011 at 7:20 PM, Patrick Greene patri...@layer8llc.comwrote: I thought there are still 5 /8's left in IANA. -Original Message- From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly That was it :-) so long IPv4! It's been a great ride! As good old Frank said, And now, the end is near, we face the final curtain... cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush ra...@psg.com wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: quietly....
On 1/31/2011 6:20 PM, Patrick Greene wrote: I thought there are still 5 /8's left in IANA. I thought there was an agreement that when there was only 5 /8's, each RIR would be allocated 1 /8, and IANA would be done. :) Jack
Re: quietly....
One each of the remaining /8′s will be allocated to each RIR. Once the RIR’s are out of space in their current supply and they only have this 1 /8 left, it will trigger policies relating to how that /8 will be allocated. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists ske...@eintellego.netmailto:ske...@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. On 1/02/11 11:20 AM, Patrick Greene patri...@layer8llc.commailto:patri...@layer8llc.com wrote: I thought there are still 5 /8's left in IANA. -Original Message- From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly That was it :-) so long IPv4! It's been a great ride! As good old Frank said, And now, the end is near, we face the final curtain... cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush ra...@psg.commailto:ra...@psg.com wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: quietly....
The last 5 are, by existing agreement, to be allocated 1 per Regional registry immediately after the other /8s are exhausted. This was agreed to some time ago to ensure that no regional was disadvantaged by timing concerns on applications for space as the IANA exhaustion approached. As that has now happened, all that awaits is for the announcement of which RIR got which remaining /8. Immediate doesn't mean today this instant, but by agreement, they're effectively all gone right now. The large woman has walked on stage and is awaiting the orchestra director's starting the music. -george On Mon, Jan 31, 2011 at 4:20 PM, Patrick Greene patri...@layer8llc.com wrote: I thought there are still 5 /8's left in IANA. -Original Message- From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly That was it :-) so long IPv4! It's been a great ride! As good old Frank said, And now, the end is near, we face the final curtain... cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush ra...@psg.com wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net = -- -george william herbert george.herb...@gmail.com
Re: quietly....
Almost a sigh, actually; though in a moment of horrid thread convergence and poor taste, there was some question being tossed around as to whether Egypt's space could be reused, if they're not going to use it after all... :/ That's sounds like those bad jokes that some jerks tell at a funeral. -J
Re: quietly....
On Mon, Jan 31, 2011 at 4:22 PM, Jack Bates jba...@brightok.net wrote: On 1/31/2011 6:20 PM, Patrick Greene wrote: I thought there are still 5 /8's left in IANA. I thought there was an agreement that when there was only 5 /8's, each RIR would be allocated 1 /8, and IANA would be done. :) Jack It's more than just an agreement--it's part of the documented IANA global policy: http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm We're now faction section 2 action. Matt
Re: quietly....
They are effectively gone, will be allocated in coming days or weeks, 1 per RIR. This is per global IANA policy. regards Carlos On 1/31/11 10:20 PM, Patrick Greene wrote: I thought there are still 5 /8's left in IANA. -Original Message- From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly That was it :-) so long IPv4! It's been a great ride! As good old Frank said, And now, the end is near, we face the final curtain... cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush ra...@psg.com wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: quietly....
On Mon, Jan 31, 2011 at 5:36 PM, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: That was it :-) so long IPv4! It's been a great ride! IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. As good old Frank said, And now, the end is near, we face the final curtain... -- -JH
Re: quietly....
On 1/31/2011 9:55 PM, Jimmy Hess wrote: There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. Until the core networks fix their peering relationships, I don't think it matters. My connectivity to google still sucks. Nothing else matters. :) Jack
Re: quietly....
On Jan 31, 2011, at 7:55 PM, Jimmy Hess wrote: On Mon, Jan 31, 2011 at 5:36 PM, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: That was it :-) so long IPv4! It's been a great ride! IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. As good old Frank said, And now, the end is near, we face the final curtain... -- -JH It may not be dead, but, it's is chain stoking. Owen
Re: quietly....
On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess mysi...@gmail.com wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up! -Jack Carrozzo
Re: quietly....
Has there been any discussion about allocating the Class E blocks? If this doesn't count as future use what does? (Yes, I realize this doesn't *fix* the problem here) -Jeremy On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo j...@crepinc.com wrote: On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess mysi...@gmail.com wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up! -Jack Carrozzo
Re: quietly....
On Jan 31, 2011, at 8:15 PM, Jack Carrozzo wrote: On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess mysi...@gmail.com wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up! -Jack Carrozzo All of the eye networks that have looked at this have realized the following things that you apparently have not: 1. Layering NAT beyond 2 deep (one provider, one subscriber) doesn't help. 2. NAT444 will break lots of things that work in current NAT44. 3. Users subjected to this environment after experiencing the limited brokenness of NAT44 or full access to the internet will not be happy. 4. Maintaining NAT444 environments will be a support headache and a costly arms race of deployments and management. 5. IPv6 will cost a lot less than NAT444 as soon as they can get their subscribers fully deployed and is a much more desirable alternative. Owen
Re: quietly....
Discussed, Disgusted, and Dismissed. The E space would take more software upgrades to existing systems than just deploying IPv6. Owen On Jan 31, 2011, at 8:31 PM, Jeremy wrote: Has there been any discussion about allocating the Class E blocks? If this doesn't count as future use what does? (Yes, I realize this doesn't *fix* the problem here) -Jeremy On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo j...@crepinc.com wrote: On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess mysi...@gmail.com wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up! -Jack Carrozzo
Re: quietly....
Jeremy, I have not heard of any IP stack that is built to accept 240/4. Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think about all routers, including CPE:s, out there. The logic goes: You are many orders of magnitudes more likely to get v6 off the ground, than 240/4 or 224/4 as unicast IPv4. 224/3 will never be very usable as public v4 space since every non-upgraded host on the Internet will be unable to send packets to them, eg, for every additional host you introduce with these addresses the worse the reachability situation becomes for the v4 Internet. Notably, this is the inverse of what happens when you introduce more hosts with native, proper IPv6, in the IPv6-Internet. Cheers, Martin On Mon, Jan 31, 2011 at 11:31 PM, Jeremy jba...@gmail.com wrote: Has there been any discussion about allocating the Class E blocks? If this doesn't count as future use what does? (Yes, I realize this doesn't *fix* the problem here) -Jeremy On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo j...@crepinc.com wrote: On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess mysi...@gmail.com wrote: IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later. What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up! -Jack Carrozzo
Re: quietly....
On Tue, Feb 1, 2011 at 12:00 AM, Martin Millnert milln...@gmail.com wrote: Neither Linux 2.6.37 nor Windows 7 accepts it Oops, I was clumpsy there, apologies. When I was testing this, I messed up one of my hosts :/ It seems 240/4 *does* work as unicast v4 in Linux 2.6.37. Then it's easy, just convert everything to Linux. ;) /M
Re: quietly....
On Mon, 31 Jan 2011, Jeremy wrote: Has there been any discussion about allocating the Class E blocks? If this doesn't count as future use what does? (Yes, I realize this doesn't *fix* the problem here) I think it has been discussed at various levels, but would likely have been dismissed for one or more of the following reasons: 1. A lot of people filter packets and/or prefixes 224/3 or 240/4 out of habit, right, wrong, or otherwise, so space from 240/4 is likely to have lots of reachability problems. 2. The effort expended by people to solve reachability problems from space they'd get out of 240/4 would be better put toward moving to v6. 3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. jms
Re: quietly....
On Mon, Jan 31, 2011 at 8:38 PM, Owen DeLong o...@delong.com wrote: Discussed, Disgusted, and Dismissed. The E space would take more software upgrades to existing systems than just deploying IPv6. It's true. It was only after discovering how much work it would take to make 240/4 like RFC 1918 (truly impossible) that I fully engaged in doing IPv6. Now, we are pretty close to launching an IPv6-only + NAT64 service to mobile customer. Cameron === T-Mobile USA IPv6 Beta - http://bit.ly/9s0Ed3 ===
Re: quietly....
On Mon, Jan 31, 2011 at 11:00 PM, Martin Millnert milln...@gmail.com wrote: This has come up before, in 2007, and earlier, http://www.merit.edu/mail.archives/nanog/2007-10/msg00487.html Way too late now for unreserving 240/4 to help. Now, if it had been unreserved in 2003 or so, there might not be so many devices to upgrade. There could a case to be made for unreserving 240/4 now, so perhaps it could be used in 2020,. Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think about all routers, including CPE:s, out there. hm.. for Linux, there was a patch for this in 2008, in the kernel proper should be in 2.6.25 and newer, http://kerneltrap.org/mailarchive/linux-netdev/2008/1/21/587456 -- -JH
Re: quietly....
On Mon, Jan 31, 2011 at 10:31:43PM -0600, Jeremy wrote: Has there been any discussion about allocating the Class E blocks? If this doesn't count as future use what does? (Yes, I realize this doesn't *fix* the problem here) https://puck.nether.net/pipermail/240-e Last real message? 31 Oct 2007 Done and done. V6, please. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: quietly....
On Jan 31, 2011, at 4:49 PM, Justin M. Streiner wrote: On Mon, 31 Jan 2011, Jeremy wrote: Has there been any discussion about allocating the Class E blocks? If this doesn't count as future use what does? (Yes, I realize this doesn't *fix* the problem here) I think it has been discussed at various levels, but would likely have been dismissed for one or more of the following reasons: 1. A lot of people filter packets and/or prefixes 224/3 or 240/4 out of habit, right, wrong, or otherwise, so space from 240/4 is likely to have lots of reachability problems. Also, many systems will not accept this traffic or configuration as hard-coded system parameters. 2. The effort expended by people to solve reachability problems from space they'd get out of 240/4 would be better put toward moving to v6. Not to mention the software updates required to make it functional would exceed the software updates necessary for IPv6 _AND_ it has no lasting future. 3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. Actually, if last year's consumption is any indicator, it's more like 10 months and given the accelerating consumption of IPv4 overall, I'd say less than 9 is not unlikely. I'm betting you're talking about more than 9 months to get the software and reachability issues resolved. Owen
RE: quietly....
Not to mention the software updates required to make it functional would exceed the software updates necessary for IPv6 _AND_ it has no lasting future. Part one of that statement goes for v6 in a lot of places. The whole NAT444 allocation argument would go away with this. Maybe we need both. It might be easier to teach a v4-only device to use that space than to teach it to use v6. Part 2 is dead on in that it has no lasting future ... but what if it does? What if Outer Slobovia decides to simply number their nation using the entire v4 /0. Everyone can talk with each other inside the country just fine. $PROVIDER wants to provide services there? Well, they will just need to get an allocation out of Outer Slobovia's address space and NAT that to their services using either NAT44 or a stateless NAT64/DNS64 (Tayga or something). Outer Slobovia gets mad at the world? They just black hole the block set aside for foreign assignments and connectivity is instantly cut off. No v6 and no v4 leaks outside the country. I suspect we will see countries do just that.
RE: quietly....
3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. jms If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it.
Re: quietly....
On 1/31/11 10:43 PM, George Bonser wrote: 3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. jms If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it. except when the tried to determine their external ip. and of course one of the big applications for cgnat is mobile where the cpe are the end systems... There are negligible benefits as far as I can tell from the vantage points of end systems to creating new private scope ipv4 regions at this late date. network operators see some but frankly each one comes with additional support costs as does using rfc1918... the difference is we've got a lot of experience with the latter even in nat444 envirnments.
