Re: 32 bits ASN on Cisco
You can still request a 16 bit ASN from the registries, so if this is a concern for a new deployment you're not out of luck (yet). There is a compatibility mechanism, so you can still receive routes sourced from (or passing through) 32 bit ASNs, they will simply appear as AS 23456. Even if you have 32-bit ASN-compatible gear, all your direct peers need to support it as well (more or less), and many providers still don't have support for this yet (for example, the 7600 platform only just got support with 12.2(33) SRE0, and no one in their right mind is running it in production yet). A great resource for information on 32-bit ASN's is http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf GG On Sun, Apr 11, 2010 at 1:33 AM, Franck Martin fra...@genius.com wrote: Sorry if it is not the right forum, but I'm trying to get a grip on 32Bits ASN on Cisco I see that feature is available on 12.4(24)T http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html Which is available only for new gear. I don't know how new is the 1800,2800,3800 series, but I know networks still running on 2500 and 2600. So does it mean that to get 32bit ASN you need to get new gear? Seems to me 12.4(24)T is relatively new, and that this feature is not available on the mainline IOS 12.4? So in one hand RIR allocates 32bit ASN, but on the other hand, it is hard to implement it on current equipment? Is that a (un)fair assessment?
Re: 32 bits ASN on Cisco
Yes Gary, I understood how to run 16bit ASN with 32bit ASN, I'm just trying to confirm/understand how it is supported today on Cisco hardware. I have seen for instance policy change in APNIC, as since this year they assign 32bits ASN (which could fall in the 16bit part if you are lucky) but if you want a 16bit, then you need to justify. I feel this policy is a bit premature as hardware does not support it. I guess this exhaustion is not as critical as for IPv4, but still... To come back, to your statement that says it is just supported on 7200, means you cannot use a 32bit ASN in production today on any hardware? - Original Message - From: Gary T. Giesen gie...@snickers.org To: Franck Martin fra...@genius.com Cc: nanog@nanog.org Sent: Sunday, 11 April, 2010 6:36:01 PM Subject: Re: 32 bits ASN on Cisco You can still request a 16 bit ASN from the registries, so if this is a concern for a new deployment you're not out of luck (yet). There is a compatibility mechanism, so you can still receive routes sourced from (or passing through) 32 bit ASNs, they will simply appear as AS 23456. Even if you have 32-bit ASN-compatible gear, all your direct peers need to support it as well (more or less), and many providers still don't have support for this yet (for example, the 7600 platform only just got support with 12.2(33) SRE0, and no one in their right mind is running it in production yet). A great resource for information on 32-bit ASN's is http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf GG
Commodore PET, was: Re: legacy /8
Roland Perry wrote: There are at least two sources which date the PET to Winter CES and Jan 1977, but I agree that June CES is where production items would be first shown; however by then schools were out and my project was finished (I was studying to be maths teacher). I thought people might like to know: According to the book On the edge by Brian Bagnall the first showing was in March 1977. In January of 1977 it was announced at the CES. The machine was there but had a tiny but hard to find bug that prevented it from working until the last day, then when it worked the image was upside down. It was shown to John Roach, then an operations guy of Rat Shack. He was interested to have it distributed in their stores but because Jack Tramiel also demanded they'd order a lot of Commodore's calculators John Roach didn't go through with the deal and decided they could make their own... missed opportunities. quoting page56, The birth of an Industry Leonard Tramiel unveiled the PET 2001 to the world. The first showing of the PET was at the Hanover Faire in Germany in March 1977, recalls Leonard. It was shown first at the Hanover Faire in that hand-carved wooden case. (..) A month later they would unveil the PET in the United States (end quote) That was at the West Coast Computer Faire in mid-April of 1977, organised by Jim Warren of Dr. Dobbs Journal. The first major gather of hobbyists and microcomputer companies. Apparently an important moment in the microcomputer history. Greetings, Jeroen
Solar Flux (was: Re: China prefix hijack)
Paul Vixie vi...@isc.org writes: i'm more inclined to blame the heavy solar wind this month and to assume that chinanet's routers don't use ECC on the RAM containing their RIBs and that chinanet's router jockeys are in quite a sweat about this bad publicity. -- Paul Vixie KI6YSY That is likely to be an increasing problem in upcoming months/years. Solar cycle 24 started in August '09; we're ramping up on the way out of a more serious than usual sunspot minimum. We've seen great increases in CPU and memory speeds as well as disk densities since the last maximum (March 2000). Speccing ECC memory is a reasonable start, but this sort of thing has been a problem in the past (anyone remember the Sun UltraSPARC CPUs that had problems last time around?) and will no doubt bite us again. Rob Seastrom, AI4UC
Seeking Amazon EC2 abuse contact
Could someone from Amazon EC2 please contact me off-list regarding an abuse issue from one of their IPs? Alternatively, could someone please send me the contact details of someone there? E-mailing the abuse e-mail listed in WHOIS per their instructions, including all pertinent data, results in an auto-reply indicating to use a form on their site. Submitting the form results in There has been an error while submitting your data. Please try again later. Calling their supposed NOC (as per WHOIS) results in You have reached the legal department at Amazon...please leave a message. Thanks -- Erik Caneris Inc. Tel: 647-723-6365 Fax: 647-723-5365 Toll-free: 1-888-444-8843 www.caneris.com
Re: Solar Flux (was: Re: China prefix hijack)
That is likely to be an increasing problem in upcoming months/years. Solar cycle 24 started in August '09; we're ramping up on the way out of a more serious than usual sunspot minimum. I wonder what kind of buildings are less susceptible to these kinds of problems. And is there a good way to test your data centre to come up with some kind of vulnerability rating? Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping and how could you retrofit a Faraday cage onto a rack or two of gear? --Michael Dillon
Re: 32 bits ASN on Cisco
The reference to a IOS supporting 32-bit ASNs being too fresh was specific to the 7600 platform and the SRE software train. As of SRE1, for example, NetFlow v9 template still advertizes source and destination ASNs fields as 2 bytes long. Cheers, Paolo On Sun, Apr 11, 2010 at 11:15:57PM +1200, Franck Martin wrote: This is the document I quoted in my first email. ok for 2500, 2600 they are EOL, but still out there.. but Gary says the software is too new to be used on prod, and you say there is no problem. So who is right? I see that 12.4(24)T has been released in Feb last year. Do people follow the router upgrades closely? What is the common sense? - Original Message - From: ??ukasz Bromirski luk...@bromirski.net To: nanog@nanog.org Sent: Sunday, 11 April, 2010 10:31:05 PM Subject: Re: 32 bits ASN on Cisco On 2010-04-11 12:15, Franck Martin wrote: To come back, to your statement that says it is just supported on 7200, means you cannot use a 32bit ASN in production today on any hardware? It doesn't mean anything like that. As the software is available for some time already, you can run 32bit ASN in production today, and actually people do that. Nothing fancy. For the list of software versions supporting 32 bit ASN please referer to this document: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html But yes, you can't run it on 2500 and 2600 as they're for long time End of Life/Engineering/Support/Everything. -- Everything will be okay in the end. | ??ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net
Re: legacy /8
On 4/3/2010 1:39 PM, valdis.kletni...@vt.edu wrote: On Sat, 03 Apr 2010 08:06:44 EDT, Jeffrey Lyon said: For small companies the cost of moving to IPv6 is far too great, especially when we rely on certain DDoS mitigation gear that does not yet have an IPv6 equivalent. So? How many people are *realistically* being hit by IPv6 DDoS right now? (I saw a number in the last 2-3 days that 2-3% of spam is now being delivered via SMTP-over-IPv6). You may not need that gear as much as you thought... Did you tell your mitigation gear vendor 5 years ago that their next model needed to have IPv6 support? Given that currently most stuff is dual-stack, and IPv6 isn't totally widespread, what are the effects of doing IPv6 DDoS mitigation by simply turning off IPv6 on your upstream link and letting traffic fall back to IPv4 where you have mitigation gear? Not a valid argument. When ipv6 gets widely used then the DDOS will follow it. I have to agree with the previous poster about not wanting to move until his DDOS mitigation gear supports V6. Many of the security products i use are just now starting to go v6 capable. I would not want to move to V6 even if i could until all of my security gear/software is properly V6 tested.
Re: Solar Flux (was: Re: China prefix hijack)
On Sun, 11 Apr 2010 16:58:40 BST, Michael Dillon said: Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping and how could you retrofit a Faraday cage onto a rack or two of gear? Scientists build neutrino detectors in mines 8,000 feet underground because that much rock provides *partial* shielding against cosmic rays causing spurious detection events. Fortunately, the sun emits almost no cosmic rays. It does however spew a lot of less energetic particles that will cause single-bit upsets in electronic gear. Time to double-check that all your gear has ECC ram - the problem with the UltraSparc CPUs last time was that they had some cache chips built by IBM. IBM said Use these chips in an ECC config, but Sun didn't. The ions hit, and the resulting bit-flips crashed the machines. Incidentally, Sun sued IBM over that, and the judge basically said Well, IBM *told* you not to do that up front. Suit dismissed. One of the other big issues will be noise on satellite and microwave links screwing your S/N ratio. The one that scares me? Inducted currents on long runs of copper. You get a 200-300 mile 765Kva transmission line, and a solar flare hits, the Earth's magnetic field gets dented, so the field lines move relative to the stationary copper cable, and suddenly you have several thousand extra amps popping out one end of that cable. Ka-blam. The big danger there is that many substations are not designed for that - so it would basically *permanently* destroy that substation and they'd get to replace it. And of course, that's a several-weeks repair even if it's the only one - and in that sort of case, there will be *dozens* of step-down transformers blown up the same afternoon. How long can you run on diesel? ;) pgp8MMEClsA6V.pgp Description: PGP signature
Re: legacy /8
On 4/3/2010 1:31 PM, George Bonser wrote: -Original Message- From: Larry Sheldon [mailto:larryshel...@cox.net] Sent: Saturday, April 03, 2010 8:43 AM To: nanog@nanog.org Subject: Re: legacy /8 On 4/3/2010 10:34, Michael Dillon wrote: That adoption is so low at this point really says that it has failed. In the real world, there is no success or failure, only next steps. At this point, IPv4 has failed, Failed? Really?!!?! Failed in the sense that I am not sure there is enough time left to really get v6 deployment going before we hit the wall. It is like skydiving and waiting too long to open the chute. Any school teaching v4 at this point other than as a legacy protocol that they teach on the second year because they might see it in the wild should be closed down. All new instruction that this point should begin and end with v6 with v4 as an aside. But that isn't. We've been dealing with the IPV4 myth now for over 7 years that i have followed it. It's about as valid as the exaflood myth. Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form dying just by seeing all the arm flailing going around.
Re: 32 bits ASN on Cisco
There's quite a bit of hardware that does support it, including JunOS since 9.1 (I believe). But there's still a few lagging platforms (especially on the Cisco side) that does not yet support it. IOS 15 does indeed support it, so there is support for it in mainline code on the smaller routers. It's just that a few key platforms are still missing it (or the code is too new to be useful). Keep in mind, the 2500's and I believe the 2600's have been EOL'd for quite some time now, so you will never likely see support for those platforms. GG On Sun, Apr 11, 2010 at 6:15 AM, Franck Martin fra...@genius.com wrote: Yes Gary, I understood how to run 16bit ASN with 32bit ASN, I'm just trying to confirm/understand how it is supported today on Cisco hardware. I have seen for instance policy change in APNIC, as since this year they assign 32bits ASN (which could fall in the 16bit part if you are lucky) but if you want a 16bit, then you need to justify. I feel this policy is a bit premature as hardware does not support it. I guess this exhaustion is not as critical as for IPv4, but still... To come back, to your statement that says it is just supported on 7200, means you cannot use a 32bit ASN in production today on any hardware? - Original Message - From: Gary T. Giesen gie...@snickers.org To: Franck Martin fra...@genius.com Cc: nanog@nanog.org Sent: Sunday, 11 April, 2010 6:36:01 PM Subject: Re: 32 bits ASN on Cisco You can still request a 16 bit ASN from the registries, so if this is a concern for a new deployment you're not out of luck (yet). There is a compatibility mechanism, so you can still receive routes sourced from (or passing through) 32 bit ASNs, they will simply appear as AS 23456. Even if you have 32-bit ASN-compatible gear, all your direct peers need to support it as well (more or less), and many providers still don't have support for this yet (for example, the 7600 platform only just got support with 12.2(33) SRE0, and no one in their right mind is running it in production yet). A great resource for information on 32-bit ASN's is http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf GG
Re: ARIN IP6 policy for those with legacy IP4 Space
On Apr 11, 2010, at 9:17 AM, Joe Greco wrote: Put less tersely: We were assigned space, under a policy whose purpose was primarily to guarantee uniqueness in IPv4 numbering. As with other legacy holders, we obtained portable space to avoid the technical problems associated with renumbering, problems with in-addr.arpa subdelegation, etc. So far, correct. Part of that was an understanding that the space was ours (let's not get distracted by any ownership debate, but just agree for the sake of this point that it was definitely understood that we'd possess it). This served the good of the Internet by promoting stability within an AS and allowed us to spend engineering time on finer points (such as maintaining PTR's) rather than renumbering gear every time we changed upstreams. This is fictitious unless you are claiming that your allocation predates: RFC2050 November, 1996 RFC1466 May, 1993 RFC1174 August, 1990 Prior to that, it was less clear, but, the concept was still generally justified need so long as that need persisted. Which ours does. Eventually InterNIC was disbanded, and components went in various directions. ARIN landed the numbering assignment portion of InterNIC. Along with that, maintenance of the legacy resources drifted along to ARIN. Actually, ARIN was spun off from InterNIC (containing most of the same staff that had been doing the job at InterNIC) well before InterNIC was disbanded. Is there an effective difference or are you just quibbling? For the purposes of this discussion, I submit my description was suitable to describe what happened. Your description makes it sound like there was limited or no continuity between the former and the current registration services entity. I point out that ARIN was formed run by and including most of the IP-related staff from InterNIC. I consider that a substantive distinction. ARIN might not have a contract with us, or with other legacy holders. It wasn't our choice for ARIN to be tasked with holding up InterNIC's end of things. However, it's likely that they've concluded that they better do so, because if they don't, it'll probably turn into a costly legal battle on many fronts, and I doubt ARIN has the budget for that. This is going to be one of those situations that could become a legal battle on many fronts either way. On the one hand you have legacy holders who have no contractual right to services from anyone (If you want to pursue InterNIC for failing to live up to whatever agreement you have/had with them, I wish you the very best of luck in that endeavor, especially since you don't have a written contract from them, either). On the other hand, in a relatively short timeframe, you are likely to have litigants asking why ARIN has failed to reclaim/reuse the underutilized IPv4 space sitting in so many legacy registrations. Which of those two bodies of litigants is larger or better funded is left as an exercise for the reader. Nonetheless, ARIN is going to be in an interesting position between those two groups (which one is rock and which is hard place is also left as an exercise for the reader) going forward regardless of what action is taken by ARIN in this area. That is why the legacy RSA is important. It represents ARIN trying very hard to codify and defend the rights of the legacy holders. Yes, but according to the statistics provided by Mr. Curran, it looks like few legacy space holders are actually adopting the LRSA. So far, yes. That's unfortunate. Like many tech people, you seem to believe that the absence of a contract means that there's no responsibility, and that InterNIC's having been disbanded absolves ARIN from responsibility. In the real world, things are not so simple. The courts have much experience at looking at real world situations and determining what should happen. These outcomes are not always predictable and frequently don't seem to have obvious results, but they're generally expensive fights. No, actually, quite the opposite. I believe that BOTH legacy holders and ARIN have responsibilities even though there is no contract. I believe that ARIN is, however, responsible to the community as it exists today and not in any way responsible to legacy holders who choose to ignore that community and their responsibilities to it. The reality is that the community has evolved. For the most part, the community has been willing to let legacy holders live in their little reality distortion bubble and accommodated their eccentricities. I think that is as it should be, to some extent. On the other hand, I think the history now shows that ARIN's failure to immediately institute the same renewal pricing model on legacy holders as on new registrants has created an unfortunate disparity and a number of unfortunate perceptions. Contrast this with APNIC and the domain registrars/registries shortly after the ARIN
RE: Solar Flux
I wonder what kind of buildings are less susceptible to these kinds of problems. And is there a good way to test your data centre to come up with some kind of vulnerability rating? Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping and how could you retrofit a Faraday cage onto a rack or two of gear? Unfortunately, you're in the wrong part of the spectrum there. Shielding against EMI to protect against solar flares is like ... well, it's like writing IPv6 ACLs to protect your IPv4 network. You're looking in the wrong place. Solar flares have all sorts of effects on earth, including every piece of the EM spectrum (you get ionization, which has secondary effects like interfering with the amateur bands so ham operators can't click at each other very well, and induction of current in long wires because of the magnetic effects), but the nasty effects from our point of view are likely to be in piles of hard and soft x-rays and proton storms. So to answer your questions directly: less susceptible building would be buildings which are constructed of hundred-foot thick solid lead walls under a mile of rock in a salt mine under a mountain in Wyoming. And no, Faraday cages don't protect against cosmic rays (or most of the other kinds of radiation that a solar flare emits directly). Of course, IANAPhysicist, but I did play one in college for a while. On the other hand, another effect of solar flares is UV radiation, so a good pair of sunglasses and some high-SPF sunblock would be good to have, plus make you look less like a nerd. Unless you use that zinc stuff on your nose, in which case you look more like a nerd. YMMV. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 j...@opus1.comhttp://www.opus1.com/jms
Re: legacy /8
William Warren hescomins...@emmanuelcomputerconsulting.com writes: We've been dealing with the IPV4 myth now for over 7 years that i have followed it. It's about as valid as the exaflood myth. Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form dying just by seeing all the arm flailing going around. anyone claiming that the then-existing ipv4 will stop working when the free pool runs out is indeed doing the chicken little dance. however, for many networks, growth is life, and for them, free pool depletion is a problem. -- Paul Vixie Chairman, ARIN BoT
Re: legacy /8
On Sun, 11 Apr 2010 12:31:28 EDT, William Warren said: On 4/3/2010 1:39 PM, valdis.kletni...@vt.edu wrote: Given that currently most stuff is dual-stack, and IPv6 isn't totally widespread, what are the effects of doing IPv6 DDoS mitigation by simply turning off IPv6 on your upstream link and letting traffic fall back to IPv4 where you have mitigation gear? Not a valid argument. When ipv6 gets widely used then the DDOS will follow it. Totally valid. IPv6 isn't heavily used *currently*, so it may be perfectly acceptable to deal with the mythological IPv6 DDoS by saying screw it, turn off the IPv6 prefix, deal with customers on IPv4-only for a few hours. After all, that's *EXACTLY* the way you're doing business now - IPv4 only. So that's obviously a viable way to deal with an IPv6 DDoS - do *exactly what you're doing now*. pgpHvYxXlhv8S.pgp Description: PGP signature
Re: 32 bits ASN on Cisco
The AS4 Wiki has a list of software support for most vendors, as well as a bunch of other information related to 32-bit ASNs. http://as4.cluepon.net/index.php/Software_Support More information is always welcome, if you'd like to add something. Greg -- Greg Hankins ghank...@mindspring.com
Re: ARIN IP6 policy for those with legacy IP4 Space
Owen, On Apr 11, 2010, at 6:39 AM, Owen DeLong wrote: Instead, we have a situation where the mere mention of requiring legacy holders to pay a token annual fee like the rest of IP end-users in the ARIN region leads to discussions like this. I don't believe the issue is the token annual fee. My guess is that most legacy holders would be willing to pay a reasonable service fee to cover rDNS and registration database maintenance (they'd probably be more willing if there were multiple providers of that service, but that's a separate topic). I suspect the issue might be more related to stuff like: Especially in light of the fact that if you are sitting on excess resources and want to be able to transfer them under NRPM 8.3, you will need to bring them under LRSA or RSA first and the successor who acquires them from you (under 8.2 or 8.3) will need to sign an RSA for the transfer to be valid. You appear to be assuming folks are willing to accept ARIN has the right and ability to assert the above (and more). That is, that the entire policy regime under which the NRPM has been defined is one that legacy holders are implicitly bound simply because they happen to operate in ARIN's service region and received IP addresses in the past without any real terms and conditions or formal agreement. I imagine the validity of your assumption will not be established without a definitive legal ruling. I'm sure it will be an interesting court case. In any event, it seems clear that some feel that entering into agreements and paying fees in order to obtain IPv6 address space is hindering deployment of IPv6. While ARIN has in the past waived fees for IPv6, I don't believe there has ever been (nor is there likely to be) a waiver of signing the RSA. Folks who want that should probably get over it. To try to bring this back to topics relevant to NANOG (and not ARIN's PPML), the real issue is that pragmatically speaking, the only obvious alternative to IPv6 is multi-layer NAT and it seems some people are trying to tell you that regardless of how much you might hate multi-layer NAT, how much more expensive you believe it will be operationally, and how much more limiting and fragile it will be because it breaks the end-to-end paradigm, they believe it to be a workable solution. Are there _any_ case studies, analyses with actual data, etc. that shows multi-layer NAT is not workable (scalable, operationally tractable, etc.) or at least is more expensive than IPv6? Regards, -drc
Re: legacy /8
On Apr 11, 2010, at 8:09 AM, Owen DeLong wrote: Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form dying just by seeing all the arm flailing going around. IPv4 will not die in 2 years. I'd wager it won't be dead in 20 years. Of course, a lot depends on what is meant by dying. Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months). Growth stopping is extremely unlikely. Growth becoming significantly more expensive is guaranteed. Address utilization efficiency will increase as people see the value in public IPv4 addresses. ISPs interested in continuing to grow will do what it takes to obtain IPv4 addresses and folks with allocated-but-unused addresses will be happy to oblige (particularly when they accept that they only need a couple of public IP addresses for their entire network). At some point, it may be that the cost of obtaining IPv4 will outstrip the cost of migrating to IPv6. If we're lucky. Regards, -drc
Re: legacy /8
On Apr 12, 2010, at 12:39 AM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: IPv6 isn't heavily used *currently*, so it may be perfectly acceptable to deal with the mythological IPv6 DDoS The only IPv6-related DDoS attacks of which I'm aware to date is miscreants going after 6-to-4 gateways in order to disrupt one another's IPv6-tunneled botnet CC traffic. However, as soon as there are moneymaking opportunities to be had and/or ideological vendettas to be pursued by launching pure IPv6-based DDoS attacks, we can all rest assured they won't let the side down. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: legacy /8
David Conrad d...@virtualized.org writes: Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months). Growth stopping is extremely unlikely. Growth becoming significantly more expensive is guaranteed. ... more expensive for whom, though? if someone has to find existing address space and transfer it at some payment to the current holder in order to grow their own network, that's a direct expense. if this became common and resulted in significant deaggregation, then everybody else attached in some way to the global routing table would also have to pay some costs, which would be indirect expenses. unless a market in routing slots appears, there's no way for the direct beneficiaries of deaggregation to underwrite the indirect costs of same. at a systemic level, i'd characterize the cost of that kind of growth as instability rather merely expense. Address utilization efficiency will increase as people see the value in public IPv4 addresses. ISPs interested in continuing to grow will do what it takes to obtain IPv4 addresses and folks with allocated- but- unused addresses will be happy to oblige (particularly when they accept that they only need a couple of public IP addresses for their entire network). At some point, it may be that the cost of obtaining IPv4 will outstrip the cost of migrating to IPv6. If we're lucky. the cost:benefit of using ipv6 depends on what other people have deployed. that is, when most of the people that an operator and their customers want to talk to are already running ipv6, then the cost:benefit will be compelling compared to any form of continued use of ipv4. arguments about the nature and location of that tipping point amount to reading tea leaves. nevertheless if everybody who can deploy dual-stack does so, we'll reach that tipping point sooner and it'll be less spectacular. -- Paul Vixie Chairman, ARIN BoT
Re: ARIN IP6 policy for those with legacy IP4 Space
On Apr 11, 2010, at 11:21 AM, David Conrad wrote: Owen, On Apr 11, 2010, at 6:39 AM, Owen DeLong wrote: Instead, we have a situation where the mere mention of requiring legacy holders to pay a token annual fee like the rest of IP end-users in the ARIN region leads to discussions like this. I don't believe the issue is the token annual fee. My guess is that most legacy holders would be willing to pay a reasonable service fee to cover rDNS and registration database maintenance (they'd probably be more willing if there were multiple providers of that service, but that's a separate topic). I suspect the issue might be more related to stuff like: Especially in light of the fact that if you are sitting on excess resources and want to be able to transfer them under NRPM 8.3, you will need to bring them under LRSA or RSA first and the successor who acquires them from you (under 8.2 or 8.3) will need to sign an RSA for the transfer to be valid. You appear to be assuming folks are willing to accept ARIN has the right and ability to assert the above (and more). That is, that the entire policy regime under which the NRPM has been defined is one that legacy holders are implicitly bound simply because they happen to operate in ARIN's service region and received IP addresses in the past without any real terms and conditions or formal agreement. I imagine the validity of your assumption will not be established without a definitive legal ruling. I'm sure it will be an interesting court case. Well, if they want to operate under the previous regime, then, they should simply return any excess resources now rather than attempting to monetize them under newer policies as that was the policy in place at the time. Certainly they should operate under one of those two regimes rather than some alternate reality not related to either. Interestingly, APNIC seems to have had little trouble asserting such in their region, but, I realize the regulatory framework in the ARIN region is somewhat different. In any event, it seems clear that some feel that entering into agreements and paying fees in order to obtain IPv6 address space is hindering deployment of IPv6. While ARIN has in the past waived fees for IPv6, I don't believe there has ever been (nor is there likely to be) a waiver of signing the RSA. Folks who want that should probably get over it. I believe you are correct about that. To try to bring this back to topics relevant to NANOG (and not ARIN's PPML), the real issue is that pragmatically speaking, the only obvious alternative to IPv6 is multi-layer NAT and it seems some people are trying to tell you that regardless of how much you might hate multi-layer NAT, how much more expensive you believe it will be operationally, and how much more limiting and fragile it will be because it breaks the end-to-end paradigm, they believe it to be a workable solution. Are there _any_ case studies, analyses with actual data, etc. that shows multi-layer NAT is not workable (scalable, operationally tractable, etc.) or at least is more expensive than IPv6? Can you point to a single working deployment of multi-layer NAT? I can recall experiences with several attempts which had varying levels of dysfunction. Some actually done at NANOG meetings, for example. As such, I'm willing to say that there is at least anecdotal evidence that multi-layer NAT either is not workable or has not yet been made workable. Owen
Re: legacy /8
On Apr 11, 2010, at 11:34 AM, David Conrad wrote: On Apr 11, 2010, at 8:09 AM, Owen DeLong wrote: Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form dying just by seeing all the arm flailing going around. IPv4 will not die in 2 years. I'd wager it won't be dead in 20 years. Of course, a lot depends on what is meant by dying. Yep. Assuming IPv6 catches on in the post-runout crisis (and I think it will), I suspect that IPv4 will be largely deprecated on the wide-spread internet within about 5-10 years of IPv6 practical ubiquity. I suspect it will ALWAYS be used in some niches somewhere. Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months). Growth stopping is extremely unlikely. Growth becoming significantly more expensive is guaranteed. Address utilization efficiency will increase as people see the value in public IPv4 addresses. ISPs interested in continuing to grow will do what it takes to obtain IPv4 addresses and folks with allocated-but-unused addresses will be happy to oblige (particularly when they accept that they only need a couple of public IP addresses for their entire network). At some point, it may be that the cost of obtaining IPv4 will outstrip the cost of migrating to IPv6. If we're lucky. Eventually, utilization efficiency will get close to 100% and growth will, therefore stop. Note, I was specific about IPv4 accessible hosts, as in hosts which you can send a TCP SYN packet to, not merely hosts which can originate connections. Multi-layer NAT may help increase the number of IPv4-non-accessible hosts, but, it can do little to help increase accessible host count. Owen
Re: ARIN IP6 policy for those with legacy IP4 Space
On Apr 11, 2010, at 9:03 AM, Owen DeLong wrote: Well, if they want to operate under the previous regime, then, they should simply return any excess resources now rather than attempting to monetize them under newer policies as that was the policy in place at the time. Why? There were no policies to restrict how address space was transferred (or anything else) when they got their space. Certainly they should operate under one of those two regimes rather than some alternate reality not related to either. When most of the legacy space was handed out, there were no restrictions on what you could do/not do with address space simply because no one considered it necessary. Much later, a policy regime was established that explicitly limits rights and you seem surprised when the legacy holders aren't all that interested. Interestingly, APNIC seems to have had little trouble asserting such in their region, Hah. I suspect you misunderstand. Can you point to a single working deployment of multi-layer NAT? I suppose it depends on your definition of working. I've been told there are entire countries that operate behind multi-later NAT (primarily because the regulatory regime required ISPs obtain addresses from the PTT and the PTT would only hand out a couple of IP addresses). I have put wireless gateways on NAT'd hotel networks and it works for client services, for some value of the variable works. I can recall experiences with several attempts which had varying levels of dysfunction. Some actually done at NANOG meetings, for example. As such, I'm willing to say that there is at least anecdotal evidence that multi-layer NAT either is not workable or has not yet been made workable. The problem is, anecdotal evidence isn't particularly convincing to folks who are trying to decide whether to fire folks so they'll have money to spend on upgrading their systems to support IPv6. Regards, -drc
Re: Solar Flux (was: Re: China prefix hijack)
On Sun, Apr 11, 2010 at 7:07 AM, Robert E. Seastrom r...@seastrom.com wrote: We've seen great increases in CPU and memory speeds as well as disk densities since the last maximum (March 2000). Speccing ECC memory is a reasonable start, but this sort of thing has been a problem in the past (anyone remember the Sun UltraSPARC CPUs that had problems last time around?) and will no doubt bite us again. Sun's problem had an easy solution - and it's exactly the one you've mentioned - ECC. The issue with the UltraSPARC II's was that they had enough redundancy to detect a problem (Parity), but not enough to correct the problem (ECC). They also (initially) had a very abrupt handling of such errors - they would basically panic and restart. From the UltraSPARC III's they fixed this problem by sticking with Parity in the L1 cache (write-through, so if you get a parity error you can just dump the cache and re-read from memory or a higher cache), but using ECC on the L2 and higher (write-back) caches. The memory and all datapaths were already protected with ECC in everything but the low-end systems. It does raise a very interesting question though - how many systems are you running that don't use ECC _everywhere_? (CPU, memory and datapath) Unlike many years ago, today Parity memory is basically non-existent, which means if you're not using ECC then you're probably suffering relatively regular single-bit errors without knowing it. In network devices that's less of an issue as you can normally rely on higher-level protocols to detect/correct the errors, but if you're not using ECC in your servers then you're asking for (silent) trouble... Scott.
Re: Solar Flux (was: Re: China prefix hijack)
Are we thinking its going to get worse?? Did anyone else see the intelsat spacecraft failure last week?? Sent using my GCI BlackBerry - Original Message - From: valdis.kletni...@vt.edu valdis.kletni...@vt.edu To: Michael Dillon wavetos...@googlemail.com Cc: Paul Vixie vi...@isc.org; Robert E. Seastrom r...@seastrom.com; na...@merit.edu na...@merit.edu Sent: Sun Apr 11 08:36:05 2010 Subject: Re: Solar Flux (was: Re: China prefix hijack) On Sun, 11 Apr 2010 16:58:40 BST, Michael Dillon said: Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping and how could you retrofit a Faraday cage onto a rack or two of gear? Scientists build neutrino detectors in mines 8,000 feet underground because that much rock provides *partial* shielding against cosmic rays causing spurious detection events. Fortunately, the sun emits almost no cosmic rays. It does however spew a lot of less energetic particles that will cause single-bit upsets in electronic gear. Time to double-check that all your gear has ECC ram - the problem with the UltraSparc CPUs last time was that they had some cache chips built by IBM. IBM said Use these chips in an ECC config, but Sun didn't. The ions hit, and the resulting bit-flips crashed the machines. Incidentally, Sun sued IBM over that, and the judge basically said Well, IBM *told* you not to do that up front. Suit dismissed. One of the other big issues will be noise on satellite and microwave links screwing your S/N ratio. The one that scares me? Inducted currents on long runs of copper. You get a 200-300 mile 765Kva transmission line, and a solar flare hits, the Earth's magnetic field gets dented, so the field lines move relative to the stationary copper cable, and suddenly you have several thousand extra amps popping out one end of that cable. Ka-blam. The big danger there is that many substations are not designed for that - so it would basically *permanently* destroy that substation and they'd get to replace it. And of course, that's a several-weeks repair even if it's the only one - and in that sort of case, there will be *dozens* of step-down transformers blown up the same afternoon. How long can you run on diesel? ;)
Re: legacy /8
Paul, On Apr 11, 2010, at 8:58 AM, Paul Vixie wrote: David Conrad d...@virtualized.org writes: Growth becoming significantly more expensive is guaranteed. ... more expensive for whom, though? ISPs requiring space will have to pay more and I fully anticipate that cost will propagate down to end users. In (some version of) an ideal world, IPv6 would be at no cost to end users, thereby incentivizing them to encourage their favorite porn sites (et al) to offer their wares via IPv6. unless a market in routing slots appears, there's no way for the direct beneficiaries of deaggregation to underwrite the indirect costs of same. And that's different from how it's always been in what way? My tea leaf reading is that history will repeat itself. As it was in the mid-90's, as soon as routers fall over ISPs will deploy prefix length (or other) filters to protect their own infrastructure as everybody scrambles to come up with some hack that won't be a solution, but will allow folks to limp along. Over time, router vendors will improve their kit, ISPs will rotate out routers that can't deal with the size/flux of the bigger routing table (passing the cost on to their customers, of course), and commercial pressures will force the removal of filters. Until the next go around since IPv6 doesn't solve the routing scalability problem. The nice thing about history repeating itself is that you know when to go out and get the popcorn. Regards, -drc
Re: Solar Flux (was: Re: China prefix hijack)
There is a guy who walks aroung Hyde Park Corner in London with a sandwich board that says its going to get worse. Perhaps Ill go and talk to him next weekend and see what he thinks. -- Leigh --- original message --- From: Warren Bailey wbai...@gci.com Subject: Re: Solar Flux (was: Re: China prefix hijack) Date: 11th April 2010 Time: 9:14:50 pm Are we thinking its going to get worse?? Did anyone else see the intelsat spacecraft failure last week?? Sent using my GCI BlackBerry - Original Message - From: valdis.kletni...@vt.edu valdis.kletni...@vt.edu To: Michael Dillon wavetos...@googlemail.com Cc: Paul Vixie vi...@isc.org; Robert E. Seastrom r...@seastrom.com; na...@merit.edu na...@merit.edu Sent: Sun Apr 11 08:36:05 2010 Subject: Re: Solar Flux (was: Re: China prefix hijack) On Sun, 11 Apr 2010 16:58:40 BST, Michael Dillon said: Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping and how could you retrofit a Faraday cage onto a rack or two of gear? Scientists build neutrino detectors in mines 8,000 feet underground because that much rock provides *partial* shielding against cosmic rays causing spurious detection events. Fortunately, the sun emits almost no cosmic rays. It does however spew a lot of less energetic particles that will cause single-bit upsets in electronic gear. Time to double-check that all your gear has ECC ram - the problem with the UltraSparc CPUs last time was that they had some cache chips built by IBM. IBM said Use these chips in an ECC config, but Sun didn't. The ions hit, and the resulting bit-flips crashed the machines. Incidentally, Sun sued IBM over that, and the judge basically said Well, IBM *told* you not to do that up front. Suit dismissed. One of the other big issues will be noise on satellite and microwave links screwing your S/N ratio. The one that scares me? Inducted currents on long runs of copper. You get a 200-300 mile 765Kva transmission line, and a solar flare hits, the Earth's magnetic field gets dented, so the field lines move relative to the stationary copper cable, and suddenly you have several thousand extra amps popping out one end of that cable. Ka-blam. The big danger there is that many substations are not designed for that - so it would basically *permanently* destroy that substation and they'd get to replace it. And of course, that's a several-weeks repair even if it's the only one - and in that sort of case, there will be *dozens* of step-down transformers blown up the same afternoon. How long can you run on diesel? ;)
Re: Solar Flux (was: Re: China prefix hijack)
Bring cider, he'll be more talkative. Here in Alaska, the natives believed the Aurora was brought by birds - so anything is possible. Though, I will admit - I've read similar craziness on this mailing list. Not craziness, bat shit crazy is probably more appropriate. Sent using my GCI BlackBerry - Original Message - From: Leigh Porter leigh.por...@ukbroadband.com To: Warren Bailey; valdis.kletni...@vt.edu valdis.kletni...@vt.edu; wavetos...@googlemail.com wavetos...@googlemail.com Cc: vi...@isc.org vi...@isc.org; r...@seastrom.com r...@seastrom.com; na...@merit.edu na...@merit.edu Sent: Sun Apr 11 12:39:39 2010 Subject: Re: Solar Flux (was: Re: China prefix hijack) There is a guy who walks aroung Hyde Park Corner in London with a sandwich board that says its going to get worse. Perhaps Ill go and talk to him next weekend and see what he thinks. -- Leigh --- original message --- From: Warren Bailey wbai...@gci.com Subject: Re: Solar Flux (was: Re: China prefix hijack) Date: 11th April 2010 Time: 9:14:50 pm Are we thinking its going to get worse?? Did anyone else see the intelsat spacecraft failure last week?? Sent using my GCI BlackBerry - Original Message - From: valdis.kletni...@vt.edu valdis.kletni...@vt.edu To: Michael Dillon wavetos...@googlemail.com Cc: Paul Vixie vi...@isc.org; Robert E. Seastrom r...@seastrom.com; na...@merit.edu na...@merit.edu Sent: Sun Apr 11 08:36:05 2010 Subject: Re: Solar Flux (was: Re: China prefix hijack) On Sun, 11 Apr 2010 16:58:40 BST, Michael Dillon said: Would a Faraday cage be sufficient to protect against cosmic ray bit-flipping and how could you retrofit a Faraday cage onto a rack or two of gear? Scientists build neutrino detectors in mines 8,000 feet underground because that much rock provides *partial* shielding against cosmic rays causing spurious detection events. Fortunately, the sun emits almost no cosmic rays. It does however spew a lot of less energetic particles that will cause single-bit upsets in electronic gear. Time to double-check that all your gear has ECC ram - the problem with the UltraSparc CPUs last time was that they had some cache chips built by IBM. IBM said Use these chips in an ECC config, but Sun didn't. The ions hit, and the resulting bit-flips crashed the machines. Incidentally, Sun sued IBM over that, and the judge basically said Well, IBM *told* you not to do that up front. Suit dismissed. One of the other big issues will be noise on satellite and microwave links screwing your S/N ratio. The one that scares me? Inducted currents on long runs of copper. You get a 200-300 mile 765Kva transmission line, and a solar flare hits, the Earth's magnetic field gets dented, so the field lines move relative to the stationary copper cable, and suddenly you have several thousand extra amps popping out one end of that cable. Ka-blam. The big danger there is that many substations are not designed for that - so it would basically *permanently* destroy that substation and they'd get to replace it. And of course, that's a several-weeks repair even if it's the only one - and in that sort of case, there will be *dozens* of step-down transformers blown up the same afternoon. How long can you run on diesel? ;)
Re: legacy /8
From: David Conrad d...@virtualized.org Date: Sun, 11 Apr 2010 10:30:05 -1000 unless a market in routing slots appears, there's no way for the direct beneficiaries of deaggregation to underwrite the indirect costs of same. And that's different from how it's always been in what way? when 64MB was all anybody had, deaggregation was rendered ineffective by route filtering. what i've seen more recently is gradual monotonic increase in the size of the full table. if the systemic cost of using all of ipv4 includes a 10X per year step function in routing table size then it will manifest as instability (in both the network and the market). as you have pointed out many times, ipv6 offers the same number of /32's as ipv4. however, a /32 worth of ipv6 is enough for a lifetime even for most multinationals, whereas for ipv4 it's one NAT or ALG box. so, i'm thinking that making ipv4 growth happen beyond pool exhaustion would be a piecemeal affair and that the routing system wouldn't accomodate it painlessly. the rate of expansion of other people's routers seems to fit the growth curve we've seen, but will it fit massive deaggregation? My tea leaf reading is that history will repeat itself. As it was in the mid-90's, as soon as routers fall over ISPs will deploy prefix length (or other) filters to protect their own infrastructure as everybody scrambles to come up with some hack that won't be a solution, but will allow folks to limp along. Over time, router vendors will improve their kit, ISPs will rotate out routers that can't deal with the size/flux of the bigger routing table (passing the cost on to their customers, of course), and commercial pressures will force the removal of filters. Until the next go around since IPv6 doesn't solve the routing scalability problem. instability like we had in the mid-1990's would be far more costly today, given that the internet is now used by the general population and serves a global economy. if the rate of endpoint growth does not continue beyond ipv4 pool exhaustion we'll have a problem. if it does, we'll also have a problem but a different problem. i'd like to pick the easiest problem and for that reason i'm urging dual-stack ipv4/ipv6 for all networks new or old. -- Paul Vixie Chairman, ARIN BoT
RE: Solar Flux (was: Re: China prefix hijack)
The topic of sunspots is certainly familiar from long ago. We had a 7513 that crashed unexpectedly, upon a review of the data available, it was determined that a parity error had occurred. I can't remember the exact error as it was several years ago, but upon a quick search this article seems familiar. http://www.ciscopress.info/en/US/products/hw/switches/ps700/products_tech_no te09186a00801b42bf.shtml Search on cosmic radiation and/or SEU within. -Joe
Re: legacy /8
In message 54701fcf-13ea-44da-8677-26a7c6635...@virtualized.org, David Conrad writes: On Apr 11, 2010, at 10:57 AM, Paul Vixie wrote: i'd like to pick the easiest problem and for that reason i'm urging dual-stack ipv4/ipv6 for all networks new = or old. Is anyone arguing against this? The problem is what happens when there = isn't sufficient IPv4 to do dual stack. On the client side you will still be dual stack and also be using PNAT (single, double or distributed) to more efficiently use the available IPv4 addresses. There will be service providers that provide client address pools for those that can't get IPv4 addresses themselves using technologies like ds-lite to transport the traffic. On the server side you will be able to purchase the use of a IPv4 address and the packets will be tunneled back to you socks like. Eventually most of the traffic will switch to being IPv6 and providers of theses services will disappear as they are no longer profitable to run. Mark Regards, -drc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Solar Flux
On 04/11/2010 06:02 PM, Paul Vixie wrote: Warren Bailey wbai...@gci.com writes: Are we thinking its going to get worse?? i am. looking at some local passive dns data (generated from ISC SIE), we find the following single bit errors by anchoring some searches at the known names and addresses of the f-root server. DNS does not have its own crc or checksum, it relies on UDP and IP for error detection (in which it is weak or nonexistant). i think it's probably time to formalize the study of bit errors in DNS, and then see if we can make a sensible mapping between what we observe and what the solar flux is. because if they're related and we're going to have a strong solar cycle then everybody's insurance rates are about to go up. And to top it all off, how many picojoules are stored in a modern ram cell compared to the same during the last sunspot peak. There is a hidden cost to memory density growth here... -- Pete
Re: ARIN IP6 policy for those with legacy IP4 Space
On Sun, Apr 11, 2010 at 7:08 PM, John Curran jcur...@arin.net wrote: On Apr 11, 2010, at 3:20 PM, David Conrad wrote: When most of the legacy space was handed out, there were no restrictions on what you could do/not do with address space simply because no one considered it necessary. I don't think I can agree with that statement, but for sake of clarity - when do you think this no restriction period actually occurred? John, What restrictions do you believe were imposed on someone requesting a class-C between 4/93 and 9/94 who did not intend to connect to MILNET or NSFNET? For your reference, here's the form then active: http://bill.herrin.us/network/templates/199304-internet-number-template.txt 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
