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: 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: 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: 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: 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: 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: 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
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
In message 00bc01cbcf19$8b3f13d0$a1bd3b70$@iname.com, Frank Bulk writes: 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). Every device doesn't need to know the address. The CPE device still uses RFC 1918 internally. This is for the external address. 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 -- 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...
Luckily, they do. Only the smart DSLAMs had issues, and they even blocked IP protocol 41. haha On 2/13/2011 4:44 PM, Frank Bulk wrote: Fine approach as long as the DSLAMs and CPE allow ether type 0x86DD to pass.
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Fine approach as long as the DSLAMs and CPE allow ether type 0x86DD to pass. Frank -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Friday, February 11, 2011 4:01 PM To: Ricky Beam Cc: nanog@nanog.org Subject: Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... On 2/11/2011 3:41 PM, Ricky Beam wrote: In bridge mode, any modem will do. It's when the modem is also the router (which is most cases today) that it will need attention to support IPv6. (in bridge mode, you'll have to fix whatever it's plugged into, but that's the customer's problem... off to Best Buy for an IPv6 capable D-Link.) I just finished discussing with the one telco in my network that deployed PPPoE. All customers will bring their modem into the office, where the front desk ladies will flash the config to bridge mode. It was that or replace thousands of CPE that never will support IPv6 in routed mode. Have a nice day. Jack
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, Feb 11, 2011 at 16:02, Ricky Beam jfb...@gmail.com wrote:
i.e. cellphones... the two largest groups there (iPhone and Android)
support IPv6 already.
No they don't. Only Symbian and Maemo (MeeGo?) supports IPv6 *on the
mobile side*.
Not android, not iphone.
Unless this has changed in the last month, it's still the case.
Neither of the two have any public plans to support IPv6 either.
Really.
--
typedef struct me_s {
char name[] = { Thomas Habets };
char email[] = { tho...@habets.pp.se };
char kernel[] = { Linux };
char *pgpKey[] = { http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854 };
char coolcmd[] = { echo '. ./_. ./_'_;. ./_ };
} me_t;
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My Milestone (android 2.1) uses IPv6 when connecting to a WLAN with stateless auto configuration enabled... (well at least basic connectivity when browsing web pages... Not sure about the rest...) Am 12.02.2011 16:49, schrieb Thomas Habets: On Fri, Feb 11, 2011 at 16:02, Ricky Beam jfb...@gmail.com wrote: i.e. cellphones... the two largest groups there (iPhone and Android) support IPv6 already. No they don't. Only Symbian and Maemo (MeeGo?) supports IPv6 *on the mobile side*. Not android, not iphone. Unless this has changed in the last month, it's still the case. Neither of the two have any public plans to support IPv6 either. Really. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1WtpcACgkQHTGv6cAMp2iYGQCgmY7LZLOCyaj0SloiyObyBHx+ Ts8AnAvnyRurC9a3eZgwV0BRJ2oiAvJe =+mZr -END PGP SIGNATURE-
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/12/2011 10:34 AM, Andre Keller wrote: My Milestone (android 2.1) uses IPv6 when connecting to a WLAN with stateless auto configuration enabled... Am 12.02.2011 16:49, schrieb Thomas Habets: *on the mobile side*.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Sat, 12 Feb 2011, Thomas Habets wrote: Really. Exactly. Can we PLEASE kill the myth that Android and iPhone has IPv6 support for mobile side. PLEASE. None do, and there are no publically available roadmaps when this might happen on either OSes. There are exactly two types of devices (afaik) that support IPv6 for mobile, and that's Nokia phones using Symbian and Maemo (afaik only N900). No other vendor has any IPv6 mobile side support, and even though Microsoft did the right thing for IPv6 on Vista and Win7, they've dropped the ball on Windows Phone 7 and have no IPv6 support there. I was very disappointed when I learnt that fact. I've been told it's to some extent a Qualcomm baseband issue. There are also no USB dongles with IPv6 support that I am aware of. This means that the incentive for mobile operators to support IPv6 is very close to zero even though a lot of them could do it fairly easily. I have native IPv6 in my Nokia N900, it works just fine within my own network, ie without roaming. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Friday, February 11, 2011 05:33:37 pm valdis.kletni...@vt.edu wrote: So riddle me this - what CPE stuff were they giving out in 2009 that was already v6-able? (and actually *tested* as being v6-able, rather than It's supposed to work but since we don't do v6 on the live net, nobody's ever actually *tried* it...) Well, while no one that I know 'gave out' Linksys WRT54G's capable of running OpenWRT or similar (Sveasoft firmware, too), a WRT54G of the right (read: old enough) version can run the IPv6 modules (ipkg's) for OpenWRT, and there was at least one version of the Sveasoft WRT firmware that could do IPv6. While I have a few WRT54G's lying around, I've never tried IPv6 on them, and would find it interesting if anyone has. Owen, in particular, should know, because one of the HOWTO's I found was posted on an HE forum.back in April of 2009. I found a few other HOWTO's, some in 2006, some in 2005, detailing IPv6 setup for the WRT54G running either Sveasoft or OpenWRT (one was for DD-WRT, and another for Tomato). Yeah, only the tech-savvy customers will be able to use this, unless the ISP sets up a 'Golden' CPE firmware image and recycles all those WRT54G's into useful things and then, of course, the DSL/Cable gateway needs to be in bridge mode. I'm sure there are other Linux-based firmwares for other CPE that can run Linux and IPv6; they just need enough flash and RAM to do it. vxWorks boxen, not so sure. And then there's all the Zoom stuff out there. My own Netgear DG834G can, too, with some interesting tinkering involved. So the firmware is out there to do this, it just requires flashing and configuring.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Sat, Feb 12, 2011 at 8:53 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Sat, 12 Feb 2011, Thomas Habets wrote: Really. Exactly. Can we PLEASE kill the myth that Android and iPhone has IPv6 support for mobile side. PLEASE. None do, and there are no publically available roadmaps when this might happen on either OSes. There are exactly two types of devices (afaik) that support IPv6 for mobile, and that's Nokia phones using Symbian and Maemo (afaik only N900). No other vendor has any IPv6 mobile side support, and even though Microsoft did the right thing for IPv6 on Vista and Win7, they've dropped the ball on Windows Phone 7 and have no IPv6 support there. I was very disappointed when I learnt that fact. I've been told it's to some extent a Qualcomm baseband issue. There are also no USB dongles with IPv6 support that I am aware of. I completely agree with this note from Mikael, but as Joel pointed out and I have confirmed before, Verizon Wireless does have dual-stack USB sticks for LTE. But it is only working on their itty bitty LTE network ... LTE is still developing a market and the economies of scale are not there, so things like this happen where small supply exceeds the growing demand. I believe the chipset cost for LTE are around $100 while they are $15 for HSPA ... (foggy memory) But, LTE is not the issue here. GSM/UMTS/HSPA+ all support IPv6 just as well as LTE. The issue is mobile OSs don't support IPv6 aside from Nokia. Mikael and I both have 3G networks with demonstrated IPv6 capabilities, perhaps people should request Google drive Android IPv6 support. Please point your IPv6 interest here http://code.google.com/p/android/issues/detail?id=3389 and comment and try and drive the IPv6 support for mobile into Android. Cameron This means that the incentive for mobile operators to support IPv6 is very close to zero even though a lot of them could do it fairly easily. I have native IPv6 in my Nokia N900, it works just fine within my own network, ie without roaming. -- Mikael Abrahamsson email: swm...@swm.pp.se
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 02/12/2011 09:26 AM, Lamar Owen wrote: While I have a few WRT54G's lying around, I've never tried IPv6 on them, and would find it interesting if anyone has. http://www.tunnelbroker.net/forums/index.php?topic=106.0 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Re: [v6z] Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 02/12/2011 02:32 PM, Scott Howard wrote: On Sat, Feb 12, 2011 at 9:26 AM, Lamar Owenlo...@pari.edu wrote: While I have a few WRT54G's lying around, I've never tried IPv6 on them, and would find it interesting if anyone has. I used a WRT54G running DD-WRT for some time with a HE IPv6 tunnel (now replaced with a Cisco 877, but not due to any failing of the Linksys/DD-WRT) IPv6 support is actually broken in the latest version of DD-WRT, and it's been that way for some time (measured in years), however with some hacking you can get it to work. It's not at all user friendly, and definitely not consumer ready, but once it's working it's pretty much rock solid. All up I'd say I probably spent less time getting IPv6 working on DD-WRT than on my Cisco 877W (Hint: IOS 12.x doesn't support IPv6 on the bridge interface, the IOS 15.x Advanced Security feature set doesn't support IPv6 at all, and the flash requirements listed for 15.1 Advanced IP are wrong. Go Cisco!) Keep in mind that not all WRT54G's support DD-WRT. Linksys moved from Linux to Vxworks but kept the model number the same (the version did change). The WRT54GL along with various other devices do support it - details are on the DD-WRT website. OpenWRT will run IPv6 fine; Comcast posted patches some months back to enable some 6rd configuration mods needed for Comcast's IPv6 trial. From the Comcast beta forum, it's clear that some people have succeeded at merging those 6rd patches into OpenWRT, though there may be some rough edges. I haven't had time to take them for a spin. - Jim
Re: [v6z] Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Sat, Feb 12, 2011 at 9:26 AM, Lamar Owen lo...@pari.edu wrote: While I have a few WRT54G's lying around, I've never tried IPv6 on them, and would find it interesting if anyone has. I used a WRT54G running DD-WRT for some time with a HE IPv6 tunnel (now replaced with a Cisco 877, but not due to any failing of the Linksys/DD-WRT) IPv6 support is actually broken in the latest version of DD-WRT, and it's been that way for some time (measured in years), however with some hacking you can get it to work. It's not at all user friendly, and definitely not consumer ready, but once it's working it's pretty much rock solid. All up I'd say I probably spent less time getting IPv6 working on DD-WRT than on my Cisco 877W (Hint: IOS 12.x doesn't support IPv6 on the bridge interface, the IOS 15.x Advanced Security feature set doesn't support IPv6 at all, and the flash requirements listed for 15.1 Advanced IP are wrong. Go Cisco!) Keep in mind that not all WRT54G's support DD-WRT. Linksys moved from Linux to Vxworks but kept the model number the same (the version did change). The WRT54GL along with various other devices do support it - details are on the DD-WRT website. Scott.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Sat, 2011-02-12 at 09:37 -0800, Cameron Byrne wrote: Mikael and I both have 3G networks with demonstrated IPv6 capabilities, perhaps people should request Google drive Android IPv6 support. Please point your IPv6 interest here http://code.google.com/p/android/issues/detail?id=3389 and comment and try and drive the IPv6 support for mobile into Android. Looks like cyanogenmod supports ipv6: http://forum.cyanogenmod.com/topic/1286-ipv6-on-cm-508-ds/ Laurent
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
That is on WiFi, NOT cellular. On Sat, Feb 12, 2011 at 2:44 PM, Laurent GUERBY laur...@guerby.net wrote: On Sat, 2011-02-12 at 09:37 -0800, Cameron Byrne wrote: Mikael and I both have 3G networks with demonstrated IPv6 capabilities, perhaps people should request Google drive Android IPv6 support. Please point your IPv6 interest here http://code.google.com/p/android/issues/detail?id=3389 and comment and try and drive the IPv6 support for mobile into Android. Looks like cyanogenmod supports ipv6: http://forum.cyanogenmod.com/topic/1286-ipv6-on-cm-508-ds/ Laurent
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 11 Feb 2011, at 04:51, Ricky Beam wrote: On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad d...@virtualized.org wrote: Amusingly enough, I personally (along with others) made arguments along these lines back in 1995 or so when the IAB was coming out with http://www.ietf.org/rfc/rfc1814.txt. Given the publication of 1814, you can probably guess how far those arguments fared. You missed the anticipates external connectivity to the Internet part. Networks that never touch the internet have RFC1918 address space to use. (and that works 99.999% of the time.) Except in acquisitions and private peering. as
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, Feb 11, 2011 at 6:07 AM, Arturo Servin arturo.ser...@gmail.com wrote: On 11 Feb 2011, at 04:51, Ricky Beam wrote: On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad d...@virtualized.org wrote: Amusingly enough, I personally (along with others) made arguments along these lines back in 1995 or so when the IAB was coming out with http://www.ietf.org/rfc/rfc1814.txt. Given the publication of 1814, you can probably guess how far those arguments fared. You missed the anticipates external connectivity to the Internet part. Networks that never touch the internet have RFC1918 address space to use. (and that works 99.999% of the time.) Except in acquisitions and private peering. as Especially during acquisitions, my $EMPLOYEER has made several acquisitions recently and every one of them was wrought with painful RFC1918 overlap problems. Thanks, Josh Smith KD8HRX email/jabber: juice...@gmail.com phone: 304.237.9369(c)
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
I don't know about that. Yes, v4 will be around for a long time but considering the oligopolies we have in both eyeball and content networks, ones a dozen or so very large networks switch, there is the vast majority of Internet traffic right there. It will be around for a very long time handling a tiny bit of traffic. Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. Facebook alone accounts for 25% of internet traffic in the US. Netflix is estimated to be over 20% and YouTube at 10%. So that's 55% of Internet traffic right there. At the other end of the transaction you have ATT with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 million and Time Warner at 8.9 million (early 2010 numbers). That's 50 million of the estimated 83 million US broadband subscribers. So once three content providers and four subscriber nets switch, that is over 25% of US internet traffic on v6 (more than half the users and more than half the content they look at). Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with enough embedded brains to talk directly. Those devices will also seriously lag behind PCs in IPv6 support. I don't think the growth of v6 traffic is going to be gradual, I think it will increase in steps. You will wake up one morning to find your v6 traffic doubled and some other morning it will double again. They'll be jumps, but they will be fairly smallish jumps since both the content maker, the ISP, and the device consuming the content all have to be ready. Since I don't imagine we will see any pure IPv6 deployments any time soon many/most of the IPv6 deploys will be dual stack and so we are still at the mercy of the record returning before the A record does. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Friday 11 February 2011 15:00:57 Scott Helms wrote:
While Facebook working over IPv6 will be a big deal you won't get all of
their traffic since a significant fraction of that traffic is from
mobile devices which are going to take much longer than PCs to get to
using IPv6 in large numbers. Also, Netflix is even more problematic
since the bulk of their traffic, and the fastest growing segment as
well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with
enough embedded brains to talk directly. Those devices will also
seriously lag behind PCs in IPv6 support
Recommendation: if you're doing some sort of under-the-TV device, if it does
6to4 or some other kind of IPv6 tunnelling (like Apple Airports), colocate your
relay/vpn host/tunnel exit points with content CDN servers rather than sending
everything via your head office location.
If you're snooping on the traffic, you can always configure the nodes to do
that:-{0
--
The only thing worse than e-mail disclaimers...is people who send e-mail to
lists complaining about them
signature.asc
Description: This is a digitally signed message part.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, Feb 11, 2011 at 10:00 AM, Scott Helms khe...@ispalliance.net wrote: Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. I seriously doubt v4 traffic is going to fall off a cliff. That would require IPv6 adoption on a large scale over a relatively short period. To date, nothing in the v6 verse has happened *quickly*. Replacement or software upgrades to millions of CPEs in hundreds of network is not something that will happen overnight. Even then, that will not instantly switch everyone and every device to IPv6. How many connected devices do you think there are in the average home? TV? DVR (stb)? Game console(s)? Netflix streaming thing? If you're using Windows 7, you're already IPv6 connected... IPv6 is installed by default (and in fact cannot be uninstalled) and configured with Teredo. So a lot of people could be using v6 already and not even know it. Facebook ... So that's 55% of Internet traffic right there. and making a dent in it means residential transition. 50mil (or 83mil) devices is a lot of shit to replace or reprogram. Not to forget the thousands of devices that feed them. ... mobile devices i.e. cellphones... the two largest groups there (iPhone and Android) support IPv6 already. (in certain versions) I was saying the same thing about netflix. PC based streaming can already be done via IPv6. (ipv6.netflix.com?) I'm not sure any of my media devices (tv, consoles, tivo) can do IPv6. I'd be disappointed if SONY didn't have the PS3 doing v6. Tivo doesn't do v6 -- unless the premier does. DTV receiver doesn't. DISH doesn't. (Wii, don't care. :-)) --Ricky
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, Feb 10, 2011 at 10:46 PM, Ricky Beam jfb...@gmail.com wrote: On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman matt...@matthew.at wrote: There is no one universal global routing table. They probably appear in someone's routing table, somewhere... just not yours. Using public address space for private networking is a gross misuse of the resource. Ricky, One example I heard was a generic financial exchange connected to perhaps a hundred other companies. Those companies also connect to the Internet but the exchange itself does not. It's valuable for the exchange to use addressing which will not conflict with any of its customers' RFC1918 use or overlap any Internet destinations they want to access. This is why ULA in IPv6 has statistical uniqueness -- so that organizations with similar requirements don't need to use Internet-routable addresses. 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. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, Feb 11, 2011 at 10:00 AM, Scott Helms wrote: Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. I seriously doubt v4 traffic is going to fall off a cliff. That would require IPv6 adoption on a large scale over a relatively short period. The thing is that a very few networks account for a very large amount of traffic. So it depends on what you mean by adoption on a large scale. 1% of the networks account for 50% of the traffic. If a handful of networks move to v6, then we have a very large amount of v6 traffic and a significant decrease in v4 traffic. It depends on if you mean large numbers of different endpoints or large numbers of packets when you say adoption on a large scale. Joe's Fish Farm might and all the other Fish Farms might stay v4 for a decade or more but that traffic accounts for an insignificant portion of traffic in the context of internet traffic as a whole. To date, nothing in the v6 verse has happened *quickly*. Replacement or software upgrades to millions of CPEs in hundreds of network is not something that will happen overnight. What is the natural churn rate for CPE for one of the large MSOs? What portion of the MSOs have v6 capable CPE in place right now but v6 just isn't in use but is planned to go into v6 service soon? You don't need to migrate hundreds of networks to account for the majority of eyeball internet traffic in North America, you only need about five. It could be that v6 capable CPE has been in the process of being rolled out already and has been for months to possibly years. Even then, that will not instantly switch everyone and every device to IPv6. How many connected devices do you think there are in the average home? TV? DVR (stb)? Game console(s)? Netflix streaming thing? Ok, we have been watching our DNS servers for who is requesting records. The vast majority of our connections come from a very small number of networks. We are seeing requests for records. The next step is to put a v6 only DNS server into whois but hand out only A records for a while. But the idea is to see what of the requests for records actually arrive via IPv6. Once we profile that for a while, we will return records for the largest requester but only for requests arriving by IPv6 requesting records. The next step is to see that the requests actually result in connections to the service address handed out by the records and let that bake for a while and see if any service oddities are noticed. We happen to be in a unique position in that requests from different remote networks request a unique service address for that remote network and most others don't have that luxury. So if one remote network is v6 clean, we can change one IP address to records and migrate that remote network to v6 without impacting others simply by changing the DNS record for their service IP. If another network has issues, is requesting records but can't really talk over v6, we can roll back to A records for that service IP associated with that particular remote network. Other providers don't have that luxury and I understand that. But still, once two of those remote networks switch to v6, that is a very significant portion of our traffic. It will be possible, depending on which remote networks migrate and at what speed, for traffic to migrate in chunks as we migrate those records. We might go from 0% of traffic on v6 to 25% of traffic on v6 in less than a calendar quarter depending on the behavior of the remote nets. Also, once THEY see more successful traffic migration to v6, it gives impetus for them to move faster in that direction for additional services. Facebook ... So that's 55% of Internet traffic right there. and making a dent in it means residential transition. 50mil (or 83mil) devices is a lot of shit to replace or reprogram. Not to forget the thousands of devices that feed them. Yes, and I mentioned that. So once you have 50% of the potential content sources v6 capable and 50% of the potential eyeballs v6 capable, you have potentially 25% of internet traffic on v6. And that can be done with the migration of enough networks to count on your fingers. So again, are we talking number of networks or number of packets when we say large scale adoption? ... mobile devices i.e. cellphones... the two largest groups there (iPhone and Android) support IPv6 already. (in certain versions) And are already being given native v6 IP addresses in some markets. Some markets are already doing NAT64 or something to get these devices to v4 content. George
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Lucky you. .as On 11 Feb 2011, at 11:42, Josh Smith wrote: On Fri, Feb 11, 2011 at 6:07 AM, Arturo Servin arturo.ser...@gmail.com wrote: On 11 Feb 2011, at 04:51, Ricky Beam wrote: On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad d...@virtualized.org wrote: Amusingly enough, I personally (along with others) made arguments along these lines back in 1995 or so when the IAB was coming out with http://www.ietf.org/rfc/rfc1814.txt. Given the publication of 1814, you can probably guess how far those arguments fared. You missed the anticipates external connectivity to the Internet part. Networks that never touch the internet have RFC1918 address space to use. (and that works 99.999% of the time.) Except in acquisitions and private peering. as Especially during acquisitions, my $EMPLOYEER has made several acquisitions recently and every one of them was wrought with painful RFC1918 overlap problems. Thanks, Josh Smith KD8HRX email/jabber: juice...@gmail.com phone: 304.237.9369(c)
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 11, 2011, at 7:00 AM, Scott Helms wrote: I don't know about that. Yes, v4 will be around for a long time but considering the oligopolies we have in both eyeball and content networks, ones a dozen or so very large networks switch, there is the vast majority of Internet traffic right there. It will be around for a very long time handling a tiny bit of traffic. Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. I don't think it will be just a drop in traffic levels. I think that it will not be long before the internet is an IPv6 ocean with islands of IPv4, much like it was an ocean of IPv4 with islands of IPv6 years ago. Facebook alone accounts for 25% of internet traffic in the US. Netflix is estimated to be over 20% and YouTube at 10%. So that's 55% of Internet traffic right there. At the other end of the transaction you have ATT with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 million and Time Warner at 8.9 million (early 2010 numbers). That's 50 million of the estimated 83 million US broadband subscribers. So once three content providers and four subscriber nets switch, that is over 25% of US internet traffic on v6 (more than half the users and more than half the content they look at). Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. I think you'll be in for a surprise here. While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with enough embedded brains to talk directly. Those devices will also seriously lag behind PCs in IPv6 support. 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. In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. I don't think the growth of v6 traffic is going to be gradual, I think it will increase in steps. You will wake up one morning to find your v6 traffic doubled and some other morning it will double again. They'll be jumps, but they will be fairly smallish jumps since both the content maker, the ISP, and the device consuming the content all have to be ready. Since I don't imagine we will see any pure IPv6 deployments any time soon many/most of the IPv6 deploys will be dual stack and so we are still at the mercy of the record returning before the A record does. You misunderstand how getaddrinfo() works under the hood. The code itself first does an lookup and then does an A lookup. DNS does not return both record sets at once. If there is an record, it will return first. Some OS have modified things to resort the getaddrinfo() returns based on the perceived type of IPv6 and IPv4 connectivity available as an attempt to reduce certain forms of brokenness. However, even in those cases, you should get the first if you have real IPv6 connectivity. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. I think you'll be in for a surprise here. We'll see, I have reasons to be (deeply) skeptical, but I hope you're right. Care to speculate on a time frame for when we might get a pleasant surprise? While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with enough embedded brains to talk directly. Those devices will also seriously lag behind PCs in IPv6 support. 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. LTE won't be real for the vast majority of subs until the they have an LTE handset, which won't happen until they replace their existing 3G phone. That won't happen unless Verizon and ATT decide to suddenly give people upgrade credits before their contract would allow. What's worse the whole LTE isn't really 4G and will be replaced by LTE+ makes this worse. If you're a phone maker you're likely trying to decide if you've gone to far to delay your product launch or if you can wait for LTE+ chipsets before releasing your new phone. In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. 3G will be around in substantial amounts for at least 10 years outside of the top 20 metro markets. You misunderstand how getaddrinfo() works under the hood. The code itself first does an lookup and then does an A lookup. DNS does not return both record sets at once. If there is an record, it will return first. Some OS have modified things to resort the getaddrinfo() returns based on the perceived type of IPv6 and IPv4 connectivity available as an attempt to reduce certain forms of brokenness. However, even in those cases, you should get the first if you have real IPv6 connectivity. I haven't looked at the code so that it is entirely possible, but I am more concerned with what the content providers do. Does MS implement the POSIX function? I don't know, but if not whatever Win(XP-7) does is much more important to traffic than what all of the BSD and Linux variants do. Right now you can have a completely working dual stack set up and if your ISP's name server isn't on Google's (and a host of others) white list you'll never get the record no matter what order your client resolver code asks for the addresses in. http://tools.ietf.org/html/draft-ietf-v6ops-v6--whitelisting-implications-02 http://arstechnica.com/web/news/2010/03/yahoo-wants-two-faced-dns-to-aid-ipv6-deployment.ars The point here is that there are multiple hoops that have to navigated and if any one of them is missed the client will work over v4 and that will keep the ramp up of v6 traffic modest for a long time to come. BTW, I don't want to be right here but I know intimately how ISPs, CPE vendors, and customers behave. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, Feb 11, 2011 at 11:56 AM, Owen DeLong o...@delong.com wrote: On Feb 11, 2011, at 7:00 AM, Scott Helms wrote: I don't know about that. Yes, v4 will be around for a long time but considering the oligopolies we have in both eyeball and content networks, ones a dozen or so very large networks switch, there is the vast majority of Internet traffic right there. It will be around for a very long time handling a tiny bit of traffic. Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. I don't think it will be just a drop in traffic levels. I think that it will not be long before the internet is an IPv6 ocean with islands of IPv4, much like it was an ocean of IPv4 with islands of IPv6 years ago. Facebook alone accounts for 25% of internet traffic in the US. Netflix is estimated to be over 20% and YouTube at 10%. So that's 55% of Internet traffic right there. At the other end of the transaction you have ATT with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 million and Time Warner at 8.9 million (early 2010 numbers). That's 50 million of the estimated 83 million US broadband subscribers. So once three content providers and four subscriber nets switch, that is over 25% of US internet traffic on v6 (more than half the users and more than half the content they look at). Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. I think you'll be in for a surprise here. While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with enough embedded brains to talk directly. Those devices will also seriously lag behind PCs in IPv6 support. 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. In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. This is not quite the case. 2G / 3G / 4G largely refers to radio interface aspects, and the packet core that moves IP packets is largely the same. I have a 5 year old 2G/GSM Nokia phone that support IPv6 over cellular just fine on my network today. There are several LTE deployments around the world that are IPv4 only. There is no hackery require to make IPv4 work in LTE. LTE supports IPv4, IPv6, and IPv4v6 bearers all the same... its just an option from the core perspective, handset / chipset makers like to limit the options to keep cost and variability down. The pressure needs to be applied to the handset makers, they are squarely the long pole in the tent here. Cameron == http://groups.google.com/group/tmoipv6beta == I don't think the growth of v6 traffic is going to be gradual, I think it will increase in steps. You will wake up one morning to find your v6 traffic doubled and some other morning it will double again. They'll be jumps, but they will be fairly smallish jumps since both the content maker, the ISP, and the device consuming the content all have to be ready. Since I don't imagine we will see any pure IPv6 deployments any time soon many/most of the IPv6 deploys will be dual stack and so we are still at the mercy of the record returning before the A record does. You misunderstand how getaddrinfo() works under the hood. The code itself first does an lookup and then does an A lookup. DNS does not return both record sets at once. If there is an record, it will return first. Some OS have modified things to resort the getaddrinfo() returns based on the perceived type of IPv6 and IPv4 connectivity available as an attempt to reduce certain forms of brokenness. However, even in those cases, you should get the first if you have real IPv6 connectivity. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
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. In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. This is not quite the case. 2G / 3G / 4G largely refers to radio interface aspects, and the packet core that moves IP packets is largely the same. I have a 5 year old 2G/GSM Nokia phone that support IPv6 over cellular just fine on my network today. Sure, there are some 3G systems that support IPv6, but, most carriers will probably roll IPv6 out as part of their 4G upgrade from what I have seen. There are several LTE deployments around the world that are IPv4 only. I think if you look under the hood, they may only provide internet routing for IPv4, but, I don't think they are IPv4 only across the radio. There is no hackery require to make IPv4 work in LTE. LTE supports IPv4, IPv6, and IPv4v6 bearers all the same... its just an option from the core perspective, handset / chipset makers like to limit the options to keep cost and variability down. My understanding (admittedly second hand, so perhaps the engineer explaining it to me was mistaken) was that LTE was IPv6 and that IPv4 was implemented on the radio side essentially as a 4in6 tunnel with a very very short-term DHCP lease for the v4 address. The pressure needs to be applied to the handset makers, they are squarely the long pole in the tent here. Yep. In the US, at least, the carriers have an unfortunately large ability to do that. In this case, it will prove helpful. In most cases, it has proven to be rather strongly contrary to the consumer's best interests. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, 11 Feb 2011 12:20:59 -0500, George Bonser gbon...@seven.com wrote: The thing is that a very few networks account for a very large amount of traffic. Traffic has to have two end points. Just because the content source supports IPv6 does not mean the content request will be. That's the millions of eyeballs (aka sheep.) You don't seem to grasp the full picture... There are 4 parts to the equation: 1. Content Source 2. Transit network(s) 3. CPE 4. Content Consumer Fixing the source (be it Facebook, Youtube, or netflix) is rather simple in concept -- it's just one network, and doesn't require touching millions of devices. Transit networks are hit-n-miss, but is becoming less of a burden. The CPE on the other hand is a whole other mess... there are thousands (into millions) that will need firmware upgrades or complete replacement to support IPv6. (That's the cablemodems, dsl modem, Uverse RGs, FiOS ONTs, and linksys's and netgears of the world.) And *then* the device that actually wants the content has to have support. (that'd be you roku, blu-ray player, console, laptop, cellphone, picture frame, etc.) What is the natural churn rate for CPE for one of the large MSOs? How often MSO's replace CPE gear? When it breaks and when it's no longer compat I don't know about your cable company, but TW doesn't replace anything unless it's broken. I've had the same SB5100 for nearly a decade. (they did replace the SB3100/4100's a few years back, but they were no longer compatible with the network.) ATT DSL also doesn't replace CPE's unless they break. (or you buy a new one.) In bridge mode, any modem will do. It's when the modem is also the router (which is most cases today) that it will need attention to support IPv6. (in bridge mode, you'll have to fix whatever it's plugged into, but that's the customer's problem... off to Best Buy for an IPv6 capable D-Link.) What portion of the MSOs have v6 capable CPE in place right now... Unknown. I've not known any MSO to publish those numbers. Any sane MSO is handing out D3 modems even if they are still running a D2 network, so new connections (or replacements) should be D3. you only need about five If you're thinking of five major cable operators, they aren't each one network but are a group of franchises/markets running more or less independent of each other. Yes, and I mentioned that. So once you have 50% of the potential content sources v6 capable and 50% of the potential eyeballs v6 capable, you have potentially 25% of internet traffic on v6. And that can be done with the migration of enough networks to count on your fingers. Heh. No it can't. You grossly underestimate the work necessary to get the eyeballs v6 capable. If Comcast has to replace as little as 10% of their modems, that'd be over 1mil. That's not going to happen overnight. (or even a month.) --Ricky
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Using public address space for private networking is a gross misuse of the resource. No it is not. IP was invented to enable internetworking. The IPv4 address registry was set up so that anyone who wanted to use IP for internetworking could get unique addresses. The key here, is internetworking, which refers to exchanging packets with other networks. It is possible to internetwork without ever exchanging packets with the public Internet. Go to any registry and ask for address space for your private networking that you do not intend to announce to the internet. They will laugh at you, and point you to RFC1918. (and likely flag you as someone to whom address space should never be assigned.) Not true. Two of my former employers went to ARIN every year or two and received blocks around a /16 in size, specifically for use on global IP networks that did not intend to ever announce those addresses on the Internet. There are several other companies which operate somewhat similar networks. Also, announce to the Internet doesn't mean what you think it does. First of all there is no Internet to announce to, only peers, There are a lot of smaller networks which do announce routes to a small number of regional peers, but those routes are NOT transitively announced to the rest of the public Internet. These networks *ARE* connected to the Internet, but you won't see their routes in any of the major views (routeviews, ris, etc) which are considered as the global routing table. The only reason legacy holders get away with such crap is because there's no clear contract governing their assignment. All of the companies that I am aware of who get RIR addresses with no intention of announcing it on the Internet, are paid up members in good standing of one or more RIRs. Legacy holders really don't play in this game except for the DOD. First off, someone will have to do a lot more than 5 minutes of poking router-servers to see just how sparsely used (announced) the space really is. That includes digging through BGP histories to see if it's ever been announced. Then research who should be in control of the space (announced or not.) Then send out nasty sounding letters informing whomever that X address space has not been announced to the public internet in Y years; on Z date, the space will reenter the IANA/ICANN free pool for reassignment. (cue lawyers :-)) They'd also be highly motivated to return unused space if they were being billing for it. First of all, tools like RIPE's RIS make checking BGP history child's play. Secondly, you left out the court cases where the companies all get injunctions against ARIN because ARIN did regularly give them addresses under ARIN policy and nothing has changed to justify pulling the addresses back. These addresses are in use, i.e. configured in devices that provide a commercial internetworking service with packets flowing 24 hours a day. --Michael Dillon
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, Feb 11, 2011 at 1:00 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. In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. This is not quite the case. 2G / 3G / 4G largely refers to radio interface aspects, and the packet core that moves IP packets is largely the same. I have a 5 year old 2G/GSM Nokia phone that support IPv6 over cellular just fine on my network today. Sure, there are some 3G systems that support IPv6, but, most carriers will probably roll IPv6 out as part of their 4G upgrade from what I have seen. Yep, 4G projects should add IPv6, most people agree about this. There are several LTE deployments around the world that are IPv4 only. I think if you look under the hood, they may only provide internet routing for IPv4, but, I don't think they are IPv4 only across the radio. Nope. There is no hackery require to make IPv4 work in LTE. LTE supports IPv4, IPv6, and IPv4v6 bearers all the same... its just an option from the core perspective, handset / chipset makers like to limit the options to keep cost and variability down. My understanding (admittedly second hand, so perhaps the engineer explaining it to me was mistaken) was that LTE was IPv6 and that IPv4 was implemented on the radio side essentially as a 4in6 tunnel with a very very short-term DHCP lease for the v4 address. Nope, it does not work this way. There are tunnels for mobility, and it is possible that IPv4 user plane packet get carried in IPv6 GTP packets but that is the same case for IPv6 user plane also being in IPv6 GTP packets but LTE generally does not use any DHCP to the user. Key point: LTE does not imply any mandatory IPv6 networks infrastructure or services, but it does work with IPv6 and should be deployed with IPv6. Cameron (who works in mobile, everyday)
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
One example I heard was a generic financial exchange connected to perhaps a hundred other companies. Those companies also connect to the Internet but the exchange itself does not. It's valuable for the exchange to use addressing which will not conflict with any of its customers' RFC1918 use or overlap any Internet destinations they want to access. Sounds like SFTI in New York http://www.nyse.com/technologies/sfti/1223635951074.html In turn, SFTI is connected to the Radianz global IP network which allows financial industry companies in other countries to access the NYSE services on SFTI. And the Radianz global IP network has over 15,000 sites connected to it in some 200 countries. Probably all of the companies connected to Radianz also have an Internet connection, but nobody passes packets between Radianz and the Internet. Radianz is an example of a COIN (Community of Interest Network). Outside the Financial Services industry there are similar COINs in the air traffic industry (SITA) and the auto manufacturing industry. If you diagrammed these COINs on a typical Internet diagram, they would be a thin layer, one AS thick, wrapped around some portion of the cloud's perimeter. Invisible to most because they connect but do not exchange transit traffic. Zoom in an look at ASCustomer which peers with three ISP ASnumbers and also peers with ASRadianz. But the traffic from ASRadianz is controlled by firewalls and internal routing in ASCustomer so that it only goes to the trading workstations, while the Internet traffic is allowed pretty much everywhere. You could make various biological analogies such as the specialised layers of human skin cells or the micturating membrane in amphibians. --Michael Dillon
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/11/2011 3:41 PM, Ricky Beam wrote: In bridge mode, any modem will do. It's when the modem is also the router (which is most cases today) that it will need attention to support IPv6. (in bridge mode, you'll have to fix whatever it's plugged into, but that's the customer's problem... off to Best Buy for an IPv6 capable D-Link.) I just finished discussing with the one telco in my network that deployed PPPoE. All customers will bring their modem into the office, where the front desk ladies will flash the config to bridge mode. It was that or replace thousands of CPE that never will support IPv6 in routed mode. Have a nice day. Jack
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Fixing the source (be it Facebook, Youtube, or netflix) is rather simple in concept -- it's just one network, and doesn't require touching millions of devices. Transit networks are hit-n-miss, but is becoming less of a burden. The CPE on the other hand is a whole other mess... there are thousands (into millions) that will need firmware upgrades or complete replacement to support IPv6. I would venture to say that it is likely that most of the CPE deployed over the past couple of years is capable of supporting v6 even if v6 is not currently deployed on that CPE. (That's the cablemodems, dsl modem, Uverse RGs, FiOS ONTs, and linksys's and netgears of the world.) And *then* the device that actually wants the content has to have support. (that'd be you roku, blu-ray player, console, laptop, cellphone, picture frame, etc.) You are frame dragging what I said into something I didn't say. What I said was that it will take v6 deployment in only a tiny portion of the number of networks to account for a large amount of the traffic. There is a lot of v6 capability that is just sitting there at the moment. I never said v4 support would go away, in fact, I said it would be around for decades. What is the natural churn rate for CPE for one of the large MSOs? How often MSO's replace CPE gear? That is a different question. People are always moving, for example, turning in their old CPE and getting new. Old ones break and need to be replaced with a new one. Let's say the gear they have been handing out over the past couple of years has had v6 capability. So not only have all new deployments had the capability for v6 once the provider turns it up, a good number of legacy installations have been gaining v6 capability as old gear is changed out for new. How many CPE units does Comcast go through in a month? That would be about the rate of v6 capability being deployed out there even if v6 isn't turned up on it. When it breaks and when it's no longer compat I don't know about your cable company, but TW doesn't replace anything unless it's broken. Correct, and a certain number of those break every month. With every passing month the amount of CPE out there that isn't v6 capable declines. I've had the same SB5100 for nearly a decade. This isn't about you or me. It is about the net in aggregate. V4 will continue to work, and those with older stuff will get v4. But at some point there are going to be people who decide to deploy a site that is v6 only. It will be cool and only certain people will be able to get to the content. Probably college kids and aging hipsters. Then other people will start hearing about it and want access to it ... and will demand their ISP get them on v6 pronto ;) Heh. No it can't. You grossly underestimate the work necessary to get the eyeballs v6 capable. If Comcast has to replace as little as 10% of their modems, that'd be over 1mil. That's not going to happen overnight. (or even a month.) --Ricky They are constantly replacing them, all the time. Every day they replace a few more. Someone moves, turns in their old cable box, gets a new one at the new place. Kid spills milk in it, it gets dropped, whatever. Old CPE attritions out of the installed base every day, I just don't know what the annual churn rate is. But I do believe that if IPv6 were enabled in a market today on some carrier, there would be an installed base of gear right now that could handle it on day one that would represent an amount of traffic that is not insignificant.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, 11 Feb 2011 14:21:49 PST, George Bonser said: That is a different question. People are always moving, for example, turning in their old CPE and getting new. Old ones break and need to be replaced with a new one. Let's say the gear they have been handing out over the past couple of years has had v6 capability. So riddle me this - what CPE stuff were they giving out in 2009 that was already v6-able? (and actually *tested* as being v6-able, rather than It's supposed to work but since we don't do v6 on the live net, nobody's ever actually *tried* it...) pgpdejZEDj6HD.pgp Description: PGP signature
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 11, 2011, at 3:44 PM, Michael Dillon wrote: Not true. Two of my former employers went to ARIN every year or two and received blocks around a /16 in size, specifically for use on global IP networks that did not intend to ever announce those addresses on the Internet. There are several other companies which operate somewhat similar networks. Also, announce to the Internet doesn't mean what you think it does. Exactly. Further, just because it's announced doesn't mean it's reachable or even connected. Cheers, -Benson
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
So riddle me this - what CPE stuff were they giving out in 2009 that was already v6-able? (and actually *tested* as being v6-able, rather than It's supposed to work but since we don't do v6 on the live net, nobody's ever actually *tried* it...) I would venture to say the same as today's CPE if they are issuing today the same CPE to new customers that they were issuing in 2009. I do know that in my area it has changed since 2007. But I don't know when they started issuing the current CPE.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
There is no hackery require to make IPv4 work in LTE. LTE supports IPv4, IPv6, and IPv4v6 bearers all the same... its just an option from the core perspective, handset / chipset makers like to limit the options to keep cost and variability down. My understanding (admittedly second hand, so perhaps the engineer explaining it to me was mistaken) was that LTE was IPv6 and that IPv4 was implemented on the radio side essentially as a 4in6 tunnel with a very very short-term DHCP lease for the v4 address. Nope, it does not work this way. There are tunnels for mobility, and it is possible that IPv4 user plane packet get carried in IPv6 GTP packets but that is the same case for IPv6 user plane also being in IPv6 GTP packets but LTE generally does not use any DHCP to the user. Key point: LTE does not imply any mandatory IPv6 networks infrastructure or services, but it does work with IPv6 and should be deployed with IPv6. Cameron (who works in mobile, everyday) OK... Thanks for the clarification. So did the other guy who gave me the other story. I won't pretend to be a mobile expert. Owen
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 11, 2011, at 1:41 PM, Ricky Beam wrote: On Fri, 11 Feb 2011 12:20:59 -0500, George Bonser gbon...@seven.com wrote: The thing is that a very few networks account for a very large amount of traffic. Traffic has to have two end points. Just because the content source supports IPv6 does not mean the content request will be. That's the millions of eyeballs (aka sheep.) You don't seem to grasp the full picture... There are 4 parts to the equation: 1. Content Source 2. Transit network(s) 3. CPE 4. Content Consumer Fixing the source (be it Facebook, Youtube, or netflix) is rather simple in concept -- it's just one network, and doesn't require touching millions of devices. Transit networks are hit-n-miss, but is becoming less of a burden. The CPE on the other hand is a whole other mess... there are thousands (into millions) that will need firmware upgrades or complete replacement to support IPv6. (That's the cablemodems, dsl modem, Uverse RGs, FiOS ONTs, and linksys's and netgears of the world.) And *then* the device that actually wants the content has to have support. (that'd be you roku, blu-ray player, console, laptop, cellphone, picture frame, etc.) The CPE is an expected problem that most providers have been doing some level of planning for. I'm quite certain it will get solved in one of the following ways: 1. Provider ships replacement box. 2. Provider tells customer As of X date, your current CPE will no longer be supported. Go buy one of these: followed by a list of qualified CPE devices. 3. Provider finds some other way to get CPE to customers. What is the natural churn rate for CPE for one of the large MSOs? How often MSO's replace CPE gear? When it breaks and when it's no longer compat I don't know about your cable company, but TW doesn't replace anything unless it's broken. I've had the same SB5100 for nearly a decade. (they did replace the SB3100/4100's a few years back, but they were no longer compatible with the network.) When the provider needs their customers to be IPv6 compatible, then IPv4 gear will be broken for all practical purposes in the above sentence. This will happen much faster than you expect. ATT DSL also doesn't replace CPE's unless they break. (or you buy a new one.) In bridge mode, any modem will do. It's when the modem is also the router (which is most cases today) that it will need attention to support IPv6. (in bridge mode, you'll have to fix whatever it's plugged into, but that's the customer's problem... off to Best Buy for an IPv6 capable D-Link.) See above. What portion of the MSOs have v6 capable CPE in place right now... Unknown. I've not known any MSO to publish those numbers. Any sane MSO is handing out D3 modems even if they are still running a D2 network, so new connections (or replacements) should be D3. Yes... All D3 modems are required to be IPv6 ready. So, any plant where the customers have D3, it's a configuration issue to provide IPv6 once the rest of the network is ready. you only need about five If you're thinking of five major cable operators, they aren't each one network but are a group of franchises/markets running more or less independent of each other. Not so much as you think on the IP side of things. Yes, and I mentioned that. So once you have 50% of the potential content sources v6 capable and 50% of the potential eyeballs v6 capable, you have potentially 25% of internet traffic on v6. And that can be done with the migration of enough networks to count on your fingers. Heh. No it can't. You grossly underestimate the work necessary to get the eyeballs v6 capable. If Comcast has to replace as little as 10% of their modems, that'd be over 1mil. That's not going to happen overnight. (or even a month.) No, you grossly underestimate the motivation that will exist to get the eyeball networks v6 capable. Comcast has over 20 million subscribers. Their subscribers fall into two categories: 1. Subscribers with their own gear: Comcast will probably send them a note that tells them it's time to buy new gear with specifications on what to buy. 2. Subscribers that pay Comcast a monthly fee to rent that gear: Comcast will probably swap out their gear. Yes, it may be over a $million, but, Comcast collects $millions per month in gear rental fees from which that can easily be covered. There will be no real problem in terms of the cost here. On the flip side of the equation, all of them are going to have to start delivering new services on IPv6 equipment with IPv6 support pretty soon anyway. As such, bringing the existing customers forward becomes a cost reduction measure because it's always cheaper to manage a network were everyone is
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/11/2011 5:34 PM, Owen DeLong wrote: No, you grossly underestimate the motivation that will exist to get the eyeball networks v6 capable. eyeball networks... we hack and patch them together. Silly putty is very useful. IPv6 rollouts are no different. Just more silly putty. IPv4 support for all the applications and appliances that don't support IPv6 is what will suck. So, don't worry about the ISP. Core networks are gearing up super fast (they've actually been at it for years, just not rolled it out), eyeballs will hack and patch easy enough (CPEs aren't that large a deal, and 6rd even gets us around internal v4 only problems in those isolated areas), many standard services on the net are v6 capable. Those which aren't, that's their own fault. They've had decades. :) Jack
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
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)
