Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, Feb 11, 2011 at 8:29 PM, Tom Limoncelli t...@whatexit.org wrote: On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong o...@delong.com wrote: I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. I'm writing an article where I want to say that but I can't find an article I can reference to back it up. I don't want to accidentally encourage an urban legend or rumor. (For example, I can't find verification to the rumor that ARIN rejected a request from LTE providers for IPv4 space and instead told them to go straight to IPv6. I do others in this thread saying that native IPv4 on LTE is common, so unless someone can give me evidence, I'll have to update that part of the article. OMG i'd love to make that point; anyone have proof?). I could, instead, write, most carriers will probably roll IPv6 out as part of their 4G upgrade but that sounds wishy-washy. Thanks in advance, Tom -- http://EverythingSysadmin.com -- my blog (new posts Mon and Wed) http://www.TomOnTime.com -- my advice (more videos coming soon) The article I mentioned I was writing has been published and is now available on-line here: http://queue.acm.org/detail.cfm?id=1959015 Thanks for all the assistance both on this mailing list and the private email I received! Tom Limoncelli http://www.EverythingSysadmin.com -- Sign up for my new class Advanced Time Mgmt: Team Efficiency at PICC! April 29-30, New Jersey, LOPSA PICC: www.picconf.org Dec 4-9, Boston, Usenix LISA, www.usenix.org/event/lisa11 Dec 4-5, Boston, ACM CHIMIT, chimit.acm.org Call for papers and talk proposals open at LISA and CHIMIT!
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Now that is what Baldrick* would call a cunning plan! And interesting examples. Christian *Apologies to Tony Robinson and Blackadder On 12 Mar 2011, at 18:52, Tom Limoncelli wrote: On Fri, Feb 11, 2011 at 8:29 PM, Tom Limoncelli t...@whatexit.org wrote: On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong o...@delong.com wrote: I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. I'm writing an article where I want to say that but I can't find an article I can reference to back it up. I don't want to accidentally encourage an urban legend or rumor. (For example, I can't find verification to the rumor that ARIN rejected a request from LTE providers for IPv4 space and instead told them to go straight to IPv6. I do others in this thread saying that native IPv4 on LTE is common, so unless someone can give me evidence, I'll have to update that part of the article. OMG i'd love to make that point; anyone have proof?). I could, instead, write, most carriers will probably roll IPv6 out as part of their 4G upgrade but that sounds wishy-washy. Thanks in advance, Tom -- http://EverythingSysadmin.com -- my blog (new posts Mon and Wed) http://www.TomOnTime.com -- my advice (more videos coming soon) The article I mentioned I was writing has been published and is now available on-line here: http://queue.acm.org/detail.cfm?id=1959015 Thanks for all the assistance both on this mailing list and the private email I received! Tom Limoncelli http://www.EverythingSysadmin.com -- Sign up for my new class Advanced Time Mgmt: Team Efficiency at PICC! April 29-30, New Jersey, LOPSA PICC: www.picconf.org Dec 4-9, Boston, Usenix LISA, www.usenix.org/event/lisa11 Dec 4-5, Boston, ACM CHIMIT, chimit.acm.org Call for papers and talk proposals open at LISA and CHIMIT!
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: On Mon, Feb 21, 2011 at 19:08, Dan Wing dw...@cisco.com wrote: Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). More importantly, I am unsure the point of this argument. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as broken as others have claimed, and sub-optimal might be acceptable if it's the only alternative. Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
[ arin cesspool removed from cc: as i can not post there anyway ] There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. excuse me! randy
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 12:29 AM, Benson Schliesser wrote: On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: On Mon, Feb 21, 2011 at 19:08, Dan Wing dw...@cisco.com wrote: Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). I would point out to them that the fact that their technology choice isn't NAT 444 does not mean that they don't have the same problems, merely that their technology wasn't part of the testing documented in the draft. I think the draft is perfectly clear and that humans, even intelligent humans often have problems with this level of logic. If A is a subset of B, it does not mean that A is not a subset of C. Therefore, a draft that states that technology B has problem A is not and cannot be logically construed as a statement that technology C does not have problem A, no matter how common it is for seemingly intelligent humans to make the mistake of doing so. More importantly, I am unsure the point of this argument. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. I don't think anyone has said that IPv6 is the only address family that matters. What I think people, myself included, have been saying is that IPv6 is the only way forward that does not involve many of these problems. (See my earlier Titanic post). As to whether or not it matters that people misinterpred draft-donly..., I'm not sure whether it actually does or not. There is no flavor of NAT that is particularly desirable. It's a matter of choosing the one that is least damaging to your environment where least damage may boil down to a choice between 5% and 3% remaining functionality. On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as broken as others have claimed, and sub-optimal might be acceptable if it's the only alternative. I don't think anyone is saying IPv4 no longer matters. I think we are saying that effort spent attempting to make the deteriorating IPv4 situation deteriorate less is both futile and better spent on making the IPv6 deployment situation better. Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. Only if you expect that you can rely on a supply side in such a market. I am unconvinced that such will be reliable, especially after about 6 months of trading. This also presumes that more sensitive users can be defined in terms of what those users are willing (or able) to pay. Owen (who is very glad he has provider-independent addresses in both families as we approach this iceberg)
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
-Original Message- From: Chris Grundemann [mailto:cgrundem...@gmail.com] Sent: Monday, February 21, 2011 8:17 PM To: Dan Wing Cc: Owen DeLong; Benson Schliesser; NANOG list; ARIN-PPML List Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) On Mon, Feb 21, 2011 at 19:08, Dan Wing dw...@cisco.com wrote: Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. More importantly, I am unsure the point of this argument. My point is that: NAT breaks things, but NAT444 is /not/ the only case where breakage occurs. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). Vendor test results don't carry much value. The authors of draft-donley-nat444-impacts did testing, and I sincerely hope will publish results that split the impacts of access bandwidth starvation from home NAT from CGN from NAT444. -d Cheers, ~Chris -d -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 3:14 AM, Randy Bush wrote: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. excuse me! Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators with the opinion that 'IPv4 doesn't matter' represent the minority. Of course, it also depends on how you define doesn't matter. I think that ongoing operation matters, especially when ongoing means a continued expectation of both existing and new customers. It's easy to say, burn the IPv4 bridge so we're forced to migrate to IPv6. But it's another thing to actually do it, when you're competing for customers that want IPv4 connectivity. That said, we're not forced to choose only one: IPv4 vs. IPv6. We should migrate to IPv6 because it makes sense - IPv4 is going to become more expensive and painful (to use and support). That doesn't preclude us from patching IPv4 together long enough to cross the bridge first. Thoughts? Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. most pronounced from people not involved in operating production networks that are way behind the planning curve for IPv6 deployment. There, fixed that for you. (Full disclosure - yesterday's MRTG graphs show our border routers averaging 4Gbit/sec of IPv4 traffic and 150 Mbits/sec of IPv6 - so 4% or so of our production off-campus traffic is already IPv6) pgpxDmfB4FE37.pgp Description: PGP signature
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 3:54 PM, valdis.kletni...@vt.edu wrote: On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. most pronounced from people not involved in operating production networks that are way behind the planning curve for IPv6 deployment. There, fixed that for you. My original text remains true, because I tend to hear IPv6-only advocacy from vendors and policy folks more than operators - even more so versus operators of commercial ISP networks. But I take your point, that operators ahead of the IPv6 deployment curve are most likely to stand up with that opinion. Of course, the network effect being what it is... Your network being 100% IPv6 doesn't solve the overall problem of reachability. I think your example of 4% traffic from VT is applicable - you will have to worry about IPv4 connectivity, in one form or another, until it diminishes significantly. It's a bit like a tragedy of the commons. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 4:42 PM, Tony Hain wrote: Seriously, some people will not move until the path they are on is already burning, which is why they did nothing over the last 5 years despite knowing that the IANA pool was exhausting much faster than they had wanted to believe. It took getting within months of exhausting the IANA pool before the crowd woke up and noticed the path was on fire. Now you want 'just a little more'... after which it will be 'just a little more'. This won't go on forever. The price of IPv4 has been kept artificially low for the past decade, through a RIR-based system of rationing. There was never an immediate incentive to migrate. If we really wanted to motivate people before they reached the precipice, we should have increasingly raised the cost of an IPv4 address. Now, IPv4 exhaustion has effectively raised that cost for us, and people are motivated to migrate to IPv6. But since we didn't force this situation sooner, we now also have to deal with the effects of exhaustion. That's all I'm talking about. IPv4 hacks will not be better or cheaper than IPv6, and they're nothing to fear in terms of IPv6 adoption. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. excuse me! Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators benson, vendors saying what operators want went *seriously* out of fashion a couple of years back. we can speak for ourselves, tyvm. randy
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 6:29 PM, Randy Bush wrote: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. excuse me! Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators benson, vendors saying what operators want went *seriously* out of fashion a couple of years back. we can speak for ourselves, tyvm. I agree completely. I'm responding to what I've heard from operators. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 20, 2011, at 10:35 PM, Jimmy Hess wrote: On Fri, Feb 18, 2011 at 2:24 AM, Zed Usser zzu...@yahoo.com wrote: Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: Actually, many facebook and youtube features will also be degraded. - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :) You're joking, right? I don't think that most customers are going to take kindly to having their internet experience on their computer(s) reduced to what they expect from their cell phone. Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. Until some competitor who's not using NAT444 comes along and advertises that those functions work properly, maybe. Only for very liberal definitions of the phrase won't care either way Tolerate != won't care Most of them != People who won't eventually tell their friends or tweet about their frustrations Nah... Just make sure tweeting is one of the things you break along with the rest of the itner-tubes. (joking, of course). For those who are connecting to watch Netflix, it is only marginally less annoying for the user than removing the always on feature of DSL, requiring customers to manually click an icon to dial in, and get a busy tone played / All dialin 'lines are busy' / Please use IPv6 while you wait, wait 10 minutes and try dialing in again, if there are no global IPv4 IPs available at the moment they are trying to connect. As long as you give them IPv6, their Netflix and Youtube will work. Some might even strongly prefer that (time limited access and pay per connected hour) for periods of access to proper unique IPs over NAT444 brokenness; You guys are making me very very glad that I: 1. Do not depend on my provider for IPv4 addresses. 2. Have a fully dual-stack environment at home. 3. Do not depend on my residential provider to deliver anything more than the ability to shove GRE across the internet encapsulated in whatever protocol (v4/v6) works at the time. possibly with a customer choice between NAT444 and time metered dynamic unique IP and reasonably automatic simple means of switching between IP types on demand. I encourage my competitors to try this. Owen
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
-Original Message- From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf Of Chris Grundemann Sent: Thursday, February 17, 2011 5:55 PM To: Benson Schliesser Cc: NANOG list; ARIN-PPML List Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) On Thu, Feb 10, 2011 at 14:17, Benson Schliesser bens...@queuefull.net wrote: If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN. For details, see my comments at http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and see Reinaldo Penno's comments at http://www.ietf.org/mail-archive/web/behave/current/msg09030.html -d Cheers, ~Chris Regardless, I think we can agree that IPv6 is the way to avoid NAT- related growing pains. We've known this for a long time. Cheers, -Benson ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (arin-p...@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues. -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (arin-p...@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 21, 2011, at 12:37 PM, Dan Wing wrote: -Original Message- From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf Of Chris Grundemann Sent: Thursday, February 17, 2011 5:55 PM To: Benson Schliesser Cc: NANOG list; ARIN-PPML List Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) On Thu, Feb 10, 2011 at 14:17, Benson Schliesser bens...@queuefull.net wrote: If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN. For details, see my comments at http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and see Reinaldo Penno's comments at http://www.ietf.org/mail-archive/web/behave/current/msg09030.html -d The document describes problems that will exist in NAT444 environments. It does not state that these problems would be specific to NAT444, but, NAT444 will cause or exacerbate each of the problems described. Yes, the problems may have other underlying root causes, but, they will all be present in a NAT444 environment, even if they were not present in the same environment prior to deployment of NAT444. Let me put it this way... IPv4 has a TITANIC lack of numeric addresses and has been stretched beyond its limits for some time now. IPv6 is a life boat. NAT is a seat cushion used for floatation. NAT444 (and other NAT-based extensions) are deck chairs. Attempting to improve them beyond their current states is an effort to rearrange the deck chairs. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN. it may require a delicate palate to differentiate the different flavors of bleep randy
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
-Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Monday, February 21, 2011 12:59 PM To: Dan Wing Cc: 'Chris Grundemann'; 'Benson Schliesser'; 'NANOG list'; 'ARIN-PPML List' Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) On Feb 21, 2011, at 12:37 PM, Dan Wing wrote: -Original Message- From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf Of Chris Grundemann Sent: Thursday, February 17, 2011 5:55 PM To: Benson Schliesser Cc: NANOG list; ARIN-PPML List Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) On Thu, Feb 10, 2011 at 14:17, Benson Schliesser bens...@queuefull.net wrote: If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN. For details, see my comments at http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and see Reinaldo Penno's comments at http://www.ietf.org/mail-archive/web/behave/current/msg09030.html -d The document describes problems that will exist in NAT444 environments. It does not state that these problems would be specific to NAT444, but, NAT444 will cause or exacerbate each of the problems described. To the contrary. Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. Yes, the problems may have other underlying root causes, but, they will all be present in a NAT444 environment, even if they were not present in the same environment prior to deployment of NAT444. Let me put it this way... IPv4 has a TITANIC lack of numeric addresses and has been stretched beyond its limits for some time now. IPv6 is a life boat. NAT is a seat cushion used for floatation. NAT444 (and other NAT-based extensions) are deck chairs. Attempting to improve them beyond their current states is an effort to rearrange the deck chairs. -d
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN. it may require a delicate palate to differentiate the different flavors of bleep Running out of bandwidth for Netflix is pretty distinct from the flavor of fried gNAT. -d
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Sun, 2/20/11, Owen DeLong o...@delong.com wrote: Oh, I expect CGN/LSN to be connectivity of last resort, no question. Ok, so let's just deploy it and not even try to fix it? Even when it is a required functionality for IPv6-only hosts to access the IPv4 domain? That'll go down real well with end-users and really cut down on the operational and support issues enumerated earlier. - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 20, 2011, at 3:27 AM, Zed Usser wrote: --- On Sun, 2/20/11, Owen DeLong o...@delong.com wrote: Oh, I expect CGN/LSN to be connectivity of last resort, no question. Ok, so let's just deploy it and not even try to fix it? Even when it is a required functionality for IPv6-only hosts to access the IPv4 domain? That'll go down real well with end-users and really cut down on the operational and support issues enumerated earlier. - Zed Again, I think that it is unfixable and that development efforts are better focused on getting the IPv4 only hosts onto IPv6 as that IS a workable solution to the problem where NAT444 is an awful hack made worse by layering. IPv6 deployment is the only thing that will cut down on the operational and support issues enumerated. Trying to fix NAT444 is like trying to use more gas to get yourself out of the mud in a 2-wheel drive automobile. If you take a limited view, you might think that pushing harder will help, but, in reality, you're just digging a deeper hole. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 2:24 AM, Zed Usser zzu...@yahoo.com wrote: Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :) Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. Until some competitor who's not using NAT444 comes along and advertises that those functions work properly, maybe. Only for very liberal definitions of the phrase won't care either way Tolerate != won't care Most of them != People who won't eventually tell their friends or tweet about their frustrations For those who are connecting to watch Netflix, it is only marginally less annoying for the user than removing the always on feature of DSL, requiring customers to manually click an icon to dial in, and get a busy tone played / All dialin 'lines are busy' / Please use IPv6 while you wait, wait 10 minutes and try dialing in again, if there are no global IPv4 IPs available at the moment they are trying to connect. Some might even strongly prefer that (time limited access and pay per connected hour) for periods of access to proper unique IPs over NAT444 brokenness; possibly with a customer choice between NAT444 and time metered dynamic unique IP and reasonably automatic simple means of switching between IP types on demand. -- -JH
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Sat, 2/19/11, Owen DeLong o...@delong.com wrote: Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? No, but, I am willing to bet that we will not meaningfully make the situation better for those IPv4-only hosts or the IPv6-only hosts attempting to reach them by any mechanism more efficient than encouraging them to add IPv6 capability, whether or not that happens after the fact. So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way? - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 19, 2011, at 12:41 AM, Zed Usser wrote: --- On Sat, 2/19/11, Owen DeLong o...@delong.com wrote: Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? No, but, I am willing to bet that we will not meaningfully make the situation better for those IPv4-only hosts or the IPv6-only hosts attempting to reach them by any mechanism more efficient than encouraging them to add IPv6 capability, whether or not that happens after the fact. So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way? - Zed I'm advocating not depending on any such interaction working as it's pretty clear that the available solution set is fairly broken. I'm advocating not expending significant development resources on enhancing that situation when it's pretty clear they are better spent facilitating IPv6 deployment to obviate the need for this level of hackery. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Sun, 2/20/11, Owen DeLong o...@delong.com wrote: So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way? I'm advocating not depending on any such interaction working as it's pretty clear that the available solution set is fairly broken. Fair enough. This approach will, however, relegate IPv6-only networks to second class citizenship status. Access to the real Internet will require IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best as you can. Not quite a ringing endorsement for IPv6, in other words. This position also assumes that there will be enough IPv4 addresses to go around for everybody to dual stack. Anybody not so fortunate will simply be left out in the cold. - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 19, 2011, at 11:31 AM, Zed Usser wrote: --- On Sun, 2/20/11, Owen DeLong o...@delong.com wrote: So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way? I'm advocating not depending on any such interaction working as it's pretty clear that the available solution set is fairly broken. Fair enough. This approach will, however, relegate IPv6-only networks to second class citizenship status. Access to the real Internet will require IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best as you can. Not quite a ringing endorsement for IPv6, in other words. This position also assumes that there will be enough IPv4 addresses to go around for everybody to dual stack. Anybody not so fortunate will simply be left out in the cold. - Zed Oh, I expect CGN/LSN to be connectivity of last resort, no question. However, I don't expect it to work. I don't expect us to be able to resolve the issues with it, and I expect that to fairly rapidly serve as motivation for content providers to adopt IPv6. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote: In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64 http://www.ietf.org/mail-archive/web/behave/current/msg09027.html Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :) Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? - Zed
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 17 feb 2011, at 17:35, George Bonser wrote: Considering v4 is likely to be around for another decade or two, getting Class E into general use seems easy enough to do. You really think people will be communicating over the public internet using IPv4 in 2031? It will take a long time before the first people are going to turn off IPv4, but once that starts there will be no stopping it and IPv4 will be gone very, very quickly. (Of course there will be legacy stuff, just like some people are still running IPX or AppleTalk today. I'm talking about the public internet here.) Today people are complaining how annoying it is to have to learn new things to be able to run IPv6, but that doesn't compare to how annoying it is to have to learn OLD things to keep running a protocol that is way past its sell by date. I still need to teach class A/B/C despite the fact that CIDR is old enough to drink in most countries because without knowing that you can't configure a Cisco router. That's annoying now. Think about how insane that will be in the 2020s when the notion of requesting IPv4 addresses from an RIR is ancient history and young people don't know any better than having a /64 on every LAN that is big enough to connect all ethernet NICs ever made. Speaking of class E: this address space could be usable for NAT64 translators. That way, only servers and routers need to be upgraded to work with class E, not CPEs or client OSes.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 17 feb 2011, at 18:57, John Curran wrote: Actually, as I have noted before, the US DoD has contractually agreed to return to ARIN unneeded IPv4 address space if/when such becomes available, so that it may be used by the Internet community. How can they return stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 18, 2011, at 5:54 AM, Iljitsch van Beijnum wrote: On 17 feb 2011, at 18:57, John Curran wrote: Actually, as I have noted before, the US DoD has contractually agreed to return to ARIN unneeded IPv4 address space if/when such becomes available, so that it may be used by the Internet community. How can they return stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick. Agreed. But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason IP space exists is because the DoD paid someone to come up with the idea? :) If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? Supposed it was space ARIN assigned the DoD? -- TTFN, patrick
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On 18 feb 2011, at 9:24, Zed Usser wrote: Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You forget: - no IPv6 tunnels Deploying NAT444 without IPv6 is a very bad thing.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 18 feb 2011, at 12:00, Patrick W. Gilmore wrote: How can they return stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick. But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason IP space exists is because the DoD paid someone to come up with the idea? :) True, but how is all of that relevant? If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? Supposed it was space ARIN assigned the DoD? Policies like giving each RIR one of the final five /8s were carefully created to give each RIR equal access to address space. Automatically giving legacy space to the RIR for the region that the holder of the legacy space is in is incompatible with that, and means that ARIN will get virtually all of it. To me, it seems both natural and fair that legacy space (especially /8s) is returned to IANA and then redistributed over the RIRs. By the way, IANA only deals in /8s. However, a lot of people got legacy /16s or other non-/8 sizes, so some /8s that are marked legacy actually contain a lot of unused space. Each of those /8 is administered by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. And if not, what is supposed to happen with this space. It's a significant amount, about half the size of the class E space: RIR Administerd byDelegated Free afrinic 33.55 M 8.71 M24.85 M apnic 100.66 M 77.95 M22.72 M arin 671.09 M 592.04 M79.05 M ripencc 67.11 M 63.01 M 4.10 M
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 9:24 AM, Zed Usser zzu...@yahoo.com wrote: Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? I'd compare it with borrowing some money: When you make NAT64 to reach from IPv6 to IPv4, you are borrowing the money to build a new house. When you make NAT444, you borrow the money to repay the debt you made by borrowing the previous month. Both are borrowing. Depending on the circumstances you may need both. cheers, andrew
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
* Iljitsch van Beijnum By the way, IANA only deals in /8s. However, a lot of people got legacy /16s or other non-/8 sizes, so some /8s that are marked legacy actually contain a lot of unused space. Each of those /8 is administered by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. The unused space in the ERX blocks were divided evenly between the RIRs a couple of years ago, see: http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf http://bgp.potaroo.net/stats/nro/various.html I believe «administered by» simply means that the RIR is the one providing reverse DNS services for the block in question. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 18 feb 2011, at 12:36, Tore Anderson wrote: Each of those /8 is administered by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. The unused space in the ERX blocks were divided evenly between the RIRs a couple of years ago, see: http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf Please find attached a summary spreadsheet (Excel format) providing the agreed distribution of administrative responsibility This still leaves the question of which RIR gets to give out which parts of the unused legacy space unanswered.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
* Iljitsch van Beijnum http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf Please find attached a summary spreadsheet (Excel format) providing the agreed distribution of administrative responsibility Hit your Page Down button a couple of times, it's included right there in the PDF. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 18 feb 2011, at 12:59, Tore Anderson wrote: Hit your Page Down button a couple of times, it's included right there in the PDF. I don't see anything that clears this up.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 18, 2011, at 6:16 AM, Iljitsch van Beijnum wrote: On 18 feb 2011, at 12:00, Patrick W. Gilmore wrote: How can they return stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick. But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason IP space exists is because the DoD paid someone to come up with the idea? :) True, but how is all of that relevant? The first seems relevant because it was not possible for the US DoD to get space from ARIN. It's not like they chose to go around ARIN. The second seems relevant because ARIN is the successor, created by the IANA (Dr. Postel himself) specifically to take over the duties of address management in the geographic region where the DoD exists. When someone comes up with an idea (or pays someone to come up with an idea), they tend to get to use that idea before others. If you honestly cannot fathom why that is relevant, then I am not going to attempt to explain it to you. Now that I've answered your question, mind if I ask why you are asking? Or do you just prefer to troll? If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? Supposed it was space ARIN assigned the DoD? Policies like giving each RIR one of the final five /8s were carefully created to give each RIR equal access to address space. Automatically giving legacy space to the RIR for the region that the holder of the legacy space is in is incompatible with that, and means that ARIN will get virtually all of it. Then perhaps you should work through the process to change that? To me, it seems both natural and fair that legacy space (especially /8s) is returned to IANA and then redistributed over the RIRs. It may seem that way to many. Posting it to NANOG is not going to help you achieve what you deem to be fair natural. -- TTFN, patrick
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Iljitsch, In deed there were ERX unused space that were divided among RIRs, I think it is referred as various ERX (pointed out by Tore). http://bgp.potaroo.net/stats/nro/various.html There were also ERX space transferred from ARIN DB (used to be in InterNIC's) to RIRs because legacy holders were in the RIR region: http://www.lacnic.net/en/erx.html When you talk about unused legacy space are you talking about the various space or to the legacy space that is currently assigned but the holders just require part of it? Regards, -as On 18 Feb 2011, at 09:36, Tore Anderson wrote: * Iljitsch van Beijnum By the way, IANA only deals in /8s. However, a lot of people got legacy /16s or other non-/8 sizes, so some /8s that are marked legacy actually contain a lot of unused space. Each of those /8 is administered by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. The unused space in the ERX blocks were divided evenly between the RIRs a couple of years ago, see: http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf http://bgp.potaroo.net/stats/nro/various.html I believe «administered by» simply means that the RIR is the one providing reverse DNS services for the block in question. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 18 feb 2011, at 14:10, Arturo Servin wrote: When you talk about unused legacy space are you talking about the various space or to the legacy space that is currently assigned but the holders just require part of it? Legacy space (A) = all the /8s marked as legacy by IANA. Used legacy space (B): addresses allocated/assigned according to one of the RIRs which falls within A. Unused legacy space (C): A - B. Examples: lots of class B networks, either they were never given out or they were returned. And 45/8 minus 45.0.0.0/15.
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote: In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64 I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while technically accurate isn't particulrarly meaningful. http://www.ietf.org/mail-archive/web/behave/current/msg09027.html Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) I guess that depends on whether you like having customers or not. Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :) + More support phone calls + More unhappy customers + More cancellations + Less revenue + More costs + CALEA joy Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. An interesting theory. Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions. Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is broken in a number of ways, many of which are documented in the draft. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 18, 2011, at 2:50 AM, Iljitsch van Beijnum wrote: On 17 feb 2011, at 17:35, George Bonser wrote: Considering v4 is likely to be around for another decade or two, getting Class E into general use seems easy enough to do. You really think people will be communicating over the public internet using IPv4 in 2031? For some minimal definition of two endpoints both of which are IPv4, sure. It'll be across 4in6 tunnels or something like that, but, I'm sure there will still be die-hard legacy systems doing that in 2031. As to whether IPv4 will still be generally routed on the internet? I actually suspect that will end before 2021 and might start winding down as early as 2014. Many people think that is overly optimistic, but, I look at the scaling problems IPv4 routing will face in a post depletion world and I suspect the motivations to deprecate IPv4 will come on strong and fast as a result. Before you ask, no, I'm not going to promise to eat my column. (Hi Bob!) It will take a long time before the first people are going to turn off IPv4, but once that starts there will be no stopping it and IPv4 will be gone very, very quickly. Define long time. I'm thinking 3 to 5 years, maybe. (Of course there will be legacy stuff, just like some people are still running IPX or AppleTalk today. I'm talking about the public internet here.) Today people are complaining how annoying it is to have to learn new things to be able to run IPv6, but that doesn't compare to how annoying it is to have to learn OLD things to keep running a protocol that is way past its sell by date. I still need to teach class A/B/C despite the fact that CIDR is old enough to drink in most countries because without knowing that you can't configure a Cisco router. That's annoying now. Think about how insane that will be in the 2020s when the notion of requesting IPv4 addresses from an RIR is ancient history and young people don't know any better than having a /64 on every LAN that is big enough to connect all ethernet NICs ever made. I am not convinced you can't configure a cisco router without knowing about classful addressing. True, you will have to understand classful routing for the way Cisco displays routes to make sense to you, but, if you don't, all that happens is you wonder why they display things so strangely, grouping these octet-bounded collections of routes. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 18, 2011, at 2:54 AM, Iljitsch van Beijnum wrote: On 17 feb 2011, at 18:57, John Curran wrote: Actually, as I have noted before, the US DoD has contractually agreed to return to ARIN unneeded IPv4 address space if/when such becomes available, so that it may be used by the Internet community. How can they return stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick. The same way people have returned to ARIN resources obtained from: SRI Internic Network Solutions Internic ARIN is the successor registry and maintains the whois and in-addr data for the blocks. An attempt to return them to IANA directly would probably be met with a go return these to ARIN response. I don't know that for sure, but, that is what I would expect. As to ARIN getting the long end of the legacy stick, well, the ARIN region got the long end of the costs of developing and making the early deployments of the Internet, so, many of the legacy allocations and assignments are within the ARIN region. This is simple historical fact. I'm not sure why anyone feels we should attempt to revise history. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 18, 2011, at 3:16 AM, Iljitsch van Beijnum wrote: On 18 feb 2011, at 12:00, Patrick W. Gilmore wrote: How can they return stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick. But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason IP space exists is because the DoD paid someone to come up with the idea? :) True, but how is all of that relevant? If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? Supposed it was space ARIN assigned the DoD? Policies like giving each RIR one of the final five /8s were carefully created to give each RIR equal access to address space. Automatically giving legacy space to the RIR for the region that the holder of the legacy space is in is incompatible with that, and means that ARIN will get virtually all of it. To me, it seems both natural and fair that legacy space (especially /8s) is returned to IANA and then redistributed over the RIRs. By the way, IANA only deals in /8s. However, a lot of people got legacy /16s or other non-/8 sizes, so some /8s that are marked legacy actually contain a lot of unused space. Each of those /8 is administered by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. And if not, what is supposed to happen with this space. It's a significant amount, about half the size of the class E space: RIR Administerd byDelegated Free afrinic 33.55 M 8.71 M24.85 M apnic 100.66 M 77.95 M22.72 M arin 671.09 M 592.04 M79.05 M ripencc 67.11 M 63.01 M 4.10 M To the best of my knowledge, any RIR is free to allocate or assign any space it administers according to the policies set by that RIRs policy development process. If you feel that legacy resources returned to ARIN should be fed back to IANA, you are welcome to submit an appropriate policy to the ARIN policy development process in order to encourage such an action. Absent such a policy, I think your odds of achieving what you consider natural and fair are limited. I think that what is considered natural and fair by some is not considered so by others. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 3:33 AM, Andrew Yourtchenko wrote: On Fri, Feb 18, 2011 at 9:24 AM, Zed Usser zzu...@yahoo.com wrote: Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? I'd compare it with borrowing some money: When you make NAT64 to reach from IPv6 to IPv4, you are borrowing the money to build a new house. When you make NAT444, you borrow the money to repay the debt you made by borrowing the previous month. Both are borrowing. Depending on the circumstances you may need both. cheers, andrew If you are in a circumstance where you need to borrow money this month to repay your debt from last month, then, generally, you are on the fast track to bankruptcy court or a congressional investigation, perhaps both, depending on the size of debt snowball you are able to build. In the first case, you borrow money to leverage equity and there is a reasonable chance that by the time you pay off the loan, the value of what you built exceeds the amount borrowed. In the second case, you end up in a lather-rinse-repeat process where your debt load continues to grow and grow until it overpowers you. It's a good analogy, but, the second form of borrowing is far worse than the first. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Fri, 2/18/11, Owen DeLong o...@delong.com wrote: Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions. Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely. Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is broken in a number of ways, many of which are documented in the draft. We agree that IPv4/IPv6 domain interoperability is broken, but it's not like we can ignore the issue. So, unless I'm very much mistaken, the NAT/PAT issues are going to have to be dealt with. Or do you propose an alternative solution? Please note that this is not an anti-IPv6 stance. To me it looks like the problems plaguing NAT444 need to be solved just to make IPv4 and IPv6 co-exist. Perhaps not the very same problems, but similar NAT/PAT problems in any case. Please do tell me I'm wrong. Bonus points for explaining why I am wrong or how the IPv4/IPv6 thing is to be solved without NAT/PAT. - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 7:34 AM, Zed Usser wrote: --- On Fri, 2/18/11, Owen DeLong o...@delong.com wrote: Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions. Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely. That depends on the number of IPv4 only networks vs. dual stack networks when that happens. Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is broken in a number of ways, many of which are documented in the draft. We agree that IPv4/IPv6 domain interoperability is broken, but it's not like we can ignore the issue. So, unless I'm very much mistaken, the NAT/PAT issues are going to have to be dealt with. Or do you propose an alternative solution? Dual stacking all the IPv4 networks is the alternative solution. Initially it will be the IPv6 only users that are lonely. Relatively quickly, it will be the IPv4 only networks that are lonely as the bulk of users will, I suspect, become IPv6 preferred relatively quickly once there is no more IPv4 at the RIR level. Please note that this is not an anti-IPv6 stance. To me it looks like the problems plaguing NAT444 need to be solved just to make IPv4 and IPv6 co-exist. Perhaps not the very same problems, but similar NAT/PAT problems in any case. Please do tell me I'm wrong. Bonus points for explaining why I am wrong or how the IPv4/IPv6 thing is to be solved without NAT/PAT. I think that effort spent trying to solve those problems is better spent moving existing IPv4 things forward to dual stack. You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Move them to dual stack and the problem goes away. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 10:34 AM, Zed Usser zzu...@yahoo.com wrote: Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely. I suspect Google, Microsoft, and others have already figured out a beneficial (to everyone) way to monetize this. If I'm an ISP with working IPv6, and my competitor in a given region is an ISP without IPv6, I'd like to advertise to all the end-users of that ISP whenever they go to a search engine that sells ads. Since these search engine companies have figured out white-listing users into good IPv6, it's no great leap to suggest that they'll eventually black-list IPv4 users into bad, and tie that into their advertising system for ISPs to purchase nicely-targeted banners/links. If my ISP is reading this, please tell both your residential and business technical and sales departments to come up with a better answer than we are not going to support IPv6 because that's only for ISPs that run out of IPv4. Otherwise, I'd bet Google will be more than willing to let your competitors give customers a different answer in the near future! -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Sat, 2/19/11, Owen DeLong o...@delong.com wrote: You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote: On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64 I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while technically accurate isn't particulrarly meaningful. The document is titled Assessing the Impact of NAT444 on Network Applications and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN. http://www.ietf.org/mail-archive/web/behave/current/msg09027.html Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) I guess that depends on whether you like having customers or not. Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice). Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 12:50 PM, Zed Usser wrote: --- On Sat, 2/19/11, Owen DeLong o...@delong.com wrote: You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? - Zed No, but, I am willing to bet that we will not meaningfully make the situation better for those IPv4-only hosts or the IPv6-only hosts attempting to reach them by any mechanism more efficient than encouraging them to add IPv6 capability, whether or not that happens after the fact. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote: On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote: On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64 I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while technically accurate isn't particulrarly meaningful. The document is titled Assessing the Impact of NAT444 on Network Applications and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN. NAT444 is one implementation of CGN and the issues it describes all apply to NAT444. It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses apply to NAT444. That claim is accurate. http://www.ietf.org/mail-archive/web/behave/current/msg09027.html Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) I guess that depends on whether you like having customers or not. Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice). I remain unconvinced of the accuracy of this statement. Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution. Absolutely. Also, I think the intent of the draft is to serve as a further heads-up to content and application providers that their customer experience in a NAT-444 environment is going to suck and they need to deploy IPv6. Further, it also serves to provide a guide for help-desks to deal with the consequences of having deployed a NAT444 solution in their network. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 4:46 PM, Owen DeLong wrote: On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote: The document is titled Assessing the Impact of NAT444 on Network Applications and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN. NAT444 is one implementation of CGN and the issues it describes all apply to NAT444. It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses apply to NAT444. That claim is accurate. You continue to conflate NAT444 and CGN. I'm not sure I can say anything that hasn't already been said, but perhaps an example will help: Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better. Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice). I remain unconvinced of the accuracy of this statement. Well, if your user does nothing but send email then perhaps even UUCP would be good enough. But for the rest of us, until IPv6 penetration reaches all the content/services we care about, we need dual v4+v6 connectivity. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 16:48, Benson Schliesser bens...@queuefull.net wrote: I agree that it's an imperfect analogy, so I won't bother defending it. :) But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of transition (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it. That I'll agree with. It seems to me that what's called for is an expansion of the tests done for the draft in question to include other, currently in-vogue, CGN/LSN technologies. So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion. That wasn't the conclusion I drew, can't speak for others of course. My conclusion is that CGN/LSN is broken, as evidenced by brokenness in NAT444. I agree that a comparison of all (or some reasonable subset of all) LSN technologies would be valuable, especially as folks may begin to be forced to choose one. For now I stick with the ideal: Avoid if possible. (Dual-stack early, dual-stack often?) If we get dual v4+v6 connectivity quickly enough, we do not need LSN (including NAT444). Amen, brother. I guess I'm just pessimistic about the definition of quickly versus operationally realistic timeframes. Fair enough, I still have hope. =) ~Chris Cheers, -Benson -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 5:59 PM, Chris Grundemann wrote: On Fri, Feb 18, 2011 at 16:48, Benson Schliesser bens...@queuefull.net wrote: I agree that it's an imperfect analogy, so I won't bother defending it. :) But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of transition (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it. That I'll agree with. It seems to me that what's called for is an expansion of the tests done for the draft in question to include other, currently in-vogue, CGN/LSN technologies. That's a serious expansion to the testing matrix. I would rather see those other technologies get their own draft with their own testing matrix as this is far more likely to be achievable. So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion. That wasn't the conclusion I drew, can't speak for others of course. My conclusion is that CGN/LSN is broken, as evidenced by brokenness in NAT444. I agree that a comparison of all (or some reasonable subset of all) LSN technologies would be valuable, especially as folks may begin to be forced to choose one. For now I stick with the ideal: Avoid if possible. (Dual-stack early, dual-stack often?) Agreed. If we get dual v4+v6 connectivity quickly enough, we do not need LSN (including NAT444). Amen, brother. I guess I'm just pessimistic about the definition of quickly versus operationally realistic timeframes. Fair enough, I still have hope. =) ~Chris My thinking is that faced with disconnection after the fact suddenly causing me to choose between restoration by dual stacking vs. restoration by NAT444 (or almost any other form of LSN) leads any sane person to restoration by dual stacking. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 11 feb 2011, at 17:51, William Herrin wrote: We can't backport ULA into IPv4 private addressing; there aren't enough addresses for the math to work. So we either make such folks jump through all kinds of hoops to get their networks to function, or we assign addresses that could otherwise be used on the big-I Internet. Not that it matters because it's too late now and it would only give us a few more months, but: Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 7:39 AM, Iljitsch van Beijnum wrote: Not that it matters because it's too late now and it would only give us a few more months, but: Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap. Again, I note that we've collectively allocated the 95%+ of the address space which was made available outside of DoD's original blocks, and then considering that US DoD additionally returned 2 more /8's for the community (noted here: http://blog.icann.org/2008/02/recovering-ipv4-address-space/), I believe they've shown significant consideration to the Internet community. The fact that any particular prefix today isn't in your particular routing table does not imply that global uniqueness isn't desired. Rather than saying 240/4 is unusable for another three years, perhaps the service provider community could make plain that this space needs to be made usable (ala http://tools.ietf.org/html/draft-fuller-240space-02 or http://tools.ietf.org/html/draft-wilson-class-e-00, etc.) on a priority basis and work with the operating system and vendor community actually to make this happen? There's a chance that it could be made usable with sufficient focus to make that happen, but it is assured not to be usable if eternally delayed because it is too hard to accomplish. /John (my views alone; 100% recycled electrons used in this message)
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message 54cc2b0d-eae0-4b79-af19-20bbd233a...@istaff.org, John Curran writes: On Feb 17, 2011, at 7:39 AM, Iljitsch van Beijnum wrote: Not that it matters because it's too late now and it would only give = us a few more months, but: =20 Does the US government really need more than 150 million addresses, of = which about half are not publically routed? Non-publically routed = addresses can be reused by others as long as the stuff both users = connect to doesn't overlap. Again, I note that we've collectively allocated the 95%+ of the address=20= space which was made available outside of DoD's original blocks, and = then considering that US DoD additionally returned 2 more /8's for the = community=20 (noted here: = http://blog.icann.org/2008/02/recovering-ipv4-address-space/),=20 I believe they've shown significant consideration to the Internet = community. The fact that any particular prefix today isn't in your particular = routing=20 table does not imply that global uniqueness isn't desired. Rather than saying 240/4 is unusable for another three years, perhaps = the service provider community could make plain that this space needs to be=20= made usable (ala http://tools.ietf.org/html/draft-fuller-240space-02 or=20= http://tools.ietf.org/html/draft-wilson-class-e-00, etc.) on a priority=20= basis and work with the operating system and vendor community actually to make this happen? There's a chance that it could be made usable with=20= sufficient focus to make that happen, but it is assured not to be usable if eternally delayed because it is too hard to accomplish. /John (my views alone; 100% recycled electrons used in this message) It's not usable as general purpose unicast. Both those drafts attempt to do that. It would be possible to use it as restricted purpose unicast, i.e. to connect from a cpe border router to a 6rd and/or LSN with the cpe border router signaling that it support the use of class E addresses when it requests a address from upstream. The upsteam only returns a class E address when it is sure that the network between the LSN/6rd supports class E traffic. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 4:39 AM, Iljitsch van Beijnum wrote: On 11 feb 2011, at 17:51, William Herrin wrote: We can't backport ULA into IPv4 private addressing; there aren't enough addresses for the math to work. So we either make such folks jump through all kinds of hoops to get their networks to function, or we assign addresses that could otherwise be used on the big-I Internet. Not that it matters because it's too late now and it would only give us a few more months, but: Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap. The DoD does not seem particularly anxious to announce or explain their usage of those blocks to the rest of the community. They have much larger quantities of significantly more sophisticated armaments than ARIN. I agree it would be nice if they would voluntarily return whatever is appropriate to the community, but, as you say, there is little upside to them doing so anyway. Certainly not enough to make the risks of attempting to obtain it through any means other than voluntary return feasible or even worthy of consideration. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, 17 Feb 2011 08:08:50 EST, John Curran said: Rather than saying 240/4 is unusable for another three years, perhaps the service provider community could make plain that this space needs to be made usable In other words, you're going to tell Granny she needs to upgrade to Windows 8 and/or replace her CPE because you couldn't get your act together and deploy IPv6 - even though her friends at the bridge club who are customers of your clued competitor didn't have to do a thing. And then she has to do something *else* 9 months later when you need to deploy IPv6 *anyhow*. I encourage my competitors to design their business plans that way. :) pgpckK4CUIHuj.pgp Description: PGP signature
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 9:32 AM, valdis.kletni...@vt.edu wrote: On Thu, 17 Feb 2011 08:08:50 EST, John Curran said: Rather than saying 240/4 is unusable for another three years, perhaps the service provider community could make plain that this space needs to be made usable In other words, you're going to tell Granny she needs to upgrade to Windows 8 and/or replace her CPE because you couldn't get your act together and deploy IPv6 - even though her friends at the bridge club who are customers of your clued competitor didn't have to do a thing. Not, what I'm saying is that we've been considering this matter for more than 10 years, and as old as her machine is, it would have been patched once since then if we had bothered to note that Reserved for Future Use should be treated as unicast space. The same argument applies now: unless there is a reason to save 240/8, it should at least be redefined to be usable in some manner so that we don't repeat the same argument 5 years from now. /John
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/17/2011 10:24 AM, Steven Bellovin wrote: It might be worth doing for ISP backbones, and for things like tunnel endpoints. For anything else, it's not worth the effort -- and I suspect never was. I think several people's point is that it may be useful for the CGN/LSN numbering and other special case scenarios where a CPE might be compliant and the windows box would be ignorant. Jack
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In other words, you're going to tell Granny she needs to upgrade to Windows 8 and/or replace her CPE because you couldn't get your act together and deploy IPv6 - even though her friends at the bridge club who are customers of your clued competitor didn't have to do a thing. Or tell her to run Windows Update and get the latest update for her existing OS which has the patch. And then she has to do something *else* 9 months later when you need to deploy IPv6 *anyhow*. Maybe, maybe not. It depends on how it is deployed. That something else might be as simple as reboot the computer. I encourage my competitors to design their business plans that way. :) Considering v4 is likely to be around for another decade or two, getting Class E into general use seems easy enough to do.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 11:28 AM, Jack Bates wrote: On 2/17/2011 10:24 AM, Steven Bellovin wrote: It might be worth doing for ISP backbones, and for things like tunnel endpoints. For anything else, it's not worth the effort -- and I suspect never was. I think several people's point is that it may be useful for the CGN/LSN numbering and other special case scenarios where a CPE might be compliant and the windows box would be ignorant. Jack - There's numerous applications, including expanding internal applications such as virtualized servers for which the address space might be useful, if it was actually defined as usable as unicast. Apparently, it is also the case that the operator community wouldn't recognize the usage restrictions that might apply due to the recent reclassification, and would badly hurt themselves by making use of the space inappropriately. Thus, it is deemed better that nobody have use of the 1/16 of the IPv4 space (even if your internal use is perfectly compatible) because some who won't understand might get hurt... ;-) /John
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, Feb 17, 2011 at 5:08 AM, John Curran jcur...@istaff.org wrote: On Feb 17, 2011, at 7:39 AM, Iljitsch van Beijnum wrote: Not that it matters because it's too late now and it would only give us a few more months, but: Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap. Again, I note that we've collectively allocated the 95%+ of the address space which was made available outside of DoD's original blocks, and then considering that US DoD additionally returned 2 more /8's for the community (noted here: http://blog.icann.org/2008/02/recovering-ipv4-address-space/), I believe they've shown significant consideration to the Internet community. The fact that any particular prefix today isn't in your particular routing table does not imply that global uniqueness isn't desired. Rather than saying 240/4 is unusable for another three years, perhaps the service provider community could make plain that this space needs to be made usable (ala http://tools.ietf.org/html/draft-fuller-240space-02 or http://tools.ietf.org/html/draft-wilson-class-e-00, etc.) on a priority basis and work with the operating system and vendor community actually to make this happen? There's a chance that it could be made usable with sufficient focus to make that happen, but it is assured not to be usable if eternally delayed because it is too hard to accomplish. +1 If you want to go on a wild goose chase, start chasing down 240/4 and you might make some progress. As i have mentioned before, it was only after i gave up on 240/4 for private network numbering that i really earnestly took on IPv6-only as a strategy. Seeing 240/4 actually work would be nice, but i have already concluded it does not fit my exhaustion timeline given how many edge devices will never support it. If i have to fork lift, it should be for ipv6. Cameron === http://groups.google.com/group/tmoipv6beta === /John (my views alone; 100% recycled electrons used in this message)
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Mark Andrews ma...@isc.org writes: It's not usable as general purpose unicast. Both those drafts attempt to do that. http://tools.ietf.org/html/draft-wilson-class-e-00 does not. Recommend you re-read. It would be possible to use it as restricted purpose unicast, i.e. to connect from a cpe border router to a 6rd and/or LSN with the cpe border router signaling that it support the use of class E addresses when it requests a address from upstream. The upsteam only returns a class E address when it is sure that the network between the LSN/6rd supports class E traffic. The contemporary discussions we had on this subject centered around management infrastructure for MSOs, not 6rd (which was still a twinkle in the Bad Idea Fairy's eye at the time). Not speaking for Paul here, but it was not our intention to box in possible use of this space, only to mark it as sufficiently toxic that end users and normal enterprises would stay away. Would be great for 6rd if that's what folks wanted to use it for and could get the CPE vendors to cooperate. -r
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
If you want to go on a wild goose chase, start chasing down 240/4 and you might make some progress. As i have mentioned before, it was only after i gave up on 240/4 for private network numbering that i really earnestly took on IPv6-only as a strategy. Seeing 240/4 actually work would be nice, but i have already concluded it does not fit my exhaustion timeline given how many edge devices will never support it. If i have to fork lift, it should be for ipv6. 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Owen DeLong o...@delong.com writes: The DoD does not seem particularly anxious to announce or explain their usage of those blocks to the rest of the community. They have much larger quantities of significantly more sophisticated armaments than ARIN. I agree it would be nice if they would voluntarily return whatever is appropriate to the community, but, You mean like they already did with 49/8, 50/8 (both formerly Joint Technical Command), 10/8 (formerly ARPAnet), and 7/8 (DNIC)? As the biggest returner of IPv4 space by a fair margin, notwithstanding their current holdings I think the DoD is quite justified in saying I gave at the office and hanging up. -r
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, Feb 17, 2011 at 9:46 AM, George Bonser gbon...@seven.com wrote: If you want to go on a wild goose chase, start chasing down 240/4 and you might make some progress. As i have mentioned before, it was only after i gave up on 240/4 for private network numbering that i really earnestly took on IPv6-only as a strategy. Seeing 240/4 actually work would be nice, but i have already concluded it does not fit my exhaustion timeline given how many edge devices will never support it. If i have to fork lift, it should be for ipv6. 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already. Yep, and that's great. Let me know when a Cisco 7600 will route a packet like this. Cameron
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 12:48 PM, Cameron Byrne wrote: 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already. Yep, and that's great. Let me know when a Cisco 7600 will route a packet like this. So, it won't work for you. Is there any reason that it shouldn't be defined as unicast or private use (with warnings) rather than Future Use, so that those who might have a use for it can do so? /John
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already. Yep, and that's great. Let me know when a Cisco 7600 will route a packet like this. Cameron Considering how small of a change it is, simply removing that net from the black list, they could do it at any time with a code update to any version of IOS, provided that black list isn't burned into hardware. George
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, Feb 17, 2011 at 9:51 AM, John Curran jcur...@istaff.org wrote: On Feb 17, 2011, at 12:48 PM, Cameron Byrne wrote: 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already. Yep, and that's great. Let me know when a Cisco 7600 will route a packet like this. So, it won't work for you. Is there any reason that it shouldn't be defined as unicast or private use (with warnings) rather than Future Use, so that those who might have a use for it can do so? I am 100% pro making Class E defined as private unicast space. My only point is that people need to be realistic about the near term benefit. Yes, some linux may work. But, Microsoft and Cisco don't work today. Let's move it to not-reserved, but don't bet the farm on 240/4 solving any of your problems or in any way changing the need to for IPv6 migration. This is where the slipperly slope and expectation settings start. Cameron
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 12:46 PM, Robert E. Seastrom wrote: Owen DeLong o...@delong.com writes: ... I agree it would be nice if they would voluntarily return whatever is appropriate to the community, but, You mean like they already did with 49/8, 50/8 (both formerly Joint Technical Command), 10/8 (formerly ARPAnet), and 7/8 (DNIC)? As the biggest returner of IPv4 space by a fair margin, notwithstanding their current holdings I think the DoD is quite justified in saying I gave at the office and hanging up. Actually, as I have noted before, the US DoD has contractually agreed to return to ARIN unneeded IPv4 address space if/when such becomes available, so that it may be used by the Internet community. /John John Curran President and CEO ARIN
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
I am 100% pro making Class E defined as private unicast space. My only point is that people need to be realistic about the near term benefit. Yes, some linux may work. But, Microsoft and Cisco don't work today. Let's move it to not-reserved, but don't bet the farm on 240/4 solving any of your problems or in any way changing the need to for IPv6 migration. This is where the slipperly slope and expectation settings start. Cameron Considering the amount of linux-based CPE and other network hardware out there (including some Cisco gear), the extent to which it might be usable today could be surprising.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, Feb 17, 2011 at 9:52 AM, George Bonser gbon...@seven.com wrote: 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already. Yep, and that's great. Let me know when a Cisco 7600 will route a packet like this. Cameron Considering how small of a change it is, simply removing that net from the black list, they could do it at any time with a code update to any version of IOS, provided that black list isn't burned into hardware. I asked 2 years ago, and i was told it was not feasible. I escalated, still no-go, it was a deep problem. And they pointed to the IETF saying no on the above drafts as reason to not dig into the microcode or whatever to fix it. This is where i turned to the IPv6-only reality of the future near-term internet. I suggest you do the same. Cisco is just one example. The fact is it will likely not work in cell phones, home gateways, windows PCs, Mac's, I understand some progress has been made... but choose your scope wisely and pick your battles and know that the weight of the world is against you (cisco and msft) Let me remind you, i believe opening 240/4 for private unicast was a good ideas years ago. It is still not a bad idea, what's the harm? But ... the answer you will hear is that IPv6 has momentum, go with the flow. Using 240/4 is much better than providing a public allocation to private networks. It properly makes folks consider the reality of staying with broken ipv4 or making the much better long term investment in IPv6. @George Please don't speculating on when Cisco or Microsoft will support 240/4 on this list. Ask your account rep, then report back with facts. Arm-chair engineering accounts for too many emails on this list. Cameron = http://groups.google.com/group/tmoipv6beta =
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, Feb 17, 2011 at 1:05 PM, Cameron Byrne cb.li...@gmail.com wrote: On Thu, Feb 17, 2011 at 9:52 AM, George Bonser gbon...@seven.com wrote: 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already. Yep, and that's great. Let me know when a Cisco 7600 will route a packet like this. Cameron Considering how small of a change it is, simply removing that net from the black list, they could do it at any time with a code update to any version of IOS, provided that black list isn't burned into hardware. I asked 2 years ago, and i was told it was not feasible. I escalated, still no-go, it was a deep problem. And they pointed to the IETF saying no on the above drafts as reason to not dig into the microcode or whatever to fix it. This is where i turned to the IPv6-only reality of the future near-term internet. I suggest you do the same. Cisco is just one example. The fact is it will likely not work in cell phones, home gateways, windows PCs, Mac's, I understand some progress has been made... but choose your scope wisely and pick your battles and know that the weight of the world is against you (cisco and msft) Let me remind you, i believe opening 240/4 for private unicast was a good ideas years ago. It is still not a bad idea, what's the harm? But ... the answer you will hear is that IPv6 has momentum, go with the flow. Using 240/4 is much better than providing a public allocation to private networks. It properly makes folks consider the reality of staying with broken ipv4 or making the much better long term investment in IPv6. @George Please don't speculating on when Cisco or Microsoft will support 240/4 on this list. Ask your account rep, then report back with facts. Arm-chair engineering accounts for too many emails on this list. Cameron = http://groups.google.com/group/tmoipv6beta = IPv6's momentum is a lot like a beach landing at Normandy. -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
I asked 2 years ago, and i was told it was not feasible. I escalated, still no-go, it was a deep problem. And they pointed to the IETF saying no on the above drafts as reason to not dig into the microcode or whatever to fix it. Ok, so that implies that it is burned into hardware and as it is ASIC-based hardware and not FPGA, they can't reprogram the hardware with a code update (one of the advantages of FPGA-based hardware). Cisco is just one example. The fact is it will likely not work in cell phones, home gateways, windows PCs, Mac's, I understand some progress has been made... but choose your scope wisely and pick your battles and know that the weight of the world is against you (cisco and msft) I don't think I had general usage in mind, more along the lines of the middle 4 in NAT444 that will be rolled out in many networks to conserve IP space. @George Please don't speculating on when Cisco or Microsoft will support 240/4 on this list. Ask your account rep, then report back with facts. Arm-chair engineering accounts for too many emails on this list. The usage I have in mind would be transparent to the end stations and, frankly, someone who produces provider gear and CPE that can take advantage of that space is going to have a great selling point. There is some gold under there for someone. 240/4 is a great big dig here sign if they want some of it.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/17/2011 1:31 PM, Jeffrey Lyon wrote: IPv6's momentum is a lot like a beach landing at Normandy. As in, large, dedicated, and nigh unstoppable, but fraught with peril and with a lot of mess and destruction to get through before it is done, or as in mainly opposed by aging crazy Nazis who should have seen it coming but kept their attention in the wrong place?
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 9:57 AM, John Curran wrote: On Feb 17, 2011, at 12:46 PM, Robert E. Seastrom wrote: Owen DeLong o...@delong.com writes: ... I agree it would be nice if they would voluntarily return whatever is appropriate to the community, but, You mean like they already did with 49/8, 50/8 (both formerly Joint Technical Command), 10/8 (formerly ARPAnet), and 7/8 (DNIC)? As the biggest returner of IPv4 space by a fair margin, notwithstanding their current holdings I think the DoD is quite justified in saying I gave at the office and hanging up. As they are also the biggest consumer of IPv4 space by a fair margin, that statement rings a bit hollow. Actually, as I have noted before, the US DoD has contractually agreed to return to ARIN unneeded IPv4 address space if/when such becomes available, so that it may be used by the Internet community. This statement, on the other hand, is a good thing. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
IPv6's momentum is a lot like a beach landing at Normandy. ?? Inevitably going to succeed, but, not without heavy losses in the process? Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, Feb 17, 2011 at 2:14 PM, Owen DeLong o...@delong.com wrote: IPv6's momentum is a lot like a beach landing at Normandy. ?? Inevitably going to succeed, but, not without heavy losses in the process? Owen Yes, and also with mass fear and confusion at the beginning. -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/17/2011 1:25 PM, Jeffrey Lyon wrote: On Thu, Feb 17, 2011 at 2:14 PM, Owen DeLongo...@delong.com wrote: IPv6's momentum is a lot like a beach landing at Normandy. ?? Inevitably going to succeed, but, not without heavy losses in the process? Owen Yes, and also with mass fear and confusion at the beginning. Given the heavy losses and chaotic nature of the event, wasn't mass fear and confusion to be expected? Jack
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, Feb 17, 2011 at 2:48 PM, Jack Bates jba...@brightok.net wrote: On 2/17/2011 1:25 PM, Jeffrey Lyon wrote: On Thu, Feb 17, 2011 at 2:14 PM, Owen DeLongo...@delong.com wrote: IPv6's momentum is a lot like a beach landing at Normandy. ?? Inevitably going to succeed, but, not without heavy losses in the process? Owen Yes, and also with mass fear and confusion at the beginning. Given the heavy losses and chaotic nature of the event, wasn't mass fear and confusion to be expected? Jack At Normandy or on 2/3/11? -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message AANLkTi=uzeqb2dykxhvrxakfasphgfdmxjp1p-gj0...@mail.gmail.com, Came ron Byrne writes: On Thu, Feb 17, 2011 at 5:08 AM, John Curran jcur...@istaff.org wrote: On Feb 17, 2011, at 7:39 AM, Iljitsch van Beijnum wrote: Not that it matters because it's too late now and it would only give us = a few more months, but: Does the US government really need more than 150 million addresses, of w= hich about half are not publically routed? Non-publically routed addresses = can be reused by others as long as the stuff both users connect to doesn't = overlap. Again, I note that we've collectively allocated the 95%+ of the address space which was made available outside of DoD's original blocks, and then considering that US DoD additionally returned 2 more /8's for the communi= ty (noted here: http://blog.icann.org/2008/02/recovering-ipv4-address-space= /), I believe they've shown significant consideration to the Internet communi= ty. The fact that any particular prefix today isn't in your particular routin= g table does not imply that global uniqueness isn't desired. Rather than saying 240/4 is unusable for another three years, perhaps the service provider community could make plain that this space needs to be made usable (ala http://tools.ietf.org/html/draft-fuller-240space-02 or http://tools.ietf.org/html/draft-wilson-class-e-00, etc.) on a priority basis and work with the operating system and vendor community actually to make this happen? =A0There's a chance that it could be made usable wit= h sufficient focus to make that happen, but it is assured not to be usable if eternally delayed because it is too hard to accomplish. +1 If you want to go on a wild goose chase, start chasing down 240/4 and you might make some progress. As i have mentioned before, it was only after i gave up on 240/4 for private network numbering that i really earnestly took on IPv6-only as a strategy. Seeing 240/4 actually work would be nice, but i have already concluded it does not fit my exhaustion timeline given how many edge devices will never support it. If i have to fork lift, it should be for ipv6. You can reflash CPE devices to support this that you can't reflash to support IPv6 as there is no space in the flash for the extra code. This should be minimal. A extra PPP/DHCP option and a check box to enable (default) / disable setting it. It can be deployed incrementally. It enables IPv6 to be deployed over intermediate hardware that doesn't support IPv4. You still need lots of IPv4 to do that. It doesn't however have to be globally unique and it shouldn't be RFC 1918. Leave RFC 1918 for customers. You add IPv6 support to CPE devices where you can. It doesn't require the world to upgrade. It gives a well defined range that you don't use with 6to4. We also don't need all of class E. The first half would be more than enough for even the biggest ISP. It's big enough to give customers stable IPv6 addresses via 6rd. Mark Cameron =3D=3D=3D=3D=3D=3D=3D http://groups.google.com/group/tmoipv6beta =3D=3D=3D=3D=3D=3D=3D /John (my views alone; 100% recycled electrons used in this message) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message 32ecc9cd-d927-4407-914c-751316c59...@istaff.org, John Curran write s: On Feb 17, 2011, at 12:48 PM, Cameron Byrne wrote: 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already. Yep, and that's great. Let me know when a Cisco 7600 will route a packet like this. So, it won't work for you. Is there any reason that it shouldn't be defined as unicast or private use (with warnings) rather than Future Use, so that those who might have a use for it can do so? /John Or to ask CISCO to fix the box so it can route it? In many cases it is a minimal change. I don't know whether it is in Cisco 7600 but it can't hurt to ask the vendors if it is technically possible. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Mark Andrews expunged (ma...@isc.org): Or to ask CISCO to fix the box so it can route it? In many cases it is a minimal change. I don't know whether it is in Cisco 7600 They are in the business of selling new gear, not enabling features on EOL equipment :) -Steve
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
You can reflash CPE devices to support this that you can't reflash to support IPv6 as there is no space in the flash for the extra code. This should be minimal. A extra PPP/DHCP option and a check box to enable (default) / disable setting it. Reflashing most CPE amounts to forklifting. The difference between having them bring their CPE in to be reflashed or rolling a truck to do same vs. replacing the CPE will, in most cases, actually render replacing the CPE cheaper. It can be deployed incrementally. So can replacing the CPE, but, neither is a particularly attractive alternative for many providers. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message 5f90644c-5457-460f-9bc3-70802b13a...@delong.com, Owen DeLong write s: Cisco is just one example. The fact is it will likely not work in cell phones, home gateways, windows PCs, Mac's, I understand some progress has been made... but choose your scope wisely and pick your battles and know that the weight of the world is against you (cisco and msft) I don't think I had general usage in mind, more along the lines of the middle 4 in NAT444 that will be rolled out in many networks to conserve IP space. Infeasible. NAT444 is primarily needed to avoid doing a CPE forklift for nearly every subscriber. To deploy these addresses in that space would require a CPE forklift for nearly every subscriber. Firstly it is entirely possible to do this incrementally. Secondly it doesn't require a fork lift upgrade. A minimal upgrade is all that is required. For modern Linux boxes just setting a DHCP option would be enough. A two line fix in a config file. @George Please don't speculating on when Cisco or Microsoft will support 240/4 on this list. Ask your account rep, then report back with facts. Arm-chair engineering accounts for too many emails on this list. The usage I have in mind would be transparent to the end stations and, frankly, someone who produces provider gear and CPE that can take advantage of that space is going to have a great selling point. There is some gold under there for someone. 240/4 is a great big dig here sign if they want some of it. Maybe, but, CPE is rarely a unified solution, even within the same carrier. Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message 20110217203922.gb3...@mara.org, Steve Meuse writes: Mark Andrews expunged (ma...@isc.org): Or to ask CISCO to fix the box so it can route it? In many cases it is a minimal change. I don't know whether it is in Cisco 7600 They are in the business of selling new gear, not enabling features on EOL eq uipment :) -Steve Sometime the good will generated is worth the minor expense. Remember a lot of this problem is the direct result of vendors not acting soon enough and that includes CISCO. Asking those vendors to do a bit of work to fixup the results of their bad decisions is not unreasonable. They can't fix hardware limitations but they can definitely fix software limitations. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 4:57 PM, Mark Andrews wrote: In message 20110217203639.ga3...@mara.org, Steve Meuse writes: George Bonser expunged (gbon...@seven.com): Considering the amount of linux-based CPE and other network hardware out there (including some Cisco gear), the extent to which it might be usable today could be surprising. An how many of those embedded linux devices are running a 2.4 kernel? Just lo ok at xx-wrt as an example. If you have a certain chipset, 2.4 is your only o ption. And the work to patch that kernel is minimal if it doesn't already support it. It would take less time to fix the kernel than to argue over whether to fix it. -Steve -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org But way way way more time to deploy the patched kernel than to forklift the devices with IPv6 capable ones which don't require patching the kernel, either. The kernel patch is, at best, an expensive stop gap. At worst, it is a counter productive waste of time. At best it's slightly short of break-even. At worst, it's a huge $negative. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message 1dbdca5f-16ec-428d-bc46-3bd59a6f4...@delong.com, Owen DeLong write s: You can reflash CPE devices to support this that you can't reflash to support IPv6 as there is no space in the flash for the extra code. This should be minimal. A extra PPP/DHCP option and a check box to enable (default) / disable setting it. Reflashing most CPE amounts to forklifting. The difference between having them bring their CPE in to be reflashed or rolling a truck to do same vs. replacing the CPE will, in most cases, actually render replacing the CPE cheaper. It depends on the CPE device. Lots of CPE devices can be re-flashed in place. It just requires the will to make the images available. It can be deployed incrementally. So can replacing the CPE, but, neither is a particularly attractive alternative for many providers. And further indecision is going to make this worse not better. Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 5:18 PM, Mark Andrews wrote: In message 1dbdca5f-16ec-428d-bc46-3bd59a6f4...@delong.com, Owen DeLong write s: You can reflash CPE devices to support this that you can't reflash to support IPv6 as there is no space in the flash for the extra code. This should be minimal. A extra PPP/DHCP option and a check box to enable (default) / disable setting it. Reflashing most CPE amounts to forklifting. The difference between having them bring their CPE in to be reflashed or rolling a truck to do same vs. replacing the CPE will, in most cases, actually render replacing the CPE cheaper. It depends on the CPE device. Lots of CPE devices can be re-flashed in place. It just requires the will to make the images available. Who do you think is going to do this reflashing? If you think that Grandma is going to download an image and reflash her linksys, you're at least slightly divorced from reality. If you think she's going to do it and not have about a 10% brick rate (10% of devices going from router to brick) as a result, then, you're optimistic to say the least. It can be deployed incrementally. So can replacing the CPE, but, neither is a particularly attractive alternative for many providers. And further indecision is going to make this worse not better. On this we agree... Which is why we should decide to move to IPv6 and get on with it instead of continuing to pursue rat-holes like 240/4. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 17, 2011, at 4:52 PM, Mark Andrews wrote: In message 5f90644c-5457-460f-9bc3-70802b13a...@delong.com, Owen DeLong write s: Cisco is just one example. The fact is it will likely not work in cell phones, home gateways, windows PCs, Mac's, I understand some progress has been made... but choose your scope wisely and pick your battles and know that the weight of the world is against you (cisco and msft) I don't think I had general usage in mind, more along the lines of the middle 4 in NAT444 that will be rolled out in many networks to conserve IP space. Infeasible. NAT444 is primarily needed to avoid doing a CPE forklift for nearly every subscriber. To deploy these addresses in that space would require a CPE forklift for nearly every subscriber. Firstly it is entirely possible to do this incrementally. Secondly it doesn't require a fork lift upgrade. A minimal upgrade is all that is required. For modern Linux boxes just setting a DHCP option would be enough. A two line fix in a config file. Whether you do it incrementally or not, you have to upgrade every affected device eventually. You can roll out IPv6 incrementally, too. Most CPE is _NOT_ within the description of modern linux boxes so does not apply to the discussion of the middle 4 in NAT444. It may not require an actual forklift upgrade, but, in the real world, it will require ISP efforts that are equivalent to a forklift upgrade, so, if you're going to that much trouble, it's cheaper (and in many cases easier) to go ahead and forklift your way to IPv6. Ideally in the next round of CPE, the need for NAT444 is a non-issue. It should support at least DS-Lite or 6rd. Anything earlier than the next round of equipment will need to be at least re-flashed. Owen
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
But way way way more time to deploy the patched kernel than to forklift the devices with IPv6 capable ones which don't require patching the kernel, either. The kernel patch is, at best, an expensive stop gap. At worst, it is a counter productive waste of time. At best it's slightly short of break-even. At worst, it's a huge $negative. Owen I don't think anyone was proposing it as an alternative to v6. It is more along the lines of keeping the existing v4 net working as people migrate over. Freeing up WAN IPs can make them available for v6 migration purposes. The ironic thing about v6 is that it will require some additional v4 addresses during the migration period.
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Thu, Feb 10, 2011 at 14:17, Benson Schliesser bens...@queuefull.net wrote: If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 Cheers, ~Chris Regardless, I think we can agree that IPv6 is the way to avoid NAT-related growing pains. We've known this for a long time. Cheers, -Benson ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (arin-p...@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues. -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message c02476ce-0544-430e-bb70-b752406ad...@delong.com, Owen DeLong write s: On Feb 17, 2011, at 5:18 PM, Mark Andrews wrote: =20 In message 1dbdca5f-16ec-428d-bc46-3bd59a6f4...@delong.com, Owen = DeLong write s: =20 You can reflash CPE devices to support this that you can't reflash to support IPv6 as there is no space in the flash for the extra code. This should be minimal. A extra PPP/DHCP option and a check box to enable (default) / disable setting it. =20 Reflashing most CPE amounts to forklifting. The difference between having them bring their CPE in to be reflashed or rolling a truck to do same vs. replacing the CPE will, in most cases, actually render replacing the CPE cheaper. =20 It depends on the CPE device. Lots of CPE devices can be re-flashed in place. It just requires the will to make the images available. =20 Who do you think is going to do this reflashing? If you think that = Grandma is going to download an image and reflash her linksys, you're at least slightly divorced from reality. I think grandma is quite capable of doing it. She just needs to be informed that it needs to be done. Most people that are scared of doing it themselves have someone that they can call on to do it for them. It also doesn't have to be 100%. If you think she's going to do it and not have about a 10% brick rate (10% of devices going from router to brick) as a result, then, you're optimistic to say the least. Reflashing with manufacture supplied images doesn't have a 10% brick rate. It can be deployed incrementally. =20 So can replacing the CPE, but, neither is a particularly attractive alternative for many providers. =20 And further indecision is going to make this worse not better. =20 On this we agree... Which is why we should decide to move to IPv6 and get on with it instead of continuing to pursue rat-holes like 240/4. 240/4 is actually an enabler for IPv6. It allows the operator to give the customer a stable IPv4 address which can be used for stable IPv6 addresses via 6rd. Different parts upgrade at different times and we need to de-couple all those upgrades if we can. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Mark Andrews expunged (ma...@isc.org): An how many of those embedded linux devices are running a 2.4 kernel? Just lo ok at xx-wrt as an example. If you have a certain chipset, 2.4 is your only o ption. And the work to patch that kernel is minimal if it doesn't already support it. It would take less time to fix the kernel than to argue over whether to fix it. The point is just because it's running linux doesn't make it any more likely to get upgraded than joe six pack is going to update/patch his windows XP. -Steve
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Mark Andrews expunged (ma...@isc.org): Remember a lot of this problem is the direct result of vendors not acting soon enough and that includes CISCO. Asking those vendors to do a bit of work to fixup the results of their bad decisions is not unreasonable. They can't fix hardware limitations but they can definitely fix software limitations. Vendors have finite resources. I'm not going to ask them to waste time fixing something that buys us a short amount of time vs. asking them to work on a feature that has immediate impact to my ability to generate revenue. Yah, I'm one of those dirty capitalists. What's Randy's quote? I highly recommend my competitors do this... -Steve
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message 20110218020622.ga10...@mara.org, Steve Meuse writes: Mark Andrews expunged (ma...@isc.org): An how many of those embedded linux devices are running a 2.4 kernel? Jus t lo ok at xx-wrt as an example. If you have a certain chipset, 2.4 is your on ly o ption. And the work to patch that kernel is minimal if it doesn't already support it. It would take less time to fix the kernel than to argue over whether to fix it. The point is just because it's running linux doesn't make it any more likel y to get upgraded than joe six pack is going to update/patch his windows XP. Joe 6 pack does upgrade his XP box. It companies that don't. There too worried about things breaking. -Steve -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Mark Andrews expunged (ma...@isc.org): I think grandma is quite capable of doing it. She just needs to be informed that it needs to be done. On my planet (Earth), this isn't likely ever happen. -Steve
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
You're invited to work my helpdesk for a week. I'd even pay you. It's not just flashing, it's reconfiguring every wireless device in the home (printer, Wii, Kindle, laptop (that's not home right, will be when Sally visits for the weekend), etc). If you can come up with an online tool that downloads the correct firmware image, backs up the settings, upgrades the firmware, and restores the configuration, with 99% success, I'd consider buying it to the tune $10/upgraded device. Frank -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Thursday, February 17, 2011 7:56 PM To: Owen DeLong Cc: NANOG list; John Curran Subject: Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... snip I think grandma is quite capable of doing it. She just needs to be informed that it needs to be done. Most people that are scared of doing it themselves have someone that they can call on to do it for them. It also doesn't have to be 100%. snip Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
