Re: FCC vs FAA Story
> On Jun 6, 2022, at 09:55, John R. Levine wrote: > > Five years ago everyone knew that C band was coming. A reasonable response > would have been for the FAA to work with the FCC to figure out which > altimeters might be affected (old cruddy ones, we now know), and come up with > a plan and schedule to replace them. If the telcos had to pay some of the > costs, they would have grumbled but done it. If the replacement schedule > weren't done by now, they could live with that, too, so long as there were a > clear date when it'd be done. The FAA could have easily ordered testing to determine which RA models were affected and issued an AD prohibiting their use after a certain date. Once that data was in hand, manufacturers could start working on STCs for replacements and the airlines could add those STCs to their next annuals, just like they did for ADS-B. Both would have a decent case for demanding that the telcos pay for it, and the telcos probably would have paid up. But that opportunity was wasted. > Instead the FAA stuck their fingers in their ears and said no, nothing can > ever change, we can't hear you. Are you surprised the telecom industry is > fed up? Exactly. The FAA wants more delays while they do the work they should have done five years ago, but sorry, that’s not how politics works. The number of daily 5G users is orders of magnitude larger than the number of daily airline users, so the FCC *will* win this battle. Stephen PPL ASEL/IR
Re: NANOG67 - Tipping point of community and sponsor bashing?
On 2016-06-18 12:54, Brandon Ross wrote: On Fri, 17 Jun 2016, Eric Kuhnke wrote: What Randy just wrote is exactly the point I was trying to make in my last email. Some real estate facility owners/managers have got into the mistaken mindset that they can get the greatest value and the most monthly revenue from the square-footage of their building by charging additional MRC XC fees to the tenants of the building. There are some VERY sucessful companies that would strongly disagree with you. When in fact the opposite is true, and we need a concerted community effort to lobby every IX real estate owner with this fact: Your real estate will be MORE valuable and will attract a greater critical mass of carriers, eyeball networks, CDNs, huge hosting providers/colo/VM, etc if you make the crossconnects free. But then why would we want to do that? If you are correct and doing so would raise the value of the real esatate, doesn't that mean that the building managers would be able to charge operators a whole lot more than they are able to today, in aggregate? If the price of XC drops to ~zero, then tenants are going to do a lot more of it and thereby get more value from the IX, which means people will be _willing_ to pay more for that real estate, rather than complaining about XC price-gouging. It's as much perception as it is math. OTOH, if prices climb to unreasonable levels, then more space will (eventually) be made available, e.g. by pushing non-IX tenants out of the building, by laying ample dark fiber to a nearby building for expansion (but still ~free XC) or by a competitor appearing. The problems come with expansion that is _not_ nearby, i.e. XC can no longer be ~free, yet the operator still tries to pretend it's a single facility. There are plenty of folks in the business of transporting bits over long distances; IMHO, an IX shouldn't be one of them. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
Re: Verizon Policy Statement on Net Neutrality
On 28-Feb-15 21:55, Barry Shein wrote: On February 28, 2015 at 17:20 na...@ics-il.net (Mike Hammett) wrote: As I said earlier, there are only so many channels available. Channels added to upload are taken away from download. People use upload so infrequently it would be gross negligence on the provider's behalf. And as I said earlier it's push/pull, give people lousy upload speeds and they won't use services which depend on good upload speeds. And given lousy upload speeds the opportunities to develop for example backup services in a world of terabyte disks is limited. At 1mb/s it takes approx 100,000 seconds to upload 1TB, that's roughly one week, blue sky. OTOH, there are clever tricks you can play to reduce this. For instance, hash all every file before uploading, and if the server has seen that hash before (from another user, or from a previous run by the same user), the server just adds the to your collection of files available to restore--no second upload required. Yes, if you're the first person to backup a new version of Windows or a new movie torrent, your upload time is going to suck, but on average, the time to upload each new file will be close to zero. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Verizon Policy Statement on Net Neutrality
On 27-Feb-15 10:52, Majdi S. Abbas wrote: On Fri, Feb 27, 2015 at 10:45:11AM -0600, Mike Hammett wrote: What about ISPs that aren't world-class dicks? The punishments will continue until they either fold or sell to the duopoly which is large enough to buy whatever act of Congress, court or FCC ruling they require... This case seems to prove that the telco/cable duopoly can't _always_ buy the FCC rulings they desire; every now and then, the US govt surprises us and actually represents the people. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: OT - Verizon/ATT Cell/4G Signal Booster/Repeater
On 16-Dec-14 12:27, John Schiel wrote: One thing you might also want to consider are any calls you make to 911 whilst using a repeater. I use a repeater supplied by T-Mobile and they made it very clear, and I had to specifically acknowledge a statement, that using such a repeater takes away from emergency services being able to find out where you are if you make a 911 call from your mobile. Some may refer to this as a feature, depending on how much tin foil you have laying about, but the users of such device may need to be warned about emergency calls. They'll need to be able to describe where they are to the responding sirens. With any reasonably modern phone, wouldn't this problem only apply to areas where GPS isn't available (e.g. basements) and the system tries to fall back to using tower triangulation? AIUI, part of the registration process's purpose is to give a default location for your new tower so that emergency responders at least know where to start looking if no better location information is available, e.g. because the caller can't speak or is disoriented. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: L6-20P - L6-30R
On 18-Mar-14 17:54, Niels Bakker wrote: * w...@typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]: I have had to do this at times but it is not strictly allowed by codes and not at all recommended. It's an active fire hazard. The cables aren't rated (= built) for the power draw. That's a problem in the other direction, but plugging a 20A device into a 30A feed shouldn't be a hazard at all. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: NYT covers China cyberthreat
On 21-Feb-13 04:25, Kyle Creyts wrote: For another example of this, an acquaintance once told me about the process of getting internationally standardized technologies approved for deployment in China; the process that was described to me involved giving China the standards-based spec that had been drafted and approved, being told that for deployment, they would have to improve upon it in a laundry list of ways to bring it some 5-10 years ahead of the spec, and THEN it would be allowed to be deployed. My recent experience doing exactly this at $EMPLOYER doesn't match this story at all. The main problem, as with several other second world countries, is that the standards you must comply with are only in the local language and you must make your submission in the local language as well. However, if you have a local technical presence, you can often get software approval (or a formal notice of exemption--even for products that contain dangerous features like encryption) in a matter of days or even hours. If you don't, it can drag on for months. Hardware testing can be even worse because it must be performed in their labs and can cost tens of thousands of dollars, but at least that doesn't have to be repeated each time you publish a new version of code. In contrast, first world countries generally publish their standards in, and accept submissions in, English. They also tend not to care about software features, just hardware. The standards tend to be shared across countries (eg. EU/EFTA and US/Canada), or at least they accept test results from third-party labs that can test for all such countries at the same time. As a result, many vendors simply don't bother going past that group--or do it so infrequently that they don't gain the institutional knowledge of how to navigate the approval processes in the other group successfully and with minimal effort/cost. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
. Most customers will buy from a service provider, who lights the fiber. The point of dark fiber is that the service provider gets to decide how to light the fiber to said customers, allowing competition based on innovation. If the fiber owner puts active aggregation equipment in the path, though, that means the technologies available are dictated by that equipment's capabilities--and you have introduced another point of failure into the system. Sure, almost nobody asks for dark fiber today because they know it costs several orders of magnitude more than a T1 or whatever. However, if the price for dark fiber were the same (or lower), latent demand would materialize. Why would I pay through the nose for a T1 when I can light the fiber myself with 10GE for $20/mo? If your customer base is primarily residential with a few businesses (hospitals and schools also count here) then you'll be lucky to sell a handful of L1 connections and some of the people who will be interested will want it for very low bit rate (means low price too) uses like RS-232 over fiber for managing SCADA nodes or other telemetry pieces. Why should the fiber owner care what they use it for? It's just dark fiber, patched from one place to another, so the rental price is the same whether they light it at 10Mb/s or 10x100Gb/s. What you're missing is that in this model, _every_ connection is L1 from the fiber owner's perspective. Let service providers worry about L2 and above. The problem I see is that you seem to think that by building the L1 piece you're going to have ISPs that are eager to serve your customers. If your demographics are like most small towns in the US that just isn't very likely. Any ISP partner is going to have to build and maintain a lot of infrastructure before they can serve the first end user and your no upfront engineering is simply not true unless you're going to configure and run MetroE and/or GPON shelves for them. In any sharing scenario (L1, L2, or L3) the ISP is going to have to connect to you with enough bandwidth to serve those end users as well. How many service providers have expressed interest? Have you talked pricing for the loops and colo space yet? Why would the ISP have to build and maintain a lot of infrastructure? All they need is a fiber-capable Ethernet switch in a colo to turn up their first customer. That's a lot simpler than trying to turn up their first customer via an ILEC's DSLAM, for instance. There's nothing wrong with the muni operating a L2 (or even L3) carrier of last resort, just to ensure that _some_ useful service is available to residents. However, it should (a) be priced high enough to attract competitors and (b) be a distinct entity, treated by the fiber arm as no different from any other L1 customer. None of the shenanigans like the ILECs play, where the wholesale rate to competitors is higher than the retail rate for the ILEC's own service. Its an admirable goal, but you're never going to have CCIEs (probably not even CCNAs) doing installs. Installation is, has been, and will in all likelihood continue to be done by people with limited skill sets. You building your own fiber plant and making it easier for ISPs to connect isn't going to change that. You're missing the simplicity of dark fiber. The carrier orders a L1 circuit from a customer to their facility. The L1 provider just patches one fiber pair to another fiber pair, which can be done by a trained monkey. Then the carrier connects their own equipment to the fiber at their own facility and at the customer site, everything lights up and the spice^Wdata flows. Again, that can be done by a trained monkey. You don't need a CCIE or even a CCNA to do this. Heck, it's even simpler than what's required today for DSL, cable or satellite installers. (Note that inside wiring is a completely separate issue, and carriers _will_ have to train techs on how to do that since few are familiar with fiber, but that is an optional service they can charge extra for. The L1 provider's responsibility ends at the NIU on an outside wall, same as an ILEC's, so it's not their problem in the first place.) S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: The 100 Gbit/s problem in your network
On 11-Feb-13 12:25, Mark Radabaugh wrote: On 2/11/13 9:32 AM, ML wrote: Any eyeball network that wants to support multicast should peer with the content players(s) that support it. Simple! Just another reason to make the transit only networks even more irrelevant. The big issue is that the customers don't want to watch simulcast content. The odds of having two customers in a reasonably sized multicast domain watching the same netflix movie at exactly the same time frame in the movie is slim. Customers want to watch on time frames of their own choosing. I don't see multicast helping at all in dealing with the situation. Multicast _is_ useful for filling the millions of DVRs out there with broadcast programs and for live events (eg. sports). A smart VOD system would have my DVR download the entire program from a local cache--and then play it locally as with anything else I watch. Those caches could be populated by multicast as well, at least for popular content. The long tail would still require some level of unicast distribution, but that is _by definition_ a tiny fraction of total demand. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
On 11-Feb-13 13:13, Jay Ashworth wrote: From: Stephen Sprunk step...@sprunk.org Sure, almost nobody asks for dark fiber today because they know it costs several orders of magnitude more than a T1 or whatever. However, if the price for dark fiber were the same (or lower), latent demand would materialize. Why would I pay through the nose for a T1 when I can light the fiber myself with 10GE for $20/mo? This was part of my argument, yes. h And it even occurred to me over the weekend that this will reduce the engineering charges to get me onto the already-built backbone loops: They don't need to build to my *CO*, just to a splice at the edge of my city, and *I* can backhaul the uplinks in myself. Good point. I missed that since I was applying the same general model to the (suburban) municipality where I live, which already has no shortage of fiber _to the CO_. In the rural case originally described, reducing the middle mile problem helps too. What you're missing is that in this model, _every_ connection is L1 from the fiber owner's perspective. Let service providers worry about L2 and above. In fairness to Scott, he didn't *miss* it, he simply has his feasible slider set to a different place than I/we do. I disagree; he is obsessing over how to reduce the amount of fiber, which is a tiny fraction of the total cost, and that leads him to invite all sorts of L2 problems into the picture that, for a purely L1 provider, simply would not apply. Why would the ISP have to build and maintain a lot of infrastructure? All they need is a fiber-capable Ethernet switch in a colo to turn up their first customer. That's a lot simpler than trying to turn up their first customer via an ILEC's DSLAM, for instance. Well, that means *they have to build out in my city*; I can't aggregate L1 and backhaul it to them. As the saying goes, you must be present to win. If there's _any_ fiber available to the CO, there shouldn't be much trouble getting an ISP to show up when they have ridiculously cheap access to your customer base. There's nothing wrong with the muni operating a L2 (or even L3) carrier of last resort, just to ensure that _some_ useful service is available to residents. However, it should (a) be priced high enough to attract competitors and (b) be a distinct entity, treated by the fiber arm as no different from any other L1 customer. None of the shenanigans like the ILECs play, where the wholesale rate to competitors is higher than the retail rate for the ILEC's own service. That's true at L3, but at L2, my goal is to encourage *much smaller* ISPs (like the one I used to engineer in 1996, Centurion Technologies; we were profitable with about 400 dialup customers into a 40 and a 20 modem dialup bank backhauled by 512kb/s *and I would come to your house and make it work if I had to*. :-). By having the city run L2 over our L1, we can accomplish that; unlike L3, I don't believe it actually needs to be a separate company; I expect most ISP business to be at L2; L1 is mostly an accomodation to potential larger ISPs who want to do it all themselves. Or FiOS. :-) We have a philosophical disagreement here. I fully support public ownership of public ownership of natural monopolies, and the fiber plant itself (L1) certainly qualifies. However, running L2 (or L3) over that fiber is _not_ a natural monopoly, so I do _not_ support public ownership. At most, I could stomach a provider of last resort to guarantee resident access to useful services, in the IMHO unlikely event that only one (or zero) private players showed up, or a compelling need to provide some residents (eg. the elderly or indigent, schools, other public agencies, etc.) with below-cost services. (Note that inside wiring is a completely separate issue, and carriers _will_ have to train techs on how to do that since few are familiar with fiber, but that is an optional service they can charge extra for. The L1 provider's responsibility ends at the NIU on an outside wall, same as an ILEC's, so it's not their problem in the first place.) The L2 might end there, too, if I decide on outside ONTs, rather than an optical jackblock inside. I think the ILECs got this part right: provide a passive NIU on the outside wall, which forms a natural demarc that the fiber owner can test to. If an L2 operator has active equipment, put it inside--and it would be part of the customer-purchased (or -leased) equipment when they turn up service. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
On 11-Feb-13 16:37, Scott Helms wrote: I disagree; he is obsessing over how to reduce the amount of fiber, which is a tiny fraction of the total cost, and that leads him to invite all sorts of L2 problems into the picture that, for a purely L1 provider, simply would not apply. Not at all, I've obsessing about all of the costs. IMO if you can't pay for the initial build quickly and run it efficiently then your chances of long term success are very low. The fiber plant would presumably be paid for with 30-year bonds, same as any other municipal infrastructure (eg. water and sewer lines--the real pipes), for which interest rates are currently running around the rate of inflation. There is no need to pay them off quickly. Heck, some forward-thinking folks might even see the fiber as paying for itself through increased property values (and therefore tax revenues) and not demand that it pay back its bonds through access fees at all, just the (minimal) operating costs. L2 and above, though, is another story due to the (relatively) short depreciation cycle and higher operational costs--yet another reason they should be separated. L1, at scale, sharing is simply impractical for all of its philosophical benefits for more municipal network operators. That's not to say there aren't exceptions, but I can point to lots of successful muni operators who are the layer 3 provider. I can point to several that offer open access at layer 2 successfully but I don't know of any doing L1 sharing that would call it a success. Do you know of some that do? There have been several examples cited in this thread, but I don't know how many (if any) meet both your criteria, i.e. muni _and_ open at L1. We have a philosophical disagreement here. I fully support public ownership of public ownership of natural monopolies, and the fiber plant itself (L1) certainly qualifies. However, running L2 (or L3) over that fiber is _not_ a natural monopoly, so I do _not_ support public ownership. At most, I could stomach a provider of last resort to guarantee resident access to useful services, in the IMHO unlikely event that only one (or zero) private players showed up, or a compelling need to provide some residents (eg. the elderly or indigent, schools, other public agencies, etc.) with below-cost services. Too many places have either no or very poor services being provided from the market for me to take this stance. ... hence my reluctant acceptance of having a publicly-owned provider of last resort for L2 and L3 services. I would hate to see all that fiber go unused just because no private players showed up to the party. OTOH, it is still fundamentally different from L1. (Note that I also endorse this same model in urban and suburban markets, where there is no shortage of folks wanting to offer service--but few players with access to enough capital to put the necessary fiber in place, none of whom are interested in open access.) I think the ILECs got this part right: provide a passive NIU on the outside wall, which forms a natural demarc that the fiber owner can test to. If an L2 operator has active equipment, put it inside--and it would be part of the customer-purchased (or -leased) equipment when they turn up service. What ILEC is offering L1 fiber access at all? Think copper. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
On 11-Feb-13 15:24, Jay Ashworth wrote: From: Stephen Sprunk step...@sprunk.org By having the city run L2 over our L1, we can accomplish that; unlike L3, I don't believe it actually needs to be a separate company; I expect most ISP business to be at L2; L1 is mostly an accomodation to potential larger ISPs who want to do it all themselves. We have a philosophical disagreement here. I fully support public ownership of public ownership of natural monopolies, and the fiber plant itself (L1) certainly qualifies. However, running L2 (or L3) over that fiber is _not_ a natural monopoly, so I do _not_ support public ownership. At most, I could stomach a provider of last resort to guarantee resident access to useful services, in the IMHO unlikely event that only one (or zero) private players showed up, or a compelling need to provide some residents (eg. the elderly or indigent, schools, other public agencies, etc.) with below-cost services. I dunno; I tend to buy the arguments that there is a difference; as long as the L2 access is itself sold to comers at cost, including the internal accounting between the fiber and L2 sides of the house. I don't see much of a difference in that respect between L2 and L3 services. OTOH, I see a clear difference between L1 and L2/L3, as above. I don't even plan to offer quantity discounts. :-) Good. That's one of the ways that big carriers claim to be playing by the same rules as everyone else yet get away with substantially lower costs than smaller competitors. See also: the ARIN fee schedule. The L2 might end there, too, if I decide on outside ONTs, rather than an optical jackblock inside. I think the ILECs got this part right: provide a passive NIU on the outside wall, which forms a natural demarc that the fiber owner can test to. If an L2 operator has active equipment, put it inside--and it would be part of the customer-purchased (or -leased) equipment when they turn up service. Yes, but that means the ISP has to drill holes in walls *and push fiber jumpers through them*; I'm not at all happy with that idea. You mean their contract installers, who do the same thing today with POTS, DSL, cable and satellite lines. It'll probably be the same people, even. OTOH, an external NIU means the fiber company can install with zero cooperation from any given property owner since no entry is required. Customers are going to need internal wiring done anyway to get it from the demarc to wherever they want their fiber modem installed, so you can penetrate the exterior wall at the same time--when they're in a more cooperative mood because they're going to get an immediate tangible benefit. An exterior demarc has clear troubleshooting/maintenance benefits to the fiber owner. Let the L2/L3 provider deal with inside wiring problems. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
On 11-Feb-13 18:23, Warren Bailey wrote: On 2/11/13 4:16 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Scott Helms wrote: IMO if you can't pay for the initial build quickly and run it efficiently then your chances of long term success are very low. That is not a business model for infrastructure such as gas, electricity, CATV, water and fiber network, all of which need long term planning and investments. Nearly all of the industries you mentioned below receive some type of local or federal/government funding. If I was going to build some kind of access network, I would be banging on the .gov door asking for grants and low interest loans to help roll out broadband to remote areas. I followed the link in a recent email here to the details on the Maine Fiber Co, and their web site indicates they got started with $7M in private funding--and a $25M grant from the feds for improving service to rural areas. That radically changes the economics, just as I'm sure it did for other utilities. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
On 11-Feb-13 22:33, Jay Ashworth wrote: What I care about is not that it's optical -- it's that *it's a patchcord*. If the ONT is per ISP, and the patchpoint is an *external* jackbox, then that thru-wall cable has to be a patchcord, not drop cable -- and the ISP field tech will have to work it. *This* *will* cause the installation reliability problems that Scott is scared of. OTOH, that will be the L2+ providers' problem, and the _level_ of problems will be inversely proportional to how well they train/pay their field staff/contractors. IOW, the incentives are properly aligned with the desired behavior. If the L1 provider's responsibility ends at the jack on the outside NIU, as an ILEC's does today with copper, then you have clean separation and easy access for both initial installation and for later troubleshooting--clear benefits that help mitigate nearly all the problems Scott refers to, at least from the L1 provider's perspective. No, either the ONT goes on the outside wall and we poke cat 6, or the drop cable goes inside to a jack box for an interior ONT. IMHO, both of those options are unacceptable, for different reasons. That, in turn doesn't mean I can't coil the tail in a box, and poke it through on order. Once the tail is poked through, though, you no longer have an exterior test point that is easily accessed. If the L2 and L1 providers are arguing over whose fault a problem is, they not only have to both show up at the same time, they also have to arrange for the property owner (or their agent) to be present as well to let them inside to continue their testing and bickering. That won't end well for either party. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
On 04-Feb-13 15:17, Jean-Francois Mezei wrote: On 13-02-04 16:04, Scott Helms wrote: Subscribers don't care if the hand off is at layer 1 or layer 2 so this is moot as well. This is where one has to be carefull. The wholesale scenario in Canada leaves indepdendant ISPs having to explain to their customers that they can't fix certain problems and that they must call the telco/cableco to get it fixed. (in the case of a certain cable company, they can't even call them, it has to be done by email with response of at least 48 hours). This is not a show-stopper. In my state (TX), electric utilities have been strictly segregated into generation, distribution and retail. When I have a problem with my service, I call my retailer, who puts in a ticket with the distributor (i.e. grid operator). However, since the distributor has an equal relationship with _all_ retailers, rather than also having a retail arm itself (as in the telco model), there is no service problem. If anything, service is _better_ than when distribution and retailing were done by the same (monopoly) utility company because there are now formal SLAs and penalties. Another aspect: customers espect to be able to switch seamlessly from one ISP to the next. But ISP-2 can't take over from ISP-1 until ISP-1 has relinquised control over the line to the end user. In a layer 1 scenario, it means ISP-1 has to physically go and deinstall their CPE and disconnect strand from their OLT, and then ISP-2 can do the reverse and reconnect evrything to provide services. Wrong. As soon as retailer 2 puts in the connect order, everything gets switched over within one business day. The distributor stops billing retailer 1 because they're no longer in the picture. Now, if different CPE is required (not an issue for electricity), then the customer would notice that the CPE from retailer 1 suddenly stops working. They would then unplug it and follow the directions that came in the box with the CPE from retailer 2. No truck roll needed, unless they paid extra for that. (In a slightly different space with similar costs, prices and volumes, one carrier said rolling a truck for installation would blow their profit margin for the entire year.) S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
On 02-Feb-13 14:07, Scott Helms wrote: A layer 1 architecture isn't going to be an economical option for the foreseeable future so opining on its value is a waste of time...its simple not feasible now or even 5 years from now because of costs. The optimal open access network (with current or near future technology) is well known. Its called Ethernet and the methods to do triple play and open access are well documented not to mention already in wide spread use. Trying to enforce a layer 1 approach would be more expensive than the attempts to make this work with Packet Over SONET or even ATM. It would be more expensive in the short term, yes. But forcing the use of SONET, or ATM, or Ethernet, or any other random technology to save money in the short term will end up costing you more in the long term. You will end up locked into a merry-go-round of upgrades every time someone invents a better technology--or locked into an obsolete technology because (as is often the case with govt in the US) there is no funding to upgrade. You're focused on equipment, which has a 3-5 yr depreciation cycle, rather than the facilities, which have a 30-50 yr depreciation cycle. It's a totally different mindset. What is about a normal Ethernet deployment that you see as a negative? Active equipment in the ONS, limited topology, forced uniformity rather than innovation, etc. What problem are you tying to solve? The goal at hand is an OSP that will last 50+ years without any significant change. Considering the rapid evolution of technology over the last 10-20 years, the only safe bet is home run fiber. Let service providers decide what technology is best to light up said fiber in any given year. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Muni fiber: L1 or L2?
On 03-Feb-13 14:33, Scott Helms wrote: On Sun, Feb 3, 2013 at 2:53 PM, Owen DeLong o...@delong.com wrote: Is it more expensive to home-run every home than to put splitters in the neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be overcome? I remain unconvinced. This completely depends on the area and the goals of the network. In most cases for muni networks back hauling everything is more expensive. Slightly more expensive in the short term, yes. In the long term, no, especially if you consider the opportunity costs of _not_ being able to deploy new technologies in the future--something only home run dark fiber can guarantee. Handing out connections at layer 1 is both more expensive and less efficient. Its also extremely wasteful (which is why its more expensive) since your lowest unit you can sell is a fiber strand whether the end customer wants a 3 mbps connection or a gig its the same to the city. So what? How any particular fiber happens to be lit is irrelevant to the muni--and it doesn't change their cost structure one iota. Dark fiber is dark fiber. I'm not saying you shouldn't sell dark fiber, I'm saying that in 99% of the cities you can't build a business model around doing just that unless your city doesn't want to break even on the build and maintenance. As a private operator, no, you probably can't build a business model around that. A muni has different economics, though. At the cost levels being thrown around here, it doesn't seem like there would be _any_ difficulty in breaking even, which is all a muni needs to do. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: The Department of Work and Pensions, UK has an entire /8
On 20-Sep-12 20:51, George Herbert wrote: On Thu, Sep 20, 2012 at 5:13 PM, Stephen Sprunk step...@sprunk.org wrote: Actually, they're not any different, aside from scale. Some private internets have hundreds to thousands of participants, and they often use obscure protocols on obscure systems that were killed off by their vendors (if the vendors even exist anymore) a decade or more ago, and no source code or upgrade path is available. The enterprise networking world is just as ugly as, if not uglier than, the consumer one. I haven't worked much on the commercial private internets, but I did work for someone who connected on the back end into numerous telco cellphone IP data networks. For all of those who argue that these applications should use 1918 space, I give you those networks, where at one point I counted literally 8 different 10.200.x/16 nets I could talk to at different partners (scarily enough, 2 of those were the same company...). And hundreds and hundreds of other space conflicts. That's all? I consulted for one customer that had several (six? eight?) instances of 10/8 within their own enterprise, simply because they needed that many addresses. That doesn't include the dozens of legacy /16s they used in their data centers--plus the hundreds of legacy /24s they used in double-sided NAT configurations between them and various business partners, COINs, etc. Yet all that was exposed to the consumer internet was a couple of /24s for their web servers, email servers and VPN concentrators. Yes, you can NAT all of that, but if you get network issues where you need to know the phone end address and do end to end debugging on stuff, there are no curse words strong enough in the English language. That's the truth. To get from a credit card terminal to the bank involved _at least_ three layers of NAT on our side, and I don't know how many layers of NAT there were in total on the bank's side, but it was at least two. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: The Department of Work and Pensions, UK has an entire /8
On 20-Sep-12 14:14, Tony Hain wrote: Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling. To some degree yes. In this particular case, why don't you personally go out and tell all those people globally (that have what they consider to be perfectly working machines) that they need to pay for an upgrade to a yet to be shipped version of software ... In many cases, particularly embedded devices, the vendor may have gone out of business or ceased offering software updates for that product, in which case customers would have to pay to /replace/ the products, not just upgrade them--for no benefit to themselves. Good luck with that. That's why the 240/3 idea was abandoned years ago, and nothing has changed since then. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: The Department of Work and Pensions, UK has an entire /8
On 18-Sep-12 23:11, Mike Hale wrote: this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans. I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? In theory, that sounds great. However, the legal basis for actually taking them back is questionable since they pre-date the RIR system, registration agreements, utilization requirements, etc. And, in practice, those who _aren't_ using their assignments have, for the most part, given them back voluntarily, so it's a moot point. Also, as in the case at hand, most of the blocks that generate complaints turn out to be, upon closer examination, actively in use but just not advertised--at least on the particular internet that the complainer is using. Hint: there is more than one internet. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: The Department of Work and Pensions, UK has an entire /8
On 19-Sep-12 03:46, Alex Harrowell wrote: On the other hand, the scarcity is of *globally unique routable* addresses. You can make a case that private use of (non-RFC1918) IPv4 resources is wasteful in itself at the moment. To be provocative, what on earth is their excuse for not using IPv6 internally? By definition, an internal network that isn't announced to the public Internet doesn't have to worry about happy eyeballs, broken carrier NAT, and the like because it doesn't have to be connected to them if it doesn't want to be. A lot of the transition issues are much less problematic if you're not on the public Internet. Actually, they're not any different, aside from scale. Some private internets have hundreds to thousands of participants, and they often use obscure protocols on obscure systems that were killed off by their vendors (if the vendors even exist anymore) a decade or more ago, and no source code or upgrade path is available. The enterprise networking world is just as ugly as, if not uglier than, the consumer one. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On 18-Jul-12 13:07, Saku Ytti wrote: On (2012-07-18 11:39 -0500), Stephen Sprunk wrote: Those were not considered requirements for the algorithm in RFC 4193 since there is no scenario /where RFC 4193 addresses are a valid solution in the first place/ for which testability or provability of the algorithm's results are important or even useful. If collision occurs, if dispute occurs, provability that one party did not use BCP method can be useful to solve dispute and decide who renumbers. In my experience, pointing at RFCs is rarely how disputes are resolved in the real world. Other potential problem with RFC, if you have software to generate two, if software runs parallel, it may generate same prefixes. It is incredibly unlikely, and that is all RFC 4193 claims to offer: /statistically /unique addresses. If you want /provably/ unique addresses, use GUAs--or lobby for ULA-C, which to date has been soundly rejected for lack of usefulness. IEEE decided 2008 or 2009 to start allocation OUIs randomly, since some cheapskates were assigning themselves 'free' OUIs from end of the space, confident it'll never collide. So duplicate OUIs can happen. Also some NIC vendors ship with non-unique MAC. You'd still need two systems with duplicate MACs to run the algorithm at exactly the same timestamp, which IIRC has a resolution of 2^-32 seconds. What makes RFC method good? RFC 4193 doesn't mandate any particular algorithm; it just provides an example that was designed to be easily implemented and used. You can use another RNG if you wish. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On 18-Jul-12 22:57, Karl Auer wrote: I don't understand the professed need for provable randomness. I think his concern is that if an SP generates a ULA prefix for a customer, and that prefix happens to collide with someone else's ULA prefix, the SP may wish to prove that it was a true collision rather than a result of the SP's laziness or incompetence. However, that concern does /not/ apply to those interested in ULAs in general. For the very limited community it does apply to, use a provable RNG instead of the one in RFC 4193. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On 19-Jul-12 07:47, Mark Andrews wrote: In message caaawwbxh1ws_9ax4fwgrqmsbjmkgj0nwhri9en53htl36vh...@mail.gmail.com, Jimmy Hess writes: When numbers are selected by choosing a random value; certain ratios of bits set to 1 are more likely to occur than other ratios of bits set to 1. A random generator that is operating correctly, is much more likely to emit a number with 50% of the bits set to 1, than it is to emit a number with 0% of the bits set to 1, given a sufficient number of bits. If the ratio is inconsistent by a sufficient margin, and your sample of the bits is large enough in number, you can show with high confidence that the number is not random; a 1 in 10 billion chance of the number being randomly generated, would be pretty convincing, for example. Actually you can't. fdaa:: has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random. The ratio of the number of bits doesn't tell you anything about whether the number was random or not. He oversimplified the real entropy test, which covers those cases. For a sufficiently long stream of random bits, there should be twice as many runs of length 1 as runs of length 2, twice as many runs of length 2 as runs of length 3, etc. And for each length, they should be evenly divided between runs of 0s and runs of 1s. Of course, 40 bits is nowhere near sufficiently long, but you can score the entropy and set a lower bound for acceptability. The two examples above would get very low entropy scores, far below any sensible lower bound. That is extremely improbable. If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two. improbable != impossible All RFC 4193 ever claimed to offer was improbability. If that's not good enough, get a GUA from your RIR. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On 18-Jul-12 02:04, Saku Ytti wrote: On (2012-07-18 00:34 +0200), Jeroen Massar wrote: Here's a calculator that will generate a random one for you: does not follow RFC4193 in any way at all. A such do not use it. I'm not sure if RFC4193 is best way to generate random part, It's not claimed to be the best way, just one of many possible good ways. If you can demonstrate that your way is at least as good, go for it. it should bepossible to incorporate RFC2777 verifiability to it. There is no need for that, since your failure to use a good source of randomness hurts nobody except yourself. If you're too lazy to come up with a good method yourself, as most people are, there are several online RFC 4193-compliant prefix generators that will save you the effort. At least one even includes the ability to record your results and be assured (within the margin of best-effort service) that you will not collide with anyone else who does so. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On 18-Jul-12 08:25, Saku Ytti wrote: On (2012-07-18 09:10 -0400), valdis.kletni...@vt.edu wrote: You want to roll in at some entropy by adding in the current date or something, so two Joes' Burritos and Internet in 2 different states don't generate the same value. There's a reason that 4193 recommends a 64bit timestamp and an EUI64. I assume business ids are federal not state, as IRS is federal? Anyhow I'm not saying 'this is how it should be done', I'm saying maybe there is way to do this in a way which is verifiably random. US EINs/SSNs, and various state-level ID numbers, are not random; given our problems with identity theft, they're not guaranteed to be unique, either. I assume the same is true for identification numbers in most other countries. 64b timestamp and EUI64 make it non-verifiable. If you publish the numbers you used, then others can verify that those values are reasonable. I doubt anyone would sift through billions of reasonable timestamps combined with the thousands of EUI64s at their site just to find a result that was memorable. And, if they did, who cares? It's not like it hurts me for them to do so--unless I'm dumb enough to do the same thing, happened to get the same result /and/ happened to merge with them--all of which are still unlikely events. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On 18-Jul-12 08:48, Saku Ytti wrote: On (2012-07-18 08:37 -0500), Stephen Sprunk wrote: There is no need for [RFC2777 verifiability], since your failure to use a good source of randomness hurts nobody except yourself. I think you're making fact out of opinion. Maybe SP is generating ULAs for their customers. Why would they do that? SPs should only be assigning (and routing) GUAs. ULAs are for /local/ use within the customer site, so customers can and should generate their own locally. An SP should never see those addresses and can safely ignore their existence, aside from a generic filter on the entire ULA range. Maybe this is not practical enough concern, but I'm wondering, what is the downside? What is the benefit of recommending method which is not testable/provable. Those were not considered requirements for the algorithm in RFC 4193 since there is no scenario /where RFC 4193 addresses are a valid solution in the first place/ for which testability or provability of the algorithm's results are important or even useful. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Dear Linkedin,
On 11-Jun-12 14:05, Owen DeLong wrote: On Jun 11, 2012, at 11:35 AM, John Levine jo...@iecc.com wrote: OK, someone shows you a Quebec driver's license. You ask for a passport, she says, I don't have one, and points at the blue word Plus after the words Permis de Conduire at the top of the license. Now what? To the best of my knowledge, ICE stopped accepting DL for admission from Canada several years ago. Only non-enhanced (plus in Quebec) drivers licenses. See: http://www.dhs.gov/files/crossingborders/travelers.shtm S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: OT: Credit card policies (was Re: Dear Linkedin,)
On 10-Jun-12 13:33, Jay Ashworth wrote: From: Michael Thomas m...@mtcc.com On 06/10/2012 11:22 AM, John T. Yocum wrote: A merchant can offer a cash discount. I believe that the law just recently changed on that account. I believe that what Barry says was the old reality. Perhaps, but Cash/Credit for gas dates back to before I moved to Florida in 1981. Merchants have always been allowed to offer a cash discount. The ban is (was?) on surcharges for card purchases. In practical terms, this means that if you post only one price, it must be the card price, not the (possibly lower) cash price. Even Further Off-Topic, isn't debit supposed to be cash? Why do I pay the Credit price for it? The credit price is subject to the merchant's discount rate, regardless of the nature of the particular card used. The cash price is the part of the credit price left after the discount rate is applied. Say gas is $4/gal and the merchant's discount rate is 4%. That means the merchant only gets paid $3.84/gal for card purchases. If the merchant charges cash customers $3.84/gal, which is legal, they get paid the same amount of money. However, it is illegal for the merchant to post /only /a price of $3.84/gal and then charge card users $4/gal to cover the card discount; that's an illegal surcharge. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: OT: Credit card policies (was Re: Dear Linkedin,)
On 10-Jun-12 14:01, Robert Bonomi wrote: From: Jay Ashworth j...@baylink.com Even Further Off-Topic, isn't debit supposed to be cash? Why do I pay the Credit price for it? It is, and *ISN'T*, 'cash'. Unlike cash (and like a credit card), it is simply an instruction to a third party to pay the retailer a specified amount. And as such, is subject to the terms of the contract between -those- parties as to how payment is made an what charges are imposed. Unlike a credit card, the money _is_ immediately dedecuted from your bank account. All of the above is completely irrelevant to the merchant. Like a credit card, it is the third-party clearinghouse that gets the mone from you, and passes it on to the retailer. AFTER extracting their charges for the service they provide. FWIW, this is known as the discount rate. You pay the 'credit' price, because the card issuer, and the clearinghouse operations _charge_ the merchant the same amount for those transactions as for 'credit' ones. Thus the merchant does not receive any of the benefits of a 'cash' transaction, so there is no 'discount' to pass on to the buyer. The merchant's discount rate varies between card types. That's why many merchants don't accept AmEx, DC, CB and Nexus: their discount rates are higher than Visa and MC. For a low-margin business, the difference in rates can make the difference between profit and loss on a given sale. At one point, VISA, charged -more- for debit transactions than credit ones. Despite the fact that there was -zero- risk to them on the debit transaction. Wrong. Even debit cards present a risk of chargeback due to fraud. However, the fraud rates are lower due to the us of PINs, so the discount rate is also lower. VISA got sued over the matter, since (at that time) it was impossible to tell whether the card number presented was debit or credit. It's still impossible to tell, which is why most card terminals ask whether the card is credit or debit. If you press the credit button, even if the card is a debit card, it is processed as a credit card--with the credit card discount rate. That's why Visa's advertising and contests promote customers using signature (i.e. credit) transactions: Visa gets more money that way (at the cost of their merchants). As a result of the lawsuit, the cost differential between credit and debit transactions was eliminated. ... except it's still there, though perhaps in the other direction. The discount rate for debit transactions is lower, but a PIN must be used to get that rate. The exact rates vary between card networks, card processors and even merchants, but a few years ago the numbers I heard were 4% for credit (i.e. signature) transactions and 1% for debit (i.e. PIN) transactions. That is why those nifty PIN terminals appeared everywhere virtually overnight: saving 3% on every debit transaction easily paid for all those new terminals. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: CVV numbers
On 09-Jun-12 09:14, Joel Maslak wrote: On Jun 9, 2012, at 1:06 AM, Hal Murray hmur...@megapathdsl.net wrote: Should I really take them seriously? Your call. That said, the purpose of CVV is to stop *one* type of fraud - it's to stop a skimmer from being able to do mail-order/internet-order with your card number. The CVV is not on the magnetic strip, so a skimmer installed at the ATM or gas pump won't be able to capture it. This is CVV2; it is printed (but not embossed) on the card but not on the magstripe. This is requested by online merchants to prove that the card is in the customer's possession, since it won't show up on carbons, receipts, etc. and in theory will never be stored by any merchant (unlike the account number, expiration date, etc.). . There's a similar value on the magnetic strip that keeps the internet site you gave your card number and CVV to from being able to print cards and use them at the gas pump. This is CVV1; it is on the magstripe but not printed on the card; this is how brick-and-mortar merchants can prove that your card was in the merchant's possession (card present), i.e. swiped rather than entered by hand. Certainly they don't stop all fraud. They stop one type of fraud. The two codes are targeted at very different types of fraud. What they have in common is that submitting either a CVV1 or CVV2 number enables merchants to get a better discount rate on their transactions. Given the low margins in many industries, this can make the difference between making a profit and losing money on a sale, which is why many merchants refuse transactions without CVV1 or CVV2. Merchants in industries with higher margins often don't care; they'll submit CVV1 or CVV2 when convenient, but they won't let not having them block the sale. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: POTS Ending (Re: Operation Ghost Click)
On 04-May-12 04:11, Anurag Bhatia wrote: Curious to know if naked DSL (DSL without dialtone POTS link) is common in North America? The availability of naked DSL varies from state to state within the US, depending on how successful the telcos have been at bribing^Wlobbying the various state regulators and politicians. Even where not required, some telcos have ended up offering it anyway due to competition from other service providers, eg. cable, fixed wireless or mobile wireless. PSTN IP connectivity is banned [in India] which brings up back to GSM/CDMA and POTS option. The naked DSL debate isn't about VoIP; it's really about the mass adoption of mobile phones. Some telcos see DSL as an opportunity to force customers to keep paying for landlines they never use anymore. This is a big deal because they have a lot of expensive equipment they're still paying for--much of it bought to handle the massive influx of dial-up modem users in the 1990s--that is generating less and less revenue every year. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Squeezing IPs out of ARIN
On 24-Apr-12 12:32, ad...@thecpaneladmin.com wrote: Anyone have any tips for getting IPs from ARIN? For an end-user allocation they are requesting that we provide customer names for existing allocations, which is information that will take a while to obtain. There are no end-user allocations. Allocations go to ISPs; assignments go to end-users. Which are you? From the sound of it, you're an ISP requesting an allocation, and ARIN is requesting documentation of the assignments you've made to end users from your previous allocation(s) to verify you really need more--as required by community policy. If you're doing an even marginally competent job of managing your previous allocation(s), this data should be readily available in /some/ form, and providing it to ARIN should require little more effort than pinging your lawyers to verify the appropriate NDA is in place. If you're /not/ doing a marginally competent job of managing your previous allocation(s), you're not going to get more until you learn to do a better job of it. In my experience, going through that learning experience will uncover a lot of unused space that will likely make your current request moot (for now). And that's a big part of the point. They are insisting that this is standard process and something that everyone does when requesting IPs. Has anyone actually had to do this? Everyone /should/ be required to provide documentation of justification for all requests to any RIR. If you're aware of anyone who /hasn't/, let us know so we can beat up the RIR in question. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: WW: Colo Vending Machine
On 22-Feb-12 10:34, Gary Buhrmaster wrote: On Wed, Feb 22, 2012 at 08:09, Joel jaeggli joe...@bogus.com wrote: If we just stop printing things the problem goes away. I think Xerox promised me a paperless office (starting in the 1980s?). I am still waiting. That's an odd thing to expect from a company that made its name in photocopiers, printers and fax machines, i.e. machines that enabled using /more/ paper in the office rather than less. However, my office /is /almost entirely paperless today; everything is done via email/web except where paper is required by the legal system. Nearly all of what I do print is signed, scanned to PDF and shredded within minutes. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: De-bogon not possible via arin policy.
On 15-Dec-11 15:54, Joel jaeggli wrote: On 12/15/11 13:43 , Leo Bicknell wrote: In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote: ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. The problem is that in use means different things to differnet folks. ifconfig em0 inet 10.0.0.1 255.0.0.0 I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment. We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. For those that haven't bothered to look it up, folks appear to be referring to T-Mobile--a Cameron Byrne works there, and they fit the profile given. I think it's safe to assume that adequate docuementation could be provided. One might assume it /could/ be provided, but so far we have no evidence that it /has/ been provided or, if so, on what grounds ARIN rejected it as being adequate. Heck, so far we have no evidence that any request has even been filed or that the OP is who we think he is. All we have so far is the word of one person, using a Gmail address and the name of a T-Mobile employee, that such addresses were applied for and that ARIN denied the request. I'll also point out that, even if some of the above claims turn out to be true, T-Mobile almost certainly would have required ARIN to sign an NDA (as is customary for any almost any business dealings these days), so ARIN cannot defend itself against the ones that are not, leaving us only with the OP's obviously biased version of events and the ensuing speculation--and the OP probably knew that when he/she posted. Furthermore, it is a fact that not all of T-Mobile's ~34M customers are using IPv4-addressable devices, and they're certainly not all online at the same time, so a simple customer count does /not/ qualify as justification for getting that many addresses. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: De-bogon not possible via arin policy.
On 15-Dec-11 16:31, Ricky Beam wrote: On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@virtualized.org wrote: ... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. That depends on how you see their demontrated need. The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any immediate need on my (channeling ARIN) part. However, if they actually have the number of hosts claimed, that justifies the space they're asking for. What addresses they're using today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 space; they are allowed to get public space if they want it. This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.) Agreed, but what's done is done. What /should/ have been done is now irrelevant. And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.) Presumably, they need to renumber out of 5/8 so that their customers can reach sites legitimately assigned addresses in 5/8. However, those customers seem to have gotten along okay for years without public addresses, so why not renumber them into a second instance of 10/8? When I was in the consulting world, I had one customer with eight instances of 10/8, so I know it's doable. If they want to give every customer a public address, IPv6 provides more than they could ever possibly use--and ~34M new IPv6 eyeballs would give the content industry a nice kick in the pants... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Verizon Business - LTE?
On 16-Aug-11 10:49, chris wrote: If my edge from 5+ years ago could 3gb/day and 90gb a month how is 4G at 5gb an improvement of the service? Who said the goal was an improvement in /service/? Based on their actions, it is quite clear that carriers are only interested technology or contract terms that improve their /profits/, i.e. take more money out of customers' wallets. And that's exactly what their shareholders want them to do; it would be rather naïve to expect anything else. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On 01 Nov 2010 10:08, Jason Iannone wrote: Define long prefix length. Owen has been fairly forceful in his advocacy of /48s at every site. Is this too long a prefix? Should peers only except /32s and shorter? One assumes unpaid peers will accept prefixes up to the maximum length the RIR issues for that block, which is currently either /32 (PA) or /48 (PI). Presumably, long means any prefix longer than that; paid peers may accept those as well, but one assumes unpaid peers will not. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Only 5x IPv4 /8 remaining at IANA
On 21 Oct 2010 10:07, Ben Butler wrote: Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only. That's what NAT-PT is for. Oh wait, the IETF deprecated it... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: RIP Justification
On 29 Sep 2010 15:20, Jesse Loggins wrote: A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet never to be seen or heard from again. Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. (I assume RIP above refers to RIPv2.) When the automobile was developed, plenty of folks thought horses were obsolete and would fall completely out of use. However, the reality is that there are still some things horses are better at, e.g. terrain that automobiles (even 4WD) simply can't navigate, places where automobiles are banned for safety, aesthetic and/or environmental reasons, etc. Newer isn't always better. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Addressing plan exercise for our IPv6 course
On 29 Jul 2010 12:19, Owen DeLong wrote: On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote: On 29 July 2010 15:49, Owen DeLong o...@delong.com wrote: If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts. ... and paying sixteen times as much in assignment and maintenance fees. See the problem there? It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you. Yes. However, I don't think the RIRs are as willing to give out address space for _potential_ customers, e.g. if a telco or cableco wanted to assign a single block to each CO/head end to account for future growth. OTOH, you can get address space based on a /48 per actual customer, then actually assign a /64 per potential customer and have enough for massive growth. Why waste valuable people's time to conserve nearly valueless renewable resources? By creating artificial scarcity, one can increase profits per unit of nearly-valueless, renewable resources. See also: De Beers and the demonizing of artificial diamonds. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On 24 Apr 2010 21:01, Mark Smith wrote: On Thu, 22 Apr 2010 01:48:18 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: So what happens when you change providers? How are you going to keep using globals that now aren't yours? use pi space, request it from your local friendly RIR. I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR? The vast majority of residential customers have no idea what globals or PI are. They use PA and they're fine with that--despite being forcibly renumbered every few hours/days. (Many ISPs deliberately tune their DHCP servers to give residential customers a different address each time for market segmentation reasons.) Here's the scenario: I'm a typical, fairly near future residential customer. I have a NAS that I have movies stored on. My ISP delegates an IPv6 prefix to me with a preferred lifetime of 60 minutes, and a valid lifetime of 90 minutes. ... I start watching a 2 hour movie, delivered from my NAS to my TV over IPv6, using the GUA addresses (because you're saying I don't ULAs). 5 minutes into the movie, my Internet drops out. And five minutes and a few seconds into the movie, the movie drops out because the DRM mechanism can't phone home anymore to validate you still have a license to watch it. I have an IP-based DVR, and that's exactly what happens. However, let us look forward to a world where the TV/movie studios have woken up to the fact that DRM does more harm than good, as the record industry recently has: 1 hour, 35 minutes into movie, the movies drops out, because the IPv6 addresses used to deliver it can't be used anymore. The vast majority of residential customers have a single subnet, so they can get by just fine using IPv6 link-local addresses. The vanishingly small percentage that have multiple subnets are presumably savvy enough to set up ULA-R addresses. There is no need for ULA-C in this scenario. The only semi-rational justification for ULA-C is that organizations privately internetworking with other organizations are scared of ULA-R collisions. However, PI solves that problem just as readily. If one cannot afford or qualify for PI, or one wants a non-PI prefix due to delusions of better security, one can use a private deconfliction registry, e.g. http://www.sixxs.net/tools/grh/ula/. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Connectivity to an IPv6-only site
On 24 Apr 2010 16:15, Jack Bates wrote: valdis.kletni...@vt.edu wrote: No, the problems are probably further back in time. We first started turning up IPv6 back in 1997 or so. There's a *very* good chance that we turned it off a decade ago (or whenever people *first* started listing quad-A's in NS entries) due to breakage and never actually revisited it since then. This would have been in the era of early 6bone and your IPv6 connection is probably tromboned through Tokyo. I periodically see issues with idiotic load balancers that don't respond to anything except A records for specific domains. This causes problems when requesting records and delays waiting for timeouts before going to A. newegg fixed theirs though, yipeee! :) Don't forget the hotspot vendor that returns an address of 0.0.0.1 for every A query if you have previously done an query for the same name (and timed out). That's a fun one. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: ARIN IP6 policy for those with legacy IP4 Space
On 09 Apr 2010 12:34, David Conrad wrote: On Apr 9, 2010, at 7:07 AM, Owen DeLong wrote: No, ARIN is not a regulator. Regulators have guns or access to people with guns to enforce the regulations that they enact. ARIN has no such power. I'm a little confused on the distinction you're making. Today, ARIN can remove whois data/reverse delegations as a way of enforcing 'regulations'. In the future, assuming RPKI is deployed, ARIN could, in theory, revoke the certification of a resource. While not a gun, these are means of coercion. Are you being literal when you say gun or figurative? As Mao famously said, power grows from the barrel of a gun. Regulators have (either directly or indirectly) lots of guns at their disposal to enforce their will on those they regulate, i.e. their regulations have the force of law. In contrast, ARIN's policies do not have the force of law. If operators choose not to look in ARIN's WHOIS database to verify addresses are registered to some org, or they choose to use another RDNS provider, or they choose to use a RPKI certificate scheme not rooted at ARIN/ICANN, that is their choice and ARIN couldn't do a damn thing to stop them. ARIN has no guns. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: ARIN IP6 policy for those with legacy IP4 Space
On 09 Apr 2010 12:43, William Herrin wrote: On Fri, Apr 9, 2010 at 1:07 PM, Owen DeLong o...@delong.com wrote: On Apr 9, 2010, at 7:30 AM, todd glassey wrote: BULL SH*T, ARIN makes determinations as to how many IP addresses it will issue and in that sense it is exactly a regulator. No, ARIN is not a regulator. Regulators have guns or access to people with guns to enforce the regulations that they enact. ARIN has no such power. The FCC is a regulator. The California PUC is a regulator. ARIN is not a regulator. Last I heard, the FCC has access to people with law degrees not guns. Much like ARIN, really. If you violate FCC regulations, their first step is to take you to court for violating their regulations, but if you ignore the court's ruling against you, people with guns (the FBI, IIRC) _will_ come stop your violations, whether that means putting you in jail or putting you in the ground. That is what the force of law means. ARIN's authority ends at the contract you signed with them, and their only remedy (not providing any further services) is specified in that contract. If you did not sign a contract with them, they have no authority at all--and no obligation to provide any services to you. ARIN policy therefore does _not_ have the force of law. You are free to ignore them if you wish, unlike a regulator. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: ARIN IP6 policy for those with legacy IP4 Space
On 07 Apr 2010 16:17, Gary E. Miller wrote: On Wed, 7 Apr 2010, Owen DeLong wrote: If you are an end-user type organization, the fee is only $100/year for all your resources, IPv4 and IPv6 included. Is that really what you would call significant? As always, the devil is in the deetails. From: https://www.arin.net/fees/fee_schedule.html#waivers The proper URL for the below quote is https://www.arin.net/fees/fee_schedule.html#legacy_fee. The annual fee will be $100 USD until 2013, at which time ARIN's Board of Trustees may choose to raise the fee. Note that the LRSA specifies that the fee increase cannot be more than $25/yr. Then scroll down to the fees you can expect in 2013. Especially note how the small guys get hit much harder per IP. This is the section at https://www.arin.net/fees/fee_schedule.html#waivers. That section applies only to _allocations_, which are what ISPs get. The maintenance fee for _assignments_, which is what end users orgs get, has always been $100/yr. No waiver is necessary, and AFAIK the BoT has made never made any noises about increasing the assignment maintenance fee. And, really, even if the fee for your /48 (X-small category) assignment maintenance fee went up to $1250/yr to match the current allocation maintenance fee table, would that really be significant in the grand scheme of things? S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: ARIN IP6 policy for those with legacy IP4 Space
On 07 Apr 2010 18:40, N. Yaakov Ziskind wrote: I don't think the issue is *money* (at least the big issue; money is *always* an issue), but rather the all-of-sudden jump from being unregulated to regulated, whatever that means. ARIN is not a regulator. The jump is from not paying for services that you have no contract for to paying for services that you do have a contract for. I would think multiple times before making that jump. Hence my suggestion to set up a separate organization to request IPv6 space, and thus not 'endanger' whatever I had before. Signing an RSA to get new space does not _in any way_ endanger or otherwise affect legacy resources. Putting legacy resources under LRSA (or RSA, if you wished) is a completely separate action and is, for now at least, completely optional. You do not need to set up a separate organization; all that does is waste your time and ARIN's. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: ARIN IP6 policy for those with legacy IP4 Space
assume that ARIN has _no_ obligations to you, and they could (if the community so desired) delete your unpaid, uncontracted registration from their database and assign/allocate those numbers to some other party, and there's not a damn thing you could do about it other than waste lots of money on a lawsuit you'd undoubtedly lose. Signing an LRSA protects you against that possibility--forever--at minimal cost. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Juniper's artificial feature blocking (was legacy /8)
On 04 Apr 2010 16:07, James Hess wrote: Using a 'key' is slightly less of a network operator nightmare than having 100 featuresets, and thousands of mystery meat images for the same software version. At least you don't need to go buy a new software image, and do a full upgrade procedure to gain feature access. Applying a key seems less risky and less likely that downtime is needed, when you decide that you now need this feature. Indeed. Just as importantly, developing a single image with license-enabled features saves both vendors and customers a lot of time on QA, acceptance testing, etc. Since you're always running the same image, you only need to test it once, with all features enabled, to be sure that everything works; if there are different images for different feature sets, you have to run a full test suite on each image. That's a lot of extra work for no real benefit. Having to switch from one image to another to enable a particular feature also entails additional risk, downtime, etc. that simply loading a license key does not. Even CPU manufacturers are noted for artificially restricting features in software (such as VT or hyper-threading, even artificially disabling cores). Not all buyers of L3 switches need or want to payfor that, and there is more $$$ to be made from those that do. The manufacturer can either segment their market by not offering OSPFv3 on the device, release a new higher-end hardware model for V3 support at 10x the cost, or offer an add-on license, as an incremental upgrade to a larger number of users (including the installed base). Indeed. Vendors face a lot of price pressure, so being able to disable non-mandatory features to meet low-end customers' price demands is a major competitive advantage. However, they still need revenue to support the development that the handful of high-end customers demand for new or optional features, and charging for licenses to enable those features seems to be the best way that anyone has figured out to do that. Heck, I work with one vendor that requires separate licenses for virtually every checkbox in their GUI; turning up one customer port may involve purchasing dozens of new licenses. The customers of their product don't like it, sure, but suggest that they pay the full cost of enabling all options on all ports and they flip out. Licensed features enable customers to purchase only what they need, not what some marketing puke decides they need (or some one-size-must-fit-all pricing scheme, which rarely works well). S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: what about 48 bits?
On 05 Apr 2010 12:43, valdis.kletni...@vt.edu wrote: On Mon, 05 Apr 2010 13:29:20 EDT, Jay Nakamura said: I would have attributed the success of Ethernet to price! You've got the causality wrong -- it wasn't cheap, way back when. I remember back in '93~94ish (I think) you could get a off brand 10BT card for less than $100, as oppose to Token Ring which was $300~400. I can't remember anything else that was cheaper back then. If you go back before that, I don't know. Steve is talking mid-80s pricing, not mid-90s. By '93 or so, the fact that Ethernet was becoming ubiquitous had already forced the price down. Ah, but what _caused_ Ethernet to become ubiquitous, given the price was initially comparable? The only explanation I can think of is the raft of cheap NE2000 knock-offs that hit the market in the late 1980s, which gave Ethernet a major price advantage over Token Ring (the chips for which all vendors _had_ to buy from IBM at ridiculous cost). That, in turn, led to mass adoption and further economies of scale, pushing the price lower and lower in a virtuous cycle. Still, lots of shops stuck with TR well into the mid- and even late 1990s because Ethernet didn't perform as well as TR under moderate to high utilization by multiple hosts, not to mention IBM's insistence that TR was required for SNA. It wasn't until Ethernet switching came out, mostly solving CSMA/CD's performance problems and eventually leading to full-duplex operation, that it was entirely obvious which was going to win, and I spent several years doing almost nothing but helping large enterprises convert to Ethernet (usually with the help of DLSw). By that point, off-brand Ethernet chips cost _less than 1%_ of what IBM's TR chips did, thanks to competition and sheer volume, so vendors had started including them for free on every PC and server, and that was the final nail in TR's coffin. (LocalTalk, ARCnet, and a variety of other physical layers suffered a similar fate, but unlike IBM, their backers quickly switched to Ethernet when they realized they couldn't compete with it on price _or_ on performance given their limited volumes, so those deaths were more sudden and absolute than TR's.) As to why no other technology has managed to dislodge Ethernet, though, I think it's fairly clear that's because the various successors to 10BaseT have all maintained the same connector and the same framing, which makes for trivial upgrades that deliver regular (and significant) performance improvements as customers' equipment replacement cycle turns. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Using /31 for router links
Michael Sokolov wrote: That is why I hate Ethernet with a passion. Ethernet should be for LANs only; using Ethernet for WANs and PTP links is the vilest invention in the entire history of data networking in my opinion. Ah, but who's to say that all PTP links are WANs? Are you really going to run an OC-48 from one router to another _in the same building_ when you need 1Gb/s between them? Have you looked at how much more that would cost? Ethernet interfaces, particularly copper, are dirt cheap. Even for MANs or WANs, the price of a pipe (plus equipment at each end) will still often be significantly lower for Ethernet than for real circuits--especially if you don't plan on using all the bandwidth all of the time. My medium of choice for PTP links (WAN) is HDLC over a synchronous serial bit stream, with a V.35 or EIA-530 interface between the router and the modem/DSU. Over HDLC I then run either RFC 1490 routed mode or straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP header follows...). My 4.3BSD router (or I should better say gateway as that's the proper 80s/90s term) then sees a PTP interface which has no netmask at all, hence the near and far end IP addresses don't have to have any numerical relationship between them at all. No netmask, no MAC addresses, no ARP, none of that crap, just a PTP IP link. Well, it'd certainly be nice if someone would make something even cheaper than Ethernet for that purpose (which would squeeze out a few more bits of payload), but so far nobody has. It's hard to beat Ethernet on volume, and that's the main determinant of cost/price... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Breaking the internet (hotels, guestnet style)
Jens Link wrote: Owen DeLong o...@delong.com writes: I expect my connections to my mail server to actually reach my mail server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many of the just works settings in question break these things badly. One of my customers has an appliance for his WLAN guest access access which filters out records. :-( j...@bowmore:~$ dig www.quux.de @8.8.8.8 +short j...@bowmore:~$ That, unfortunately, is not uncommon. Actually, it's one of the _less_ broken systems I've seen, since IPv4 presumably keeps working. One major vendor of hotel guestnet equipment returns an A record for 0.0.0.1 if you do an ANY or query for any hostname--even ones that don't exist. At least with WinXP, you have to disable IPv6 just to get IPv4 to work! Worse, their tech support sees nothing wrong with this; if you disagree, all they'll do is offer a refund. Unfortunately, take your money elsewhere doesn't work when you've already paid for the hotel room--and they know it. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: FCCs RFC for the Definition of Broadband
Jack Bates wrote: Roy wrote: The problem that the FCC faces is making a realistic definition that can apply to the whole US and not just cities. If I'm reading this question right, the issue is that Congress appropriated some pork for rural broadband and now it's up to the FCC to guess what Congress intended that to mean so they can determine which applicants will be allowed to feed at the public trough. I'd say that most laymen currently consider broadband to be an always-on service at 1Mb/s or faster, regardless of the particular technology used. FTTH sounds attractive, but there's just not enough pork to actually do it for a non-trivial number of rural homes; it's barely feasible for (sub)urban homes. FTTC is the only realistic option, with the last mile being either existing copper or existing coax. The curb has a slightly different meaning in a rural area, of course, but that doesn't need to be specified in the definition anyway. How does fiber (home or curb) figure in the rural sections of the country? It figures in nicely, thank you. Of course, our definition of curb might be 1.5 miles further than your definition. ;) 2 miles is the cutoff for 10mb/s reliability, but to deal with future stuff, most of my telco customers have dropped it down to 1.5 miles. My ILEC's techs claim they can run VDSL2 several miles but lose about 1Mb/s per 1000ft from the head end. Luckily I'm about 1500ft from mine, and my line tested out at ~58Mb/s -- though they'll only sell me 10Mb/s of that for data and 25Mb/s of it for TV. It's amazing how far we've come in the last two decades since I got my first 2400bps modem. If VDSL2 can't go far enough for rural areas and/or would require more remote units than is feasible, I'd say that ADSL is fast enough that it should also qualify. Supporting triple-play should not be a requirement, IMHO, as customers can always use DBS for TV and most people who claim to have broadband today don't have or can't get triple-play. I wouldn't go as far as accepting ISDN/IDSL, though, if anyone is even still selling that junk. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: ipv6 only DNS?
Joe Abley wrote: Some time ago I checked the ORG and INFO registries and discovered that the number of host objects there with IPv6 address attributes was very small. I presumed at the time that it was either hard to find a registrar that would support IPv6 addresses for hosts, or that people were just not paying much attention to v6-only resolution. At least for now, it's pretty well accepted that basic servers like DNS, SMTP, IMAP, HTTP proxies, etc. MUST be dual-stacked for the duration of the transition. Even if your clients are IPv6-only, they can still resolve hostnames, send mail, surf the web, etc. to sites that are IPv4-only via those few servers. Generic, scalable solutions would be better rather than protocol-specific proxies of course, and the IETF is working on that angle, but in the meantime it'll allow the most common client-server protocols to keep working and get some experience with IPv6. Also, keep in mind that the vast majority of folks out there still can't get native IPv6 transit from their upstreams and may not be willing to trust free tunnel brokers with production traffic to their servers. Even if they can, most eyeballs trying to hit them are still IPv4-only and the few IPv6 eyeballs can be assumed to have proxies since otherwise they couldn't see 99.% of the Internet. This is what it looks like before critical mass is achieved. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Where to buy Internet IP addresses
Charles Wyble wrote: ([*] according to the wiki, firewire and zigbee are the only things using EUI-64. I don't know of anyone using firewire as a network backbone. (obviously, not that you care.) Zigbee is relatively new and similar to bluetooth; will people use them as a NIC or connect little zigbee gadgets to the internet -- well, there are coffee makers, vending machines, and christmas lights on the internet, so as a novelty, certainly. How many bluetooth devices are running IP over bluetooth? That said, I could see PAN meshes (personal area networks) eating a huge number of addresses, but /64???) Utility companies utilize Zigbee pretty extensively. So that's millions and millions of addresses right there. A million addresses is 1/16th of one OUI in EUI-48, and there are 4,194,304 OUIs (after you take out the local/global and multicast/unicast bits). Billions or even trillions of addresses are manageable without needing EUI-64; millions is a drop in the bucket. Still, it's good to know that another link layer -- which people _will_ be running large IPv6 networks on -- is using EUI-64 and that it's not just a FireWire thing. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Where to buy Internet IP addresses
Jack Bates wrote: Mikael Abrahamsson wrote: Why wouldn't DHCPv6-PD work within the home as well as between the ISP and the home? DHCPv6-PD requires manual configuration. It doesn't need to; that's just a flaw in current implementations. I see little reason why the main home gateway can't get a /56 from the ISP, and then hand out /62 (or whatever) to any routers within the home that asks for PD? Sure, but how does the router know it needs to hand out a /62? Then what about the router after that? Does it hand out a /61? then the router behind that? What if the ISP only gave a /60? I think some folks are getting the model wrong. Each router requests from its upstream router the delegation of a /64 for each downstream link and inserts the appropriate route when a response arrives. If it receives a PD request on its downstream interface, it forwards it upstream; when the reply comes back, it inserts the appropriate route and forwards the reply to the requester. Presto, a non-geek user can chain as many CPE devices as desired and they automagically configure themselves. (The ISP who's serving all these requests _could_ preallocate a /48 or /56 per customer, which might make aggregation in the PE router easier, or they could just have a gigantic pool per PE router and hand out as many /64s as required to each customer, which would [unnecessarily, IMHO] conserve address space.) However, as interesting as this may be, it's not particularly useful to discuss how consumer ISPs _might_ do DHCPv6 PD when none of them have shown much interest in providing any IPv6 connectivity at all and many are blocking (through mandatory NAT) even 6to4. And, until the eyeballs can speak IPv6, the content isn't going to speak it either... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Where to buy Internet IP addresses
Bill Stewart wrote: When I came back, I found this ugly EUI-64 thing instead, so not only was autoconfiguration much uglier, but you needed a /56 instead of a /64 if you were going to subnet. It's supposed to be a /48 per customer, on the assumption that 16 bits of subnet information is sufficient for virtually anyone; exceptions should be rare enough that they can be handled as special cases. The /56 monstrosity came about because a US cable company wanted to assign a prefix to every home they passed, regardless of whether it contained a customer, so that they'd never need to renumber anything ever again. However, that would require they get more than the /32 minimum allocation, and ARIN policy doesn't allow _potential_ customers as a justification for getting a larger allocation, so they had to shrink the per-customer prefix down to a /56 to fit them all into a single /32. If all those assignments were to _real_ customers, they could have gotten a /24 and given each customer a /48 as expected. And, after that, many folks who can't wrap their heads around the size of the IPv6 address space appear to be obsessed with doing the same in other cases where even that weak justification doesn't apply... Does anybody know why anybody thought it was a good idea to put the extra bits in the middle, or for IPv6 to adopt them? Why the switch from EUI-48 to EUI-64? Someone in the IEEE got worried about running short of MAC (er, EUI-48) addresses at some point in the future, so they inserted 16 bits in the middle (after the OUI) to form an EUI-64 and are now discouraging new uses of EUI-48. The IETF decided to follow the IEEE's guidance and switch IPv6 autoconfig from EUI-48 to EUI-64, but FireWire is the only significant user of EUI-64 addresses to date; if you're using a link layer with EUI-48 addresses (e.g. Ethernet), an extra 16 bits (FFFE) get stuffed in the middle to transform it into the EUI-64 that IPv6 expects. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Fiber cut in SF area
Mike Lewinski wrote: Joe Greco wrote: Which brings me to a new point: if we accept that security by obscurity is not security, then, what (practical thing) IS security? Obscurity as a principle works just fine provided the given token is obscure enough. Ideally there are layers of security by obscurity so compromise of any one token isn't enough by itself: my strong ssh password (1 layer of obscurity) is protected by the ssh server key (2nd layer) that is only accessible via vpn which has it's own encryption key (3rd layer). The loss of my password alone doesn't get anyone anything. The compromise of either the VPN or server ssh key (without already having direct access to those systems) doesn't get them my password either. I think the problem is that the notion of security by obscurity isn't security was originally meant to convey to software vendors don't rely on closed source to hide your bugs and has since been mistakenly applied beyond that narrow context. In most of our applications, some form of obscurity is all we really have. The accepted standard is that a system is secure iff you can disclose _all_ of the details of how the system works to an attacker _except_ the private key and they still cannot get in -- and that is true of most open-standard or open-source encryption/security products due to extensive peer review and iterative improvements. What security by obscurity refers to are systems so weak that their workings cannot be exposed because then the keys will not be needed, which is true of most closed-source systems. It does _not_ refer to keeping your private keys secret. Key management is considered to be an entirely different problem. If you do not keep your private keys secure, no security system will be able to help you. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Google Over IPV6
Robert D. Scott wrote: http://www.google.com/intl/en/ipv6/ http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html It's relatively easy to make _your own_ apps (i.e. ones you have the source for) support IPv6. Most companies, though, are completely reliant on their vendors, which means buying a new version, testing, deployment, etc. -- assuming the vendor is still in business, hasn't discontinued the product, has even bothered to try implementing IPv6 yet (most haven't), etc. That may also involve an upgrade of the OS that the app runs on, purchasing new hardware to handle the bloat in newer OSes, etc. You may also need to upgrade your LAN hardware to models that support IPv6 forwarding in hardware, more RAM for routers to run IPv6 code (if it's even available), new VPN boxes, etc. Now, if you keep up with your upgrades every year, and stop using products when the vendors stop supporting them or go out of business, most of this should already be built into your budgets -- but not many execs see value in that. If it ain't broke so badly that it cuts into profits, you don't need any budget for it. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: ARIN Emergency Policy Change
Joe Abley wrote: On 25-Mar-2009, at 18:24, Leo Bicknell wrote: The ARIN Board has put forth an emergency policy change: https://www.arin.net/policy/proposals/2009_1.html For those not following the discussion on ppml, and perhaps not especially familiar with the policu or the policy process, could you either describe or give a concise link to a description of the context for this change? Textually, the change is fairly simple. Proposal 2008-6 [1] was adopted by the BoT after a finding of consensus by the ARIN AC, and the relevant part reads: Policy statement: Emergency Transfer Policy for IPv4 Addresses For a period of 3 years from policy implementation, authorized resource holders served by ARIN may designate a recipient for number resources they release to ARIN. Number resources may only be received under RSA in the exact amount which can be justified under ARIN resource-allocation policies. Timetable for implementation: This policy, once ratified by the ARIN Board of Trustees, would be implemented when either the free-pool of IANA addresses is exhausted or IPv4 address resources in the ARIN Region reach a threshold of scarcity recognized by the ARIN Board of Trustees as requiring this policy implementation. The BoT then proposed emergency policy 2009-1 [2], which has some minor editorial changes (e.g. section renumbering) and the following relevant text: *8.3 Transfers to Specified Recipients* Number resources may be released, in whole or in part, to ARIN for transfer to another specified organizational recipient, by any authorized resource holder within the ARIN region. Such transferred number resources may only be received by organizations that are within the ARIN region and can demonstrate the need for such resources in the exact amount which they can justify under current ARIN policies. Most notably, the revised text does not contain the 3-year sunset clause that was a fundamental part of 2008-6. It is also unclear (to me) whether the timetable for implementation specified in 2008-6 also applies to 2009-1. As to the remaining changes, you can decide for yourself whether the rewrite has a material effect on the type of IPv4 address market this policy would create. The BoT did not mention any relevant issues with the text of 2008-6 to the PPML, to the AC, or at the Public Policy Meetings it was discussed at prior to taking this action, nor has it (officially[3]) published any explanation for its changes, why it could not send 2008-6 back to the AC for modification, or why it believes there is an emergency that precludes this proposal following the normal PDP. The use of the Emergency PDP requires a last call that ends 7 Apr 2009, less than a month before the next Public Policy Meeting (26-29 Apr 2009). My opinion: This policy should be rejected, regardless of its merits, because of how the BoT has (so far) handled it in violation of the spirit (though, admittedly, not the letter) of the process, how it disregards community consensus and attempts to sidestep community review, the complete and utter lack of transparency that we expect from ARIN, and the glaringly obvious lack of any emergency with a policy that isn't expected to be implemented for _at least_ another year or two. If there is indeed a flaw in 2008-6 that needs correcting, let it be discussed at the meeting next month and the AC and BoT can then take the appropriate non-emergency action. S [1] https://www.arin.net/policy/proposals/2008_6.html [2] https://www.arin.net/policy/proposals/2009_1.html [3] The BoT Chair has posted several messages on PPML about this, but they do not appear to be official statements by the entire BoT. I haven't noticed any other BoT members commenting. -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: IPv6 Confusion
David Conrad wrote: If a vendor sales person indicates they are getting no requests for IPv6 support in their products (which would clearly be false since presumably you are requesting IPv6 support), It's hard to imagine a vendor that is getting _no_ requests for IPv6 support these days; every RFP I see has it listed as an optional requirement. However, development priorities are set not by requests but by the amount of business they'll lose if they /don't/ do something. Since IPv6 is not _mandatory_ to win deals in most cases, it's simply not getting done. And, of course, customers can't make it mandatory in an RFP until at least one vendor has implemented it, or they risk getting no qualified responses... I bet the latter is why the US DoD gave up on their hard IPv6 requirements and now simply mandates that products be software upgradeable to support IPv6... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Ricky Beam wrote: On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk step...@sprunk.org wrote: Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate. This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null. In the case of NAT, the helper has to understand the protocol to know what traffic to map. In the case of a stateful firewalling (non-NAT), the helper has to understand the protocol to know what traffic to allow. Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.) Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. This mangling can be a serious source of problems. With UDP, it can introduce checksum errors. With TCP, not only do you have possible checksum errors, you also have to mangle the sequence numbers in both directions if the length of the payload changes. The mangling will inherently break standard IPsec and other shim layers like HIP. And let's not forget that NAT makes widespread deployment of any L4 alternative to TCP and UDP (e.g. SCTP) virtually impossible, forcing every new transport or shim protocol to inefficiently ride on top of TCP or UDP... Some protocols, e.g. SIP/RTP, also work fine through a stateful firewall even without an ALG in most cases -- but not when you add in NAT. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Matthew Moyle-Croft wrote: Stephen Sprunk wrote: You must be very sheltered. Most end users, even security folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on security through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. I assume you're referring to ALG code? Indeed, I've found that turning off ALGs in NAT/FW boxes fixes a lot of problems, because every vendor's seem to be broken in a different way. I deal mainly with SIP these days, and the first step in any sort of firewall-related troubleshooting is to turn _off_ any SIP ALG functionality in the CPE because 90% of the time, that's whats breaking things; the end devices can deal with NAT as long as there's nobody in the middle mangling their packets. Ideally, ALGs would fix up the packets such that the endpoints didn't need to be NAT-aware, but they're all (and I mean all, not most) so hideously broken that they make things worse, not better. They can't get even simple, fossilized protocols like active FTP working most of the time; there's no way they'll do better with newer, more complicated ones like SIP or the dizzying array of P2P and IM protocols. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream. Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate. However, to be safe the endpoints cannot assume any firewalls in the path are going to work properly, and the absence of NAT makes it tougher for endpoints to detect firewalls' presence and react as needed... (In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/insert favourite fw is for enterprise). I've found the enterprise NAT/FW gear to be worse: they attempt to implement more ALGs, but they do no better a job at implementing them than the less-ambitious consumer vendors, so more things break. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Roger Marquis wrote: Seth Mattinen wrote: Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall. NAT provides some security, often enough to make a firewall unnecessary. It all depends on what's inside the edge device. But really, I've never heard anyone seriously equate a simple NAT device with a firewall. You must be very sheltered. Most end users, even security folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on security through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Private use of non-RFC1918 IP space
Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Ethical DDoS drone network
Justin Shore wrote: David Barak wrote: Consider for a moment a large retail chain, with several hundred or a couple thousand locations. How big a lab should they have before deciding to roll out a new network something-or-other? Should their lab be 1:10 scale? A more realistic figure is that they'll consider themselves lucky to be between 1:50 and 1:100, and that lab is probably understaffed at best. Having a dedicated lab manager is often seen as an expensive luxury, and many businesses don't have the margin to support it. At the very least they should have a complete mock location (for an IT perspective) in a lab. Identical copies of all local servers and a carbon copy of their official template network. This is how AOL does it. Every change is tested in the mock remote site before the official template is changed and the template is pushed out to all the production sites. That's useful for testing changes to the remote site itself, but it doesn't do anything for testing changes to the entire WAN. I've seen _many_ routing problems appear in large WANs that simply can't be replicated with fewer than a hundred or even a thousand routers. The vendors may have tools to simulate such, since they need them for their own QA, support, etc. but they rarely give them to customers because that'd be another product they have to support... S smime.p7s Description: S/MIME Cryptographic Signature
Re: Telecom Collapse?
Skywing wrote: No POTS line here. New office is all VoIP, too. For my own use, though, I'm sticking with cell. Don't recall the last time that there was an outage to the point where I couldn't make a voice call in the past few years (though I've seen EVDO data go down for my region and have had to fall back to 1xRTT for an hour or once in the past couple years). Ditto for my GSM/EDGE/3G service; coverage has simply gotten too good (and too cheap) to bother with a land line at home anymore. And that, more than VoIP, is what is killing the ILECs. Naturally, that doesn't really disprove a negative, but the chances of there being, all at the same time: - a sufficiently localized disaster where I'd have to call 911, and - a sufficiently broad disaster where the cell infrastructure had completely failed for all the CDMA carriers in my area, and - nobody near by who could help or had a landline, and - despite said broad disaster taking out *ALL* CDMA cell networks within range, a condition that still permitted landlines to operate ...seem to be quite vanishing to me. Not impossible, but there's a whole lot more likely concerns to deal with than that, nowadays. The only likely types of situations that might result in that, in general, would probably be things like wide-area hurricane-style events. Those typically provide enough advance warning to get out of harm's way. (Not that I would have to worry about hurricanes in the middle of the continental US, anyway.) And, of course, if such an event _did_ occur, the authorities would certainly already know about it without your call -- if you could even get through to them. Even in everyday conditions, calls to 911 here have hold times of several minutes to get an operator. I wouldn't even bother trying, land line or otherwise, if I had an actual emergency; it'd be faster to drive to the nearest hospital/fire station/police station for help. (Unfortunately, the police and fire depts. have stopped publishing their direct numbers, and if you can still find them somewhere, all you get is a recording telling you to call 911 -- even for non-emergency calls.) S smime.p7s Description: S/MIME Cryptographic Signature
Re: Origin ASN seen vs Origin ASN in Whois Records Report?
Joe Abley wrote: On 19 Nov 2008, at 19:16, Heather Schiller wrote: ARIN makes available a list of prefixes with OriginAS. I don't know if other RIR's do. How is that list generated? I'm not aware of any tight coupling between address assignment and AS assignment that binds anybody to advertise particular routes with particular origins, at least at the time that either is assigned/allocated by an RIR/LIR. Presumably it's from the Origin AS field in WHOIS: http://www.arin.net/registration/templates/netmod.txt Template: ARIN-NET-MOD-4.1 ** As of February 2007 ** Detailed instructions are located below the template. 01. Registration Action (M or R): 02. IP Address and Prefix or Range: 03. Network Name: 04. Origin AS: ... 04. List all AS numbers from which the network may originate. You can list as many AS numbers as necessary. You must separate multiple AS numbers with a comma. You may not list AS number ranges; only list individual AS numbers. Interesting is how accurate the field actually is. Slide 6 at: http://www.arin.net/meetings/minutes/ARIN_XXII/PDF/friday/engineering_report.pdf says that 91% of the routes they checked had a correct Origin AS in WHOIS, compared to 64% in the ARIN IRR database. S smime.p7s Description: S/MIME Cryptographic Signature
Re: Sprint v. Cogent, some clarity facts
David Schwartz wrote: Your customers pay you to carry their traffic across your network between them and the next network in the line. There is no reason anyone else should compensate you for doing this. What it all comes down to is that the majority of eyeballs are on residential connections that are relatively expensive to provide but for which are sold at a relatively low price (often 1/10th as much per megabit of capacity). Those eyeball ISPs cannot or will not charge their customers the full cost of receiving traffic so they want money from the more profitable content ISPs sending the traffic to offset their losses. This is also one of the reasons eyeball ISPs want to stamp out P2P: both ends of the connections are on unprofitable lines and there is _nobody_ paying for the traffic. Just follow the money. S
Re: IPv6 Wow
Mikael Abrahamsson wrote: This brings up an interesting question, should we stop announcing our 6to4 relays outside of Europe? Is there consensus in the business how this should be done? I have heard opinions both ways. I can understand why some folks would say stop, but unfortunately Europe has the closest public 6to4 relays to the US, and our own providers don't seem to want to put any up. That means 6to4 will break for a great many folks who _are_ trying to use IPv6 (like developers trying to get ahead of the curve and make sure their apps don't break when the transition finally happens) but whose providers haven't clued in yet. (My traceroutes to 192.88.99.1 have a next-to-last hop in Amsterdam, and I'm on one of the largest ISPs in the US, which apparently hasn't figured out 6to4, much less native IPv6.) S
Re: the Intercage mess
William Pitcock wrote: On Wed, 2008-09-24 at 19:28 -0700, Paul Ferguson wrote: On Wed, Sep 24, 2008 at 7:24 PM, Randy Bush [EMAIL PROTECTED] wrote: John Bambenek wrote: When there is no law to speak of all that is left is tribal justice. this way lies lynch mobs shall we at least apply a vernier of civilization I think that _more_than_reasonable_ background research, historical record, etc. have met the qualifications of civilized vernier. The outcry was, and is not, arbitrary. No, but forcing them offline now that they are taking a new approach to handling abuse is ridiculous. Intercage are reaching out to the anti-abuse community and yet some people on NANOG keep interfering with the cleanup process. How do you expect them to clean up their network and return to normal operations (with considerably less abuse) if it keeps being disconnected? The shit isn't even there anymore. These kids have moved it elsewhere. Intercage have learned their lesson, just leave them alone and let the people who have *real* problems (e.g. me, Andrew Kirch of AHBL, Spamhaus, Gadi, etc.) with Intercage deal with this. They _claim_ they have learned their lesson and cleaned up their act. However, that does not erase the _years_ that they knew what was going on and happily took miscreants' money for polluting the commons. The police and courts are impotent, so it falls to the victims to take action. I hate lynch mobs as much as the next guy, but the law _does_ allow people to defend themselves and protect themselves from future harm by proven bad actors. They could be lying; we have no proof they're not, so given their track record, we must assume they are. What's to stop them from next week going back to the folks they've disconnected and taking their money again, again abusing the community. Even if they're not lying, application of the Death Penalty, as obviously justified in this case, is the _only_ way to discourage others from doing the same thing by instilling the fear of the same consequences. S
Re: hat tip to .gov hostmasters
Kevin Oberman wrote: Date: Mon, 22 Sep 2008 11:42:33 -0400 From: Goltz, Jim (NIH/CIT) [E] [EMAIL PROTECTED] Remember, they've also mandated IPv6 support on all backbones. Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed. Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make IPv6 capable. The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort. They mandated that all products, not just hardware, support IPv6. However, all that the requirement turned out to be, in practice, is that all products be software upgradeable to IPv6. My employer is still selling stuff by the truckload to the USG because the hardware itself is IPv6 capable (just like it's OSI or DECnet capable), but we haven't written a single line of IPv6 code yet because customers aren't actually demanding it and we have other, more profitable, things to spend developers' limited time on. For vendors whose hardware needs to change for IPv4, like core routers, this is a big deal; for the rest of us, it was a non-event once we read the fine print. S
Re: LoA (Letter of Authorization) for Prefix Filter Modification?
Azinger, Marla wrote: I use RWHOIS for proof of who we assign and allocate address space to. I dont believe an LOA is any more valid or secure than my RWHOIS data base that I keep and update on a daily basis. In this case I find it a waste of time when people ask me for LOA's when they can verify the info on my RWHOIS site. And I point these people to my RWHOIS site when they ask for LOA as opposed to wasting my time on creating paperwork. However, if you dont have something like that set up, then I do see the value in people asking for LOA and thus helping to ensure address space isnt getting hijacked. How is _you_ showing information in an RWHOIS server that _you_ control in any way proving that the holder of a address block is authorizing _you_ to advertise it on their behalf? It is not unreasonable for your upstreams to ask for some proof _from the holder_ rather than simply trusting you. For all they know, you're just hijacking random address space and putting it in your RWHOIS server. Would you be happy if some random Tier 1 started letting _their_ customers advertise _your_ address space, just because those customers had put up an RWHOIS server claiming it was theirs? This is not about asking you for an LoA for your own address space, which any moron can follow in a reasonably trustworthy chain from ARIN to you. It's about address space that is _not_ directly registered to the company trying to get a filter exception. S
Re: Identifying when netblocks have been assigned
Frank Bulk wrote: When I do that it lists the organization's AS, but not any netblocks associated with that AS. Frank -Original Message- From: Jake Mertel [mailto:[EMAIL PROTECTED] Frank, Add the operator in front of the organizations ARIN ID when you do your WHOIS query and it will show all of the resources allocated to that organization. Keep in mind that the OrgID trick only works for allocations or assignments made directly by ARIN; it won't necessarily show you everything that was SWIPed to them, since many SWIPs are not tagged with an OrgID. To find those, you have to search on the name of the customer and hope it shows up correctly in the CustName field. Also, many companies end up with lots of OrgIDs, and many of them may not have the correct current name due to MA activity. Finding them all may take a while and isn't easily automated. S
Re: ingress SMTP
Alec Berry wrote: Michael Thomas wrote: But the thing that's really pernicious about this sort of policy is that it's a back door policy for ISP's to clamp down on all outgoing ports in the name of security. I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). I see nothing wrong with filtering commonly abused ports, provided that the ISP allows a user to opt out if they know enough to ask. When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. I also agree with the comments about switching customers to 587. My former monopoly ISP only accepted mail on 25 and I had endless problems trying to send mail from airports, hotels, coffee shops, etc. while traveling. The same hotspots also tended to block port 22, so I couldn't even forward mail via my own server. However, my new monopoly ISP only accepts mail on 587, and I have yet to have a single problem with that from any hotspot I've used since the switch. Ditto for reading my mail via IMAPS/993, whereas I used to have occasional problems reading it via IMAP/143. S
Re: Force10 Gear - Opinions
Paul Wall wrote: On Fri, Aug 22, 2008 at 10:34 AM, Matlock, Kenneth L [EMAIL PROTECTED] wrote: Does anyone here have real-world experience with Force 10 gear (Specifically their E-Series and C-Series)? They came and did their whole dog and pony show today, but I wanted to get real-world feedback on their gear. I need to know about their 1) Reliability 2) Performance EANTC did a comprehensive study of the E-series: http://www.eantc.de/en/test_reports_presentations/test_reports/force_10_sfm_failover_video_ftos_6211.html http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/EANTC_Full_Report.pdf http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/Section_8.pdf Standard benchmarketing. Not that I blame Cisco or EANTC for that, since they were debunking some benchmarketing done by Force10 and Tolly, but consider the source (and follow the money) when reading any independent test and what that means for accuracy. 80% of the EANTC report can be summed up as The default CAM profile didn't do what we wanted, and we didn't bother asking Force10 for the commands to make it work. There are indeed some interesting product weaknesses, like any vendor has, but the fact that Force10's CAM can be partitioned to match the buyer's needs, rather than having a fixed configuration that all customers are forced to use, is an advantage in my book. S (Disclosure: I am a former employee of both Cisco and Force10, but have no ties to either today.)
Re: [NANOG] Microsoft.com PMTUD black hole?
Thus spake Nathan Anderson/FSR [EMAIL PROTECTED] A member of Microsoft's GNS network escalations team saw my postings on NANOG about this issue and took offense at my use of this forum to raise this issue with them, and criticized me as being unprofessional and lacking in business acumen. First, it's unprofessional and lacking in business acumen for someone to criticize their customers to their face. As one manager taught me, The customer may not always be right, but they're never wrong. Second, it's their own damn fault for not maintaining their contact information properly in public databases. If the only option they leave you is to post to NANOG, because they don't respond to (or even accept) direct requests to the listed contacts, then that's what you have to do. Many companies are guilty of the latter, and we all get the benefit of seeing the state of their customer service for reference when making future buying decisions. Very few are arrogant enough to do the former, though. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
