Re: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]
In a message written on Thu, Mar 13, 2008 at 03:26:48PM +0200, Pekka Savola wrote: On Wed, 12 Mar 2008, Leo Bicknell wrote: ISP's are very good at one thing, driving out unnecessary cost. Running dual stack increases cost. While I'm not sure about the 5 year part, I'm sure ISP's will move to disable IPv4 support as soon as the market will let them as a cost saving measure. Runing for decades dual stacked does not make a lot of economic sense for all involved. So, can you elaborate why you think the cost of running dual stack is higher than the cost of spending timemoney on beind on the bleeding edge to do v6-only yet supporting v4 for your existing and future customers still wedded to the older IP protocol? You are mixing stages of adoption. The Internet will progress as follows: 1) Early adopters deploy IPv6 while continuing to make most of their money off IPv4. We're already well into this state. 2) Substantially all ( 90%?) of the Internet is dual stacked, or has other transition mechanisms in place. 3) IPv4 is removed from the network, leaving only IPv6. Your comment compares the cost of phase 1 to the cost of phase two, making the assumption that it's more expensive to be an early adopter than it is to run dual stack down the road. On that point, I agree. My point is once we're in phase #2 the bean counters will look around and start to ask can we reduce cost if we remove IPv4. The answer will be yes. Initially the answer will be but our customers will be upset, and it won't happen, but the bean counters are persistent, and will keep asking the question over and over. They will make sure phase 2 lasts no longer than it must. Which brings us into phase 3. While engineers may see it as simple clean up, large networks will see phase 3 has a huge money saving operation by that point in time. Once the first major (top 10?) network removes IPv4 support I expect all the rest to follow within 2 years, tops. Edge and nitche networks may support it longer, but it will drop from the Internet core quickly. The specific original comment was that we would run dual-stacked, that is in phase 2, for decades. I proport there are strong economic reasons why that is probably not ging to be the case. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpDI8UStbi8R.pgp Description: PGP signature
Re: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]
In a message written on Thu, Mar 13, 2008 at 05:18:16PM +0200, Pekka Savola wrote: Who has the other transition mechanisms in place? What is the cost of deploying those transition mechanisms? At present it's not obvious how you can explain to the bean counters that deploying these are profitable. It's very hard, so most people aren't deploying, yet. My point is that it seems somewhat premature to talk extensively of 2) - 3) transition because we haven't even figured out 1) - 2) yet. Getting to 2) is the challenge, from there it is straightforward. The driver for 1-2 is the end of the IPv4 free pool. It doesn't much matter if the cause is IPv4 simply not being available anymore, or if the result is some way of moving IPv4 addresses around for money; they both will get the bean counters attention real quick. In essense the cost of IPv4 is going to dramatically rise, one way or another. And that's only the first order effect of getting the addresses. Second order effects like hanling the routing table deaggregation haven't begun to be calculated. So basically the IPv4 free pool exhaustion will drive 1-2 rather rapidly. Once we're in state 2, simple economics will drive the 2-3 transtion rather rapidly. 20 years ago was 1988. The World Wide Web did not even exist. AOL (the first service branded under that name) wasn't launched until 1989. A T1 served an enter university campus. 9600 baud was a fast modem. In essense, the entire industry as we know it was built in the last 20 years. Now think hard about a prediction we'll still be running IPv4 in 20 years. A two decade transition period just does not fit this industry's history. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpVCVnV6tYYq.pgp Description: PGP signature
Re: IPv6 on SOHO routers?
In a message written on Wed, Mar 12, 2008 at 03:06:24PM -0500, Frank Bulk - iNAME wrote: Furthermore, he stated that networking equipment companies like Cisco will be moving away from IPv4 in 5 years or so. This is the first time I've heard this posited -- I had a hard believing that, but he claims it with some authority. Anyone hear anything like this? My own opinion is that we'll see dual-stack for at least a decade or two to come. ISP's are very good at one thing, driving out unnecessary cost. Running dual stack increases cost. While I'm not sure about the 5 year part, I'm sure ISP's will move to disable IPv4 support as soon as the market will let them as a cost saving measure. Runing for decades dual stacked does not make a lot of economic sense for all involved. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpCewdFdfeY9.pgp Description: PGP signature
Re: NetworkSolutions - Was: Re: v6 gluelessness
In a message written on Thu, Jan 24, 2008 at 08:15:41AM +0900, Randy Bush wrote: ugly ugly ugly. tucows, wake up and smell the coffee! yes... :( also Joker, and everyone else :( how do we move this forward across the board? this is going to be a serious impediment. It's a pitty ICANN can't say you accept IPv6 addresses or you can't run xyz, pass it on. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpVou32OC1B2.pgp Description: PGP signature
Re: request for help w/ ATT and terminology
Some networks (of note, the larger ones) have registered a customer ASN. The idea is that networks advertised from their backbone ASN should only be the ones they own, and all customers who have no ASN use the customer ASN to originate their block. In most cases the contract prohibits using the customer ASN with another provider; it is only to be used to single home to the one network. I have no personal experience with ATT in this configuration, but with several other networks they would prefer an eBGP session where they send you a default and you send them your prefix using the ASN they assign. Aside from keeping the prefixes segregated by ASN it also makes the routing policy a lot simpler. Typically things announced by the backbone ASN may appear in prefix lists across the network, while the customer ASN is just another session. One of the more interesting big network problems is the front line support tend to not be creative thinkers, and also tend to believe their internal terminology is industry standard speak. This can make it difficult to get what you want. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgphFSSISNmdD.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
In a message written on Thu, Dec 27, 2007 at 11:27:13AM +0100, Iljitsch van Beijnum wrote: 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information. I would note, it's not too late to fix these problems. We don't have wide spread IPv6 deployment yet, and I can't imagine it's all that hard to send a default gateway in DHCPv6, for example. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpgZ7FayQI7H.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpy9pOPQJ1De.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch wrote: RA is a shotgun. All hosts on a segment get the same gateway. I have no idea what a host on multiple segments with different gateways would do. Hosting environments can get complex thanks to customer I would like to point out that in IPv4 we have ICMP Router Advertisement messages. I have never seen them used on a production network. I know one of the worries is security, that a compromised host could send out advertisements, drawing traffic to it that it can then snoop and pass on to the real gateway. Having not looked in great detail, I am unclear if IPv6 has done something to fix this concern or not. Is this feature going to get turned off when the first worm comes along that spoofs RA's -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpkunR03iHNX.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
In a message written on Wed, Dec 26, 2007 at 09:19:54PM +0100, Iljitsch van Beijnum wrote: Many switches can enforce a MAC/port relationship, so that MAC addresses can't be spoofed. Which gets to the crux of my question. If you're a shop that uses such features today (MAC/Port tracking, DHCP snooping, etc) to secure your IPv4 infrastructure does IPv6 RA's represent a step backwards from a security perspective? Would IPv6 deployment be hindered until there is DHCPv6 snooping and DHCPv6 is able to provide a default gateway, a-la how it is done today in IPv4? It would be very interesting to me if the answer was it's moot because we're going to move to CGA's as a step forward; it would be equally interesting if the answer is CGA isn't ready for prime time / we can't deploy it for xyz reason, so IPv6 is less secure than IPv4 today and that's a problem. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpFRvP23uRdF.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
In a message written on Sat, Dec 22, 2007 at 12:29:54PM +0900, Randy Bush wrote: simon, there are a million chances. and we are notoriously bad at predicting any of them more than a year or so out. Perhaps the take-away is that we shouldn't try to design protocols that last for 30-100 years, but rather design frameworks that make deploying updates easier? Naw. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpsHIxUjPTnw.pgp Description: PGP signature
RIPE is just more fun.
http://www.youtube.com/watch?v=_y36fG2Oba0 -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpIykjL04NwK.pgp Description: PGP signature
Re: Internet access in Japan (was Re: BitTorrent swarms have a deadly bite on broadband nets)
In a message written on Mon, Oct 22, 2007 at 10:20:49PM -0400, David Andersen wrote: The Washington Post article claims that: [snip] b) Fresh new wire installed after WWII I have to wonder what percentage of the population is using phone lines installed before WWII? I live in a suburb that didn't exist 20 years ago other than maybe 50 buildings around the train depot. My neighborhood did not exist 10 years ago, it was a cow pasture. Where's all this old cable? While I'm sure you can find some row houses in $big_city that have old copper I find it hard to believe that pre WWII wire is holding us back. Wasn't it Sprint back in like 1982 or 1984 made a big deal about their entire long haul network being converted to fiber? In a message written on Mon, Oct 22, 2007 at 09:44:34PM -0500, Frank Bulk wrote: A lot of the MDUs and apartment buildings in Japan are doing fiber to the basement and then VDSL or VDSL2 in the building, or even Ethernet. That's how symmetrical bandwidth is possible. Considering that much of the population does not live in high-rises, this doesn't easily apply to the U.S. population. While the US does not have as high a percentage in high rises, let's look at the part that is in the right place. What percentage of US high rises have fiber to the basement and high speed Internet offered to residents? Shouldn't NYC be on par with Tokyo by this point? Chicago? Miami? Doesn't the same model work for low rise apartments, the kind found in suburbia all across the US? Why don't any of them have building provided services, rather relying on cable modems for ADSL all the way back to the CO? Why are no major us builders installing FTTH today? Greenfield should be the easiest, and major builders like Pulte, Centex and the like should be eager to offer it; but don't. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpNxh4Oz1PEV.pgp Description: PGP signature
Re: BitTorrent swarms have a deadly bite on broadband nets
In a message written on Tue, Oct 23, 2007 at 10:34:00AM -0400, Joe Provo wrote: While I expect end-users to miss the boat that providers use stat-mux calculations to build and price their networks, I'm floored to see the sentiment on NANOG. No edge provider of geographic scope/scale will survive if 1:1 ratios were built and priced accordingly. Perhaps the MA colonialism era is coming to a close and smaller, regional nation- states... erm last-mile providers will be the entities to grow with satisfied customers? I'm not sure NANOGers are missing the boat, just bemoaning the economics of the situation and some companies choices. As an example, if I believe http://en.wikipedia.org/wiki/DOCSIS (as I'm no cable export): DOCSIS 1.x, 10.24Mbps upstream. With this providers regularly offered 384-768k upload speeds to customers. DOCSIS 3.0, 122Mbps upstream. That's about 12x. Applying the 12x to the original upload speed that's 4.6-9.2Mbps upload speed per user. And yet, today most of the major national providers don't over more than 1Mbps of upload speed in their fastest packages. Perhaps the real issue here is that broadband providers don't have enough diversity in their products. Picking on an unnamed cable provider and looking at their web site I can get: 4M down, 384k up. $39. 6M down, 768k up. $49. 8M down, 768k up. $59. That's their entire portfolio of residential services. How about a $99 package with 10M down, 3M up? How about $5 per meg download, $20 per meg upload, pick any combination of speeds you want where both are under 20Mbps? And why-o-why are they still giving me modems? Is not the stack of 5 that I already have enough waste? How much of my service charge goes to replacing equipment over and over because it's how they work. (For instance I moved, and got a new modem with the new install, same make and model as the old modem, which they didn't want back.) So, while NANOGers may float the idea of 1:1, what I think really honks them off is that the current standard (4M down, 384k up) is 1:10, and I think they feel it's time it became more like 1:4 (4M down, 1M up), and that seems to be completely within reach of the technology. Which leaves the only thing holding it up being big company management and marketing. I will point out, one of the smaller providers on the Wikipedia page under US, CableVision, is said to have 30Mbps down 5Mbps up. That's 1:6, at a heck of a lot higher speeds. I think most people here would be quite happy with that offering. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpjMM8jpdHXH.pgp Description: PGP signature
Verizon has been listening to nanog.
http://www.usatoday.com/tech/news/2007-10-23-verizon-fios-plan_N.htm 20 Mbps down, 20 Mbps up, fully symmetrical for $65. Strangely enough it's where they compete with CableVisions 30Mbps down, 5Mbps up plan first. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpdP514q5t9K.pgp Description: PGP signature
Re: The next broadband killer: advanced operating systems?
In a message written on Mon, Oct 22, 2007 at 06:42:48PM +0200, Mikael Abrahamsson wrote: You can achieve the same thing by running a utility such as TCP Optimizer. http://www.speedguide.net/downloads.php Turn on window scaling and increase the TCP window size to 1 meg or so, and you should be good to go. A bit of a warning, this is not exactly the same thing. When using the method listed above the system may buffer up to 1 Meg for each active TCP connection. Have 50 people connect to your web server via dialup and the kernel may eat up 50 Meg of memory trying to serve them. That's why the OS defaults have been so low for so long. The auto-tuning method I referenced dynamically changes the size of the window based on the free memory and the speed of the client allowing an individual client to get as big as it needs while insuring fairness. On a single user system with a single TCP connection they both do the same thing. On a very busy web server the first may make it fall over, the second should not. YMMV. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpHKVmyrjM6C.pgp Description: PGP signature
Re: BitTorrent swarms have a deadly bite on broadband nets
In a message written on Mon, Oct 22, 2007 at 08:24:17PM -0500, Frank Bulk wrote: The reality is that copper-based internet access technologies: dial-up, DSL, and cable modems have made the design-based trade off that there is substantially more downstream than upstream. With North American DOCSIS-based cable modem deployments there is generally a 6 MHz wide band at 256 QAM while the upstream is only 3.2 MHz wide at 16 QAM (or even QPSK). Even BPON and GPON follow that same asymmetrical track. And the reality is that most residential internet access patterns reflect that (whether it's a cause or contributor, I'll let others debate that). Having now seen the cable issue described in technical detail over and over, I have a question. At the most recent Nanog several people talked about 100Mbps symmetric access in Japan for $40 US. This leads me to two questions: 1) Is that accurate? 2) What technology to the use to offer the service at that price point? 3) Is there any chance US providers could offer similar technologies at similar prices, or are there significant differences (regulation, distance etc) that prevent it from being viable? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp1RqRlIg8BG.pgp Description: PGP signature
The next broadband killer: advanced operating systems?
Windows Vista, and next week Mac OS X Leopard introduced a significant improvement to the TCP stack, Window Auto-Tuning. FreeBSD is committing TCP Socket Buffer Auto-Sizing in FreeBSD 7. I've also been told similar features are in the 2.6 Kernel used by several popular Linux distributions. Today a large number of consumer / web server combinations are limited to a 32k window size, which on a 60ms link across the country limits the speed of a single TCP connection to 533kbytes/sec, or 4.2Mbits/sec. Users with 6 and 8 MBps broadband connections can't even fill their pipe on a software download. With these improvements in both clients and servers soon these systems may auto-tune to fill 100Mbps (or larger) pipes. Related to our current discussion of bittorrent clients as much as they are unfair by trying to use the entire pipe, will these auto-tuning improvements create the same situation? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgphJlpgm86OO.pgp Description: PGP signature
Why do we use facilities with EPO's?
I was complaining to some of the power designers during the building of a major facility that the EPO button represented a single point of failure, and effectively made all of the redundancy built into the power system useless. After all, what's the point of having two (or more) of anything, if there's one button somewhere that turns it all off? What I found interesting is that a single EPO is not a hard and fast rule. They walked me through a twisty maze of the national electric code, the national fire code, and local regulations. Through that journey, they left me with a rather interesting tidbit. The more urban an area the more likely it is to have strict fire codes. Typically these codes require a single EPO for the entire structure, there's no way to compartmentalize to rooms or subsystems. However in more rural areas this is often not so, and they had in fact built data centers to code WITHOUT a single building EPO in several locations. That's to say there was no EPO, but that it may only affect a single room, or even a single device. If they can be avoided, why do we put up with them? Do we really want our colo in downtown San Francisco bad enough to take the risk of having a single point of failure? How can we, as engineers, ask questions about how many generators, how much fuel, and yet take for granted that there is one button on the wall that makes it all turn off? Is it simply that having colo in the middle of the city is so convenient that it overrides the increased cost and the reduced redundancy that are necessitated by that location? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpLvtSetOd1U.pgp Description: PGP signature
Re: TransAtlantic Cable Break
In a message written on Fri, Jun 22, 2007 at 11:56:32AM -0400, Sean Donelan wrote: Is paying for protected circuits actually worth it. Or are you better off just buying two circuits and using both during normal conditions. Use switching at layer 3 to the remaining circuit during abnormal conditions. Most of the time, you get twice the capacity for only twice the price instead of a protected circuit where you only get the once the capacity for twice the price. Sorry, it doesn't work like that. I do happen to believe rather than get a single SONET/WDM protected 10G Wave you are better off getting two unprotected 10G waves and plugging them into your devices, and let layer 3 routing take over. It generally saves a good bit of cost, and it helps you keep the cable system honest. You know when there is an outage, no way to hide it from you. However, if you put 15G down your 20G path, you have no redundancy. In a cut, dropping 5G on the floor, causing 33% packet loss is not up, it might as well be down. If your redundancy solution is at Layer 3, you have to have the policies in place that you don't run much over 10G across your dual 10G links or you're back to effectively giving up all redundancy. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpjj9hZefNgy.pgp Description: PGP signature
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
In a message written on Mon, Apr 16, 2007 at 03:42:53PM -0700, David W. Hankins wrote: Both of these two progression trees represent the cumulative formulation of knowledge: Users are stupid. Automatic is not just best, it's the only way. [snip] The main point, is that if you leave all other host configuration details up to, well, the host itself, then in practice what you're really doing is leaving it up to the user. Ultimately, it is mandatory that the end-user make a choice in this model, if not about everything, then about some things. This is intolerable in an ISP environment. I agree 100% with your points, however I believe you have a minor marketing problem that might change how many people receive your comments. It's not that users are stupid, necessarily. They may be of course, but they are also lazy, impatient, and intolerant of things that do not work. As someone who can type conf t and use ed to configure their Unix box _I_ won't tolerate manually configuring my home laptop just so I can surf over to weather.com and find out if it's going to rain. While I may do all the testing and work-arounds to make it work for my job, I'll turn it off at home until it just works and is available via my standard provider. It's 2007, not 1987. If I can't take a brand new box out of the packing material, plug it into an ethernet port and have it just work then something is broken. The network, the OS, the protocol, take your pick, but it's broken and not deployable. [Note: How wise it is to put a brand new box on the net is a different question, the point is it should just work.] -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpRPuqE2lfHa.pgp Description: PGP signature
Re: The Chicken or the Egg.
In a message written on Tue, Mar 13, 2007 at 01:03:17PM -0400, list account wrote: 90 to 120 days. The first 6 locations complete over the next 2 to 6 weeks and the vendor that handle the hospitality networks want their addresses now. The road block has been that ARIN wants us to get the Perhaps you could work with them to understand why they need to know their addresses 6 weeks out. That seems rather silly. In my limited experience ARIN seems to not want to work with the small operator. Maybe I got someone on a bad day or maybe I am using the It's not that ARIN doesn't want to work with small operators, but rather if ARIN had a nickle for everyone who came to them saying I'm going to use a /16 in three weeks, really, I promise it would be a trillion dollar enterprise, and we would have burned through all the address space 10 years ago. Not that it helps you much, but ARIN's policies are 100% created by the public. You can submit a policy change, and/or attend a meeting in an effort to change the policy. More information is at http://www.arin.net/policy/index.html. The bar is high, but your best chance may be 4.2.1.6 (http://www.arin.net/policy/nrpm.html#four216), Immediate Need. This policy is unfortunately vague, and in fact there are two policy proposals for the next meeting that make it more clear: http://www.arin.net/policy/proposals/2007_9.html http://www.arin.net/policy/proposals/2007_10.html Note that those are not policy yet, but both are being proposed because of ARIN's staff concerns about how the rubber hits the road, so to speak. I suggest you call and talk to a rep on the phone. Explain your situation. I have no doubt they will want to see supporting documentation (e.g. contracts, network maps) but I believe you have a chance at getting addresses 30 days out (or so) if everything looks good. If I'm completely off base (which is always possible) I'm sure the rep can tell you the shortest path between you and more IP addresses. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpGRlRv1BwRB.pgp Description: PGP signature
Re: Wikipedia/Cogent
In a message written on Fri, Aug 18, 2006 at 03:02:45PM -0400, Richard A Steenbergen wrote: So, lets kick this Friday off right... I don't suppose anybody has noticed that Wikipedia is being blackholed by Cogent, and that it seems to be intentional? :) Maybe they don't like: http://en.wikipedia.org/wiki/Cogent_Communications -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp4h9GI95riM.pgp Description: PGP signature
Re: [Latest draft of Internet regulation bill]
In a message written on Sat, Nov 12, 2005 at 11:07:48PM -0500, Sean Donelan wrote: Verizon is calling their offering Broadband access. Cablevision calls their offering Optimum Online. Are those the same as Internet access? Depends on what they promise. For instance, if I go to Cable Vision's web site and click on optimum online I get http://www.cablevision.com/index.jhtml?pageType=ool_product, and I quote from the first paragraph: ] Cablevision's Optimum Online, the industry's first self-install, ] blazingly fast Internet access cable-modem service is revolutionizing ] the way people in the tri-state area view and use the Internet. Indeed, they call it Internet access in the first sentence. Sure looks to me like that is what they are selling. FWIW, Broadband Access is the name of Verizon's wireless product, not sure if that's what you intended or not. It's Verizon Online DSL for the wireline verison. The home page is at http://www.verizonwireless.com/b2c/mobileoptions/broadband/index.jsp, and again I quote (from service overview): ] You can finally access the Internet while in the airport, at the ] worksite, or even in a taxi with the freedom of the largest high-speed ] wireless network in the U.S. access the Internet, could it be more clear? I see the end result of your proposal is providers would come up with lots of different private label brand names for their services, because no one has been able to define with legal certaintity what the Internet is or isn't. You're being too literal. It's not just the service name. If I call it Leo's IP Service it doesn't have Internet anywhere in the name, and that's necessary but not sufficient. If in the description of the service I call it Internet Access, as both providers above did, then that is what they are selling. If you don't want people to think it's Internet access, you can't use Internet /anywhere/ in the description of the product. Bottom line, its called legal uncertainty. If no one is able to define what the Internet is or isn't, will the lawyers simply prohibit the use of the word Internet and do a global search and replace with a different term? Do you think a more likely outcome is the marketing departments will just invent new brand names for stuff? The companies will go on and sell whatever they decide to sell using the new name, while the term Internet becomes a historical footnote like ARPANET and NSFNET. No, because consumers will demand Internet Access. Have we already forgot the Level 3 and Cogent issue. If the rumor mill is right the way it was resolved was Level 3's customers got their lawyers and said you sold me x, and switched it to y, and you have to provide notice before you do that. Essentially an extension of bait and switch. I pitty the first cable company or DSL provider that doesn't offer the whole internet. I suspect their market share will erode to their competitors rather quickly. Have you tried to buy an HDTV recently? Would that really be an improvement? I think HDTV hardware is quite clear. I love my HDTV. But once again, it's the service providers who are the problem. My provider (who I will let be nameless for now) doesn't keep any cable cards locally, and has to send off to the national HDTV center to get one. They lock down their set top box to a single resolution, which is not the resolution of my TV, nor the resolution of the local broadcasters. They don't carry anything but the three local networks in HD. They are also losing my business as we type to another provider who offers a better service. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpZMDMWSKGco.pgp Description: PGP signature
Re: [Latest draft of Internet regulation bill]
In a message written on Sat, Nov 12, 2005 at 01:32:39PM -0500, Sean Donelan wrote: So its just marketing. Some cable companies charge you $5 a month more for HSIA if you don't buy the cable company's VOIP service and $10 more if you don't buy the cable company's video service. As long as they use a brand name for the $15 discount package, they can have whatever restrictions they chose on the discounted packages? Could they call it Internet++ or Platinum service and it would be fine? No, this is all pricing. You can sell Internet Access for $10, or $20, or $200 for all I care. It's still Internet Access. You can discount my Internet Access by 50% if I also buy a hotdog from you for all I care. Doesn't change what you're selling. You can sell me faster or slower Internet access, companies never seem to be shy about telling you the speeds, doesn't change the fact that it's internet access, and the customer is informed about what they are buying. Is there some licensing body that surveys 99 out of 100 people to decide if something is the whole internet? That licensing body would then have the power to order ISPs to carry just those web sites? If 99 out of 100 people only access the top 20 or so web sites, is that the whole Internet for them, because they think the web is the Internet? Would this be must carry for broadcast television stations that must be carried for free by cable systems? Would the FCC maintain a list of web sites that that 99 out of 100 people use that all licensed ISPs must carry on their networks? Would that then give the FCC the power to decide what web sites ISPs don't carry? Whoa, you went entirely the wrong direction, and used entirely the wrong analogy. This is not congruent to channels on a cable TV system. I don't think anyone has ever tried to sell cable tv access that magically gets the set of cable TV channels. There is no such common definition. The cable TV analogy would be selling me NBC, but not showing The Apprentice, SNL, and the West Wing because the producers refused to pay the cable company for access. If you chop it up, it's no longer NBC but select NBC shows. The better analogy is to the phone company selling Long Distance. If MCI sold Long Distance, but you couldn't call anyone on Sprint's network because Sprint didn't pay the access feee then it wouldn't be Long Distance. The sad thing is, these are not things with a precise definition. You can invision defining Long Distance before there were cell phones, and it might not have included them. Of course, I think if you stop anyone on the street and ask if they can call a cell phone using their long distance service they would stare at you blankly with a of course, why wouldn't you kind of response. Rather, these things are solved by the FCC and/or the courts. Someone tries to sell Internet Access which is missing part of what many people believe is the Internet, and out come an army of lawyers to sue sue sue. Think a class action lawyer wouldn't love to sue SBC on behalf of all SBC customers that SBC sold them one thing and delivered another? They would jump all over it. In the end you ask who makes the call, 12 jurors, that's who. Do they believe it was internet access or not? Which is why, in the end, this is a slippery slope that business should stay away from. You don't want to push the envelope becuase the one who does won't know until it's too late (the lawsuit is filed and/or decided) and once you do know you're probably so far in the red from the lawsuit it wasn't worth the savings or extra revenue you thought you were getting from short changing the customer. Bottom line. Selling internet access where you can't get to the whole internet (which no one of us can define, sorry) is deceptive advertising. Bait and switch. There's a litany of case law on the subject from many industries. If you're company is anywhere near such a cliff, run, quickly, to the nearest exit. It will be bad when they get it wrong. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpO3JjeFxaxr.pgp Description: PGP signature
Re: [Latest draft of Internet regulation bill]
In a message written on Fri, Nov 11, 2005 at 05:26:59PM -0500, Sean Donelan wrote: MCI Friends Family charged different rates for phone calls depending [snip] rate? Level 3 charges different rates for on-net versus off-net It's not that any of these are bad, but it's that the consumer must be informed what they are getting. They all have nice product names that are specific to a particular company. That is, MCI can't offer Free Long Distance, and then hide in the small print only to MCI customers, $200/minute to everyone else, but they can offer a Friends and Family Plan with free calls to MCI customers. It's deceptive advertising. Move to the Internet space. A consumer provider can't offer Internet Access and have the small print say but only to content providers who also pay us. However, it's perfectly ok to sell access to the Compuserve network and detail that it gets you access to all of their partnered content providers. So really the question is not a technical one, or even a business model one. It's a question of marketing. Don't sell Internet Access if you can't access the whole internet for what 99 out of 100 people define as the whole internet. If you want to sell some more limited service, fine, give it a new name because it's not Internet Access. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpqDMuJvmVsZ.pgp Description: PGP signature
Re: multi homing pressure
In a message written on Wed, Oct 19, 2005 at 11:31:32AM -0400, Jared Mauch wrote: it will be interesting to see if this has acutal impact on ASN allocation rates globally. I have done no analysis, but I do believe this is having an effect on the number of prefixes announced by many of the players involved. Looking at the top 10-20 peers over here, all of them show prefixes announced by the peers to be growing faster than the global prefix table. The only way that makes sense is if existing prefixes are being announced through additional providers. It would be interesting to see those more into BGP routing analysis to look at that (possible) trend. It's probably causing a shift in how BGP processing occures on both a device and a network level (more redundant paths) which could have implications for future gear. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpNw9b16ZBtr.pgp Description: PGP signature
Re: Cogent/Level 3 depeering
In a message written on Fri, Oct 07, 2005 at 10:40:50AM -0400, Lamar Owen wrote: Yes, you would be correct. Which offers an interesting thought: why would it be important for you then but not now? If the issue impacts your customers, then why not spend the 3 minutes reconfiguring your router(s)? (obviously, if it doesn't impact your customers, then ignore that). I venture any other ISP of importance either has direct connectivity to Cogent and Level 3, and/or buys transit from someone who does. All but the smallest most trivial ISP's are multi-homed. Those that are have seen no result from this, by and large. I can all my customers can get to both. In other words, this problem is a problem simply because people can't be bothered to fix the problem because it's just a customer service issue, and not 'helping out fellow backbone providers?' Shades of the old backbone cabal here. (yes, a healthy dose of cynicism there) No, it doesn't affect anyone else's customers. Period. Fixing it in this case would be offering Charity to Level 3 and Cogent, and offering your competitors Charity, particularly for their own mistake is not high on most business plans. There's a very large difference between offering charity to a competitor, and keeping the industry going in the face of disaster. To suggest the two are related at all is just absurd. If someone wants to cut their network off from someone else for a business reason they will be able to do that whatever the design of the network may be. Level 3 and Cogent are both actively causing this outage. It's not some grand design failure. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Did we forget that ISP's are businesses?
As Randy pointed out, this conversation has been fairly clue free. Working as a peering coordinator for a large ISP I can tell you that most of the posts in this thread have been so wrong it makes me laugh. ISP's are businesses, and let me tell you that peering is no exception. People seem to like to think that settlement free interconnections are free, but nothing could be further from the truth. You have to buy routers and the cards that go in them, provision transport services to the peering location, and then on to the peer. Provide enough backhaul in your network from where your customers are located to where the peers are located. You have to pay lawyers to review contracts, engineers to configure and troubleshoot sessions, and managers to negotiate the whole deal. The budget for settlement free interconnections at a major ISP can run into the millions of dollars. Two major ISP's may have 8xOC-48 between them. That's probably $200,000 in router costs alone. Yes, sometimes you can get a $200 cross connect, but sometimes you also have to have the $6k/month circuit, for each one, creating a $42,000/month cost. That's a half million dollars a year. When you look at the requirements, geographic diversity, volume, ratio, number of routes what is really happening is the companies are trying to make sure there is some balance of costs. It doesn't have to be a 50/50 split...everyone uses their own assets to reduce their costs, but there has to be some equality. Personally, I'm not a fan of the technical requirements to make them equal, but rather like to negotiate equality, but everyone has their own approach. Back to the issue at hand. What I can tell from this situation is that Level 3 thought they were paying a lot of costs for very little return on investment. The idea that Level 3 would take this action because Cogent was selling cheaper seems a bit far fetched to me. Level 3 knows this is going to hurt their customers as well. Indeed, I'll bet this went all the way to the Level 3 CEO for approval first, because they knew their was going to be pain. This isn't some router cowboy going nuts in the middle of the night, this is a business backed into a corner. Why? We'll never know the real story. Maybe L3 is paying for third party circuits because cogent doesn't touch their network and it's costing them a boatload. Maybe L3 wanted to move to GigE peering for cheap high density ports, and Cogent wouldn't budge from using OC-3's because their routers don't have great GigE density. Maybe traffic between the two has dropped to 20 megs, and so L3 doesn't think maintaining ports is a justified cost. Maybe the ratio is 20:1, and that was finally enough for L3 to feel they were carrying too much of the transport cost. Most likely it's a combination of all of these issues. Bottom line is some engineer had to dress up and go over to the land of suits and explain to them that yes, Level 3 was going to totally screw their own customers, but it was also going to save $X, where $X is probably fairly large, and so they really had no choice. Least I seem like I'm on Level 3's side, it may well be that they have high costs due to their own stupidity. Perhaps they cut a deal with Equinix for $5,000/month cross connects. Perhaps they pay list price for their routers. Perhaps they are about to go down the tubes. As for those who want to re-architect the Internet to fix this problem, please go away. It's not a technical problem. It's a business problem. Two companies, each responsible for their own bottom line couldn't find an economically feesable way to interconnect. Any attempt to force the interconnection (either via regulation, transit through third parties, etc) will RAISE prices for all involved. The key here is that the peering was not economically viable for some reason. It will be interesting to see how this is resolved in the end. As time passes, there will be increased pressure on both companies to fix this problem. Single homed customers are going to think twice about connecting to either one. My own observations? This appears to be happening to Cogent a lot lately. This makes me wonder if part of the reason they have been able to offer lower costs is by finding ways to take advantage of peers and transfer costs to them which is causing the peers to notice and take action. I also find Cogent's practice of offering Level 3 customers free service unseemly. They are partially responsible for the outage, and are trying to use that fact to lure customers. That makes me wonder if they've written off Level 3 entirely already...after all if you're planning on working out a deal with someone you don't rub salt in their wounds as a first step. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpZ84QoTs9DV.pgp Description: PGP signature
Re: Cogent/Level 3 depeering
In a message written on Thu, Oct 06, 2005 at 06:36:00PM -0400, Lamar Owen wrote: All philosophy aside, it does bother me that a simple single depeering can cause such an uproar in a network supposedly immune to nuclear war (even though the Internet was not designed from the start to survive nuclear war; Paul Baran's packet-switching work aside; reference 'Where Wizards Stay Up Late' which quotes Taylor and others on the origins of the ARPAnet portion of the old Internet). I shudder to think of what would happen if there were to be a real problem (I mean, really, one link (out of many thousands) is down and the Sky Is Falling!). What happened to resiliency? I've seen a lot of comments about the disruption caused by this depeering event, and what would happen if $bad_thing happened. I point you back a few weeks to when the hurricane hit. You need look no further to see people offering up their assistance to those in need. Look back further to 9-11, and people offering networking help to those who's infrastructure was damaged. I have no doubt that if the Level 3 / Cogent issue had been caused by a pre-emptive nuclear strike and the nation was called to arms that virtually every ISP that connects to both would be offering them free transit to get them reconnected. Indeed, I could log into my routers now and fix the Cogent / Level 3 problem with about 3 minutes of typing. It would cost my company thousands of dollars to do so, so I'm not going to do it. As I said before, right now this is a business problem. By the same token, if we were just attacked and Level 3 and Cogent were both, together, asking for help I'd log in and have them working as fast as I could type. I bet others would as well. Level 3 and Cogent are able to fix their own problems in this case, either by making up, or by entering into a business relationship with a third party to fix it. This is also a problem that they, themselves created. That's the difference here. I've got a new set of rules to add to this thread: If you don't have enable on a router, and you've never negotiated peering with a transit free ISP then you're not qualified to comment. You really don't understand what's going on here, and it's not, I repeat, not a technical problem. There is nothing wrong with the technology, architecture, or anything else. There is something wrong with the business model of one, or both of these companies. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpYhJeDjKGD9.pgp Description: PGP signature
Re: IPv6 Address Planning
In a message written on Wed, Aug 10, 2005 at 03:55:32PM +0100, [EMAIL PROTECTED] wrote: The current recommendation for a /48 for any customer (pretty much) does initially seem to me to be a bit wasteful, though that's perhaps because I keep thinking in IPv4 terms. Having said that, I think that perhaps a /48 for home users isn't _really_ necessary. How many domestic appliances can you connect to the net :) That's not really the question you want to be asking. The current mantra is a /64 per subnet. Now, we can argue that point separately, but taking that as a given for now (so autoconfiguration will work) what a /48 is really telling you is that a home user gets 65536 subnets. IPv6 allocations in the host portion (with /64 boundaries) are sparce, even for the largest networks. The number of hosts becomes unimportant. The question we need to ask is how many independant subnets will they need. This is why many people are proposing a /56 for home users, as it gives you 256 subnets. Still more than most people will need. Others have proposed /52 and /60, since many want to claim DNS is easier if done in nibbles. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpKVSuTn3nLh.pgp Description: PGP signature
Re: IPv6 Address Planning
In a message written on Wed, Aug 10, 2005 at 01:51:41PM -0400, Daniel Senie wrote: Where is this being discussed? What sizing is being discussed? I'm expecting in the long run some ISPs will hand out /128s in the hope that this will once and for all keep customers from putting more than one device on a connection (of course that would be followed immediately by implementations of NATv6 if it happened). This is a topic of heated discussion at the various RIR meetings, ARIN for most people on this list. Note the next ARIN meeting is with a Nanog, so you might want to stick around (show up early?). In an attempt to be objective, I'll say that there is a line in the sand between the IETF and the RIR's, and right now both groups seem to think the other is stepping over the line, and making the wrong decisions. The IETF seems to think /48 is good, thinks it's extremely unlikely we'll ever run out of space, and considers that if we do in 50 years it's probably ok, time for a new protocol anyway. The RIR's seem to think smaller (/56? /64? /96?) prefixes are good, that we will run out of space under the current plan it's simply a question of when, that deploying a new protocol in 50 years is a bad idea if we can avoid it, and with sane policies we can. Add in operators and their various opinions of NAT, how many addresses a user should get, if auto configuration is good bad or ugly, if you still need DHCP with auto configuration and soforth and you have quite a mess with no group clearly leading in the polls. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp3VgWJ3KbYd.pgp Description: PGP signature
Re: Cisco IOS Exploit Cover Up
In a message written on Thu, Jul 28, 2005 at 08:29:22AM +0100, Neil J. McRae wrote: I couldn't disagree more. Cisco are trying to control the situation as best they can so that they can deploy the needed fixes before the $scriptkiddies start having their fun. Its no different to how any other vendor handles a exploit and I'm surprised to see network operators having such an attitude. This is not a Cisco specific comment, but it is a network operator comment. You change your mind when you get hit by a network wide bug taking out all your customers, and then spend six months beating up the gear in your own lab to reproduce the problem, and when you do the vendor finally admits well, we've known about the bug for 4 years, but we were pretty sure it couldn't happen in your network so we didn't tell you. I'm sure the vendors find bugs, quietly fix them, the code is naturally upgraded and nothing ever happens. Which is a good thing. The problem is, most of the major operators have been hit by a bug where the vendor knew, did nothing, or at least not enough, the operator was hit and then the vendor continued to not want to admit the problem because of course now they look even worse for sitting on it. For better or for worse, right now the only check and balance to the vendors is conferences like the Black Hat forum. For Cisco to send an army of razor blade toting employees to such a conference is chilling. I can see them working with the parties before hand, but to make that kind of show in public? What is the motovation? If this bug is, as Cisco puts it, not serious then they just spent a lot of money on people to go do all of that for nothing. Doesn't seem likely. So what everyone's spidy sense is now telling them is Cisco wouldn't spend thousands of dollars on legal injunctions and armys of razor blade toters for nothing, so there must be something to this paper. Which makes their denial all the more hollow. This isn't an endorsement of the pro-disclosure crowd. Telling these things to the world at large in a forum like this gives the script kiddies a leg up, as they are almost always faster than the vendors. These things should happen at a more measured pace, inside normal support channels. That said, no one likes a coverup. Once it's public in any form, don't try to sweep it under the rug. Doesn't work in politics, doesn't work for vendors. Sometimes you can get away with it once or twice, but in the end it costs credibility, which is something that is extremely hard and costly to earn back. If Cisco wanted to make me feel better right now they could contact my company via normal support channels and have a frank and open discussion about what this paper/presentation means, and what action if any they are taking as a result. Somehow for what the boxes and support costs that doesn't seem like too much to ask. The presentation is out there, we will get it and read it, don't pretend like we won't. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpAjo1MvyWoE.pgp Description: PGP signature
Re: Cisco IOS Exploit Cover Up
In a message written on Thu, Jul 28, 2005 at 10:14:42AM -0400, Scott Morris wrote: And yet, look how much havoc was created there. It's always the potential stuff that scares people more. While I do think it's obnoxious to try to censor someone, on the other hand if they have proprietary internal information somehow that they aren't supposed to have to begin with, I don't think it is in security's best interested to commit a crime in order to get tighter security. We don't have all the details, so I don't know what he's accused of doing which is illegal, however, from http://news.zdnet.co.uk/internet/security/0,39020375,39211011,00.htm I quote: ] The filing in US District Court for the Northern District of California ] asks the court to prevent Lynn and Black Hat from further disclosing ] proprietary information belonging to Cisco and ISS, said John Noh, a ] Cisco spokesman. ] ] It is our belief that the information that Lynn presented at Black Hat ] this morning is information that was illegally obtained and violated our ] intellectual-property rights, Noh added. ] ] Lynn decompiled Cisco's software for his research and by doing so ] violated the company's rights, Noh said. I am not a lawyer, and so under the current DMCA and other laws it may well be illegal to decompile code. That said, it sounds rather like the technical equivilant to Ralph Nader disassembling the Corvair to prove the suspension design was flawed. GM sure didn't like that any more than Cisco likes this incident. I don't know when we decided a program should be a black box welded shut kept from all prying eyes, and that anyone who could run a decompiler was instantly a crimimal. It probably all came about from the crazy decision that software should be licensed, not sold. We'd be in a world of hurt if anyone who figured out how to put a lift kit on his pickup was sued by ford for disassembling the truck and figuring out their propretary internal designs. Why is software special? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgppARrugzTIA.pgp Description: PGP signature
Re: Cisco and the tobacco industry
In a message written on Thu, Jul 28, 2005 at 04:51:18PM -0400, Geo. wrote: Cisco routers are being sold to every company who connects to the internet, it's one step up from consumer products. You can't expect every company who owns a cisco router to buy an expensive contract or be willing to go thru the gauntlet to get the patches. Cisco needs to come up with a better way. In a message written on Thu, Jul 28, 2005 at 08:29:38PM +, Christopher L. Morrow wrote: if it's critical to your business you'd think you'd have a support contract for it, eh? (or you decided that the 'better part of a week' and associated risk was an acceptable cost to your business) Unfortunately Chris, that doesn't match how (small) business works. I had to hold up Microsoft as an example of being a good corporate citizen, but here it goes. If a 10 person company buys Windows XP and runs it in their office they get free Windows Updates patches for the life of the product (typically around 5-7 years). There is no TAC or other system to go through, you just tell the box to update and it does it. Now, I'm not suggesting a large ISP would go with this model, but Cisco has moved out of the core and into small edge and SOHO routers, VOIP phones, and all sorts of other gizmos being bought by home office users and small companies who don't buy support for their other technology items, but get updates. Heck, even digital camera makers and such put free firmware updates on their web site. Expecting all of these users to buy a support contract that costs, what, $350/year for a $2500 box is absurd. Even full tilt talk to a real person with on-site service dell support is only around $120/year. There is a reason all of these boxes are running around unpatched. Look at the percentage of windows boxes, which have auto-update software, and free updates that are patched. Now think about the routers out there, where there is no update software, and no free updates. It should surprise no one that there are thousands of routers on the ends of T1's and DS-3's running code 2-6 years (or more) old, vulnerable to any number of things. Why is Cisco so scared of this one? Well, before now hacking them was low value. You could DDOS a 5 person company off the air, maybe reboot their router with a vulnerability -- which frankly many of them wouldn't notice. However, now they can be added to the zombie army of your choice. From being able to simply trigger a flood ping remotely to being able to upload a remote controllable module it's all possible now. Cisco knows a lot of these small offices don't have support. They don't have someone who knows how to upgrade code on a Cisco. For Cisco to actually upgrade a lot of these boxes (assuming people are informed, and know to demand an upgrade) under their current system means tens of thousands of tac calls from people who've never logged into a router before needing to be walked through downloading code and upgrading a router. Millions, if not tens of millions in support costs. Will all of these people demand it? Who knows. The popular press picking up the issue is a huge step to alerting joe random with a small office and a 2501 in the corner he should pay attention, but it's probably not enough. If a hacker manages to take over twenty or thirty thousand routers thoughI suspect a flood of calls Cisco's direction. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp9GBnQdiX4D.pgp Description: PGP signature
Re: PAIX Outages
In a message written on Thu, Apr 28, 2005 at 01:51:54PM -0400, Richard A Steenbergen wrote: Personally I tend to suspect the general lack of uproar is a rather unfortunate (for them) sign that PAIX is no longer relevant when it comes to critical backbone infrastructures. That, or a sign that operators are doing their job. There should be enough redundancy in the system that loss of any one site, for whatever reason, doesn't cause a major, or even minor disruption. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpLoBlj0pW01.pgp Description: PGP signature
Re: Paul Wilson and Geoff Huston of APNIC on IP address allocation ITU v/s ICANN etc
In a message written on Wed, Apr 20, 2005 at 07:41:52AM +0530, Suresh Ramasubramanian wrote: http://www.circleid.com/article/1045_0_1_0_C/ That's a must read article, I'd say. If you're interested in these issues I strongly encourage you to read and be involved in your local RIR and/or the IETF processes. Network engineers with hands on day to day experience tend to be underrepresented in both forums. For those of you in North America (after all, this is NANOG) check out ARIN's Public Policy Mailing List, information is on ARIN's web site. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgphwdNYfJc1V.pgp Description: PGP signature
Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]
In a message written on Tue, Mar 29, 2005 at 02:27:56PM -0600, John Dupuy wrote:
I was looking at it from a route announcement point of view. Transit is
where AS A advertises full routes to AS B. Thus, AS B is getting transit
from A. Peering is where A B only advertise their network and, possibly,
the networks that stub or purchase transit from them.
This is oversimplistic. Transit does not have to be full routes.
Don't confuse the business case with the technical configuration.
That is, all combinations of:
{paid,settlement free}-{customer routes only, full routes, no routes,
you leak mine, I leak yours}
exist. Some are more common than others. Sometimes multiple
combinations exist between the same two parties.
It is my understanding that the top ISPs trade transit. They provide full
routes to each other without payment, regardless of how or where the route
was learned from. They are willing to pass some traffic without
compensation because it makes for better connectivity. From an announcement
POV they are not peering.
The top of the food chain is a full mesh of customer routes only.
I have never seen anyone at the top of the food chain trade full
routing tables, something that would likely be obvious from time
to time in various outage scenarios. There is no business case to
provide free transit on that level. It would be too easily abused.
That's not limited to top ISP's either. Full tables are not done
on a peering level, ever. If anything wonky is being done it's
done with selective leaking of routes in one or both directions,
never ever ever with a full table.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp8b8FCskV7P.pgp
Description: PGP signature
Re: ULA and RIR cost-recovery
group needs to adopt a simple path for moving forward. #1 Set aside a block for local use a-la RFC1918. This set aside should make no recommendations about how the space is subdivided for used for these local purposes. #2 Drop the ULA nonsense. As currently crafted its destined to fail. #3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it. #4 Drop the absolutely stupid notion that one size fits all. A /32 for everyone makes no sense. VLSM was a good idea. #5 Stay out of the allocation details. The RIR's have been allocating addresses for years. The RIR's have people, from small to large ISP's and everything inbetween solving real world allocation problems every day. The history tells us is the policy will change over time. History also tells us being too liberal early on can never be fixed. The RIR's will change policy as time goes on to fit the changing IPv6 world. Let them deal with the policy on a going forward basis. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpG3Ac9pe63m.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
In a message written on Mon, Nov 29, 2004 at 09:09:08AM -0800, Owen DeLong wrote: I will point out, however, that if the boundary moves to /24, there's not much difference between the allocation policy of the past that created the swamp and current allocation policy. I'm not saying I think this is a bad thing (I don't). I think that CIDR was important in its day, and, I think it is important today. However, I think that now, CIDR is only important in so far as it promotes aggregation where it makes sense. Deaggregating where it matters is a valid and necessary thing. I think Owen is well aware of the differences, but for the list's archive... I think a major difference is that the current policy requires you to be multihomed. Another difference is that you have to pay a maintenance fee. There are a lot of blocks in the swamp where end sites received space because they could, and the lack of fees was a motivator. There are also a lot of blocks given out to entities that were then, and are now single homed. It's also the case that the industry as a whole has progressed. With ISP's having good processes to give the customers the space they need, and with technologies like DHCP and the like it is much easier for many end users to live with IP's from their upstream, even if they change once in a while. Couple that with a (very small) amount of paperwork and fees and you do cut out many of the frivolous uses. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpEox03tePp9.pgp Description: PGP signature
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
In a message written on Sat, Nov 27, 2004 at 06:25:52PM +0100, Iljitsch van Beijnum wrote: All I hear is how this company or that enterprise should qualify for PI space. What I don't hear is what's going to happen when the routing tables grow too large, or how to prevent this. I think just about anyone should qualify, but ONLY if there is some form of aggregation possible. PI in IPv6 without aggregation would be a bigger mistake than all other IPv6 mistakes so far. I find it interesting that no operators are screaming that there will be too many routes, but that all the IPv6 researchers are bringing forth this view. 8 years too late guys. We've figured out table management. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpoiI7os23h2.pgp Description: PGP signature
Re: Stupid Ipv6 question...
In a message written on Fri, Nov 19, 2004 at 05:15:26PM +0100, Lars Erik Gullerud wrote: While that would seem logical for most engineers, used to /30 or /31 ptp links in IPv4 (myself included), that does not in fact seem to be the way things are currently done in IPv6, unless something changed (again) while I wasn't paying attention... /64 is the minimum subnet size, even for ptp-links - there was even an RFC published relating to the use of /127's (or, should I say, the recommendation to don't to that), namely RFC3627 (aka Use of /127 Prefix Length Between Routers Considered Harmful). But, you can still get 65536 ptp links out of a single /48 of course. FWIW, my test networks have always been configured with /126's, and have never had an issue. With the exception of auto-configuration, I have yet to see any IPv6 gear that cares about prefix length. Configuring a /1 to a /128 seems to work just fine. If anyone knows of gear imposing narrower limits on what can be configured I'd be facinated to know about them. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpJ31XBBtYLr.pgp Description: PGP signature
Re: I want my own IPs
In a message written on Fri, Nov 12, 2004 at 10:35:38AM -0800, James Laszko wrote: You've basically got to have around 16 /24's utilized before ARIN will do anything for you. Once you're at this point, they'll give you a /20 to renumber everyone, but will reserve a contiguous /19 for you if you can justify that you'll use it within the next 3-6 months. Note, if you are multi-homed the prefix length is a /22. http://www.arin.net/policy/2002_3.html -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpGOOKTl23DX.pgp Description: PGP signature
Re: IPV6 renumbering painless?
In a message written on Thu, Nov 11, 2004 at 04:22:28PM +, [EMAIL PROTECTED] wrote: Correct me if I'm wrong, but doesn't IPv6 do away with the need to renumber when switching providers? So if RFC 2462 is right, and you use DNS outside your network and you update that DNS at the moment of switching providers, everything on your network automatically acquires new IPv6 globally routable addresses as soon as the gateway router is connected to the new provider. Seems to me that with a little bit of help from a Change providers tool, this would be virtually painless without the need to own or announce a small globally unique prefix. That is how it has been designed, however there are some practical problems with this system: - Until very recently DNS software did not support A6 records at all, and chain support for A6 records still seems to be a work in progress. - I presume the problem with using DNS to find your DNS servers is obvious, so you probably still need a mechanism (static config, DHCP) to push out nameserver addresses to all boxes at some point in the cut over. - This solution works only to update the interface IP address on a box, and does not address any of the other application configurations that might need to be updated, including but not limited to: - ACL's on the box or routers to allow/disallow the new network. - Network analysis tools to include the new network. - IGP or BGP configuration to include the new network. - Also note, if you are unable to have the two services overlap (eg, must disconnect from the first, and then hours, days, weeks) connect to the second you have the potential to lose access to all your boxes locally in the mean time with this system. The solution is some sort of site-local/1918/ula address overlay. It is the last point that leads to the most interesting problem. If you create a local overlay network to always maintain access to your local boxes, then is it actually easier to push out an additional IP address to every end box, and update your IGP, firewall rules, and other configs, or is it easier to run NAT at the edge to convert your local network to public IP's? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpO8g7Lfssrm.pgp Description: PGP signature
Re: Important IPv6 Policy Issue -- Your Input Requested
In a message written on Tue, Nov 09, 2004 at 08:55:51AM +0100, Jeroen Massar wrote: http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-00.txt That contains most of the answers to your questions ;) Not really. It explains to me what a group of people would like to see happen. Major vendors already have NAT for IPv6: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6_c/sa_natpt.htm Indeed, NAT is being pushed by some vendors as a migration tool from IPv4 to IPv6. I have to believe if the code can do IPv4-IPv6 NAT, then doing IPv6 NAT to IPv6 NAT would be trivial. While I would hope we move away from NAT with IPv6, I realize there are brain dead people today with internal policies that read All network segments must be protected by NAT. I know NAT != security. You know NAT != security. However, the vendors know they can charge these people for a box that does IPv6-IPv6 NAT, these people (in ignorance) want IPv6-IPv6 NAT. Therefor it will exist, and people will use it. So, while you can talk until you're blue in the face about why it may not be needed, good planning dictates you have to realize it will exist, and as such consider what the impact will be on the network. Good product design means designing for people who do stupid stuff with your product, to a certain degree. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpfLLiqZ4CF1.pgp Description: PGP signature
Re: Important IPv6 Policy Issue -- Your Input Requested
: - Permanent with no periodic fees. So yes, everyone will be able to afford it. There is not a competition angle here. There is a huge question of how you're going to run a registry with no funding though. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Important IPv6 Policy Issue -- Your Input Requested
In a message written on Tue, Nov 09, 2004 at 11:51:10AM +0200, Hank Nussbacher wrote: Perhaps Nokia wants to make cellphones with a fixed IPv6 number - as it leaves the factory? -Hank It was relayed to me that at least one group was asking about using IPv6 addresses to replace UPC codes, since they are running out of UPC codes. I believe they were told that would be inappropriate. However, if you can get addresses for free, and they are guaranteed to be globally unique, and not to appear on the public internet I'm not sure what the barrier to such an application would be -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Important IPv6 Policy Issue -- Your Input Requested
In a message written on Tue, Nov 09, 2004 at 11:46:49PM +0100, Iljitsch van Beijnum wrote: However, there is plenty of address space in IPv6 to go NATless, so protocol desingers and implementers are unlikey to add NAT workarounds for IPv6. This means it's very unlikely that applications that don't use simple client/server communication are going to work with NAT in IPv6. As long as IPv4 exists, which I predict will be a long time, the protocol designers which are really application developers for your purposes, will write to the lowest common denominator. API's for all the major platforms already look like this; you open a TCP socket to an end address, be it IPv4 or IPv6 in a dual stack machine. So with the protocols still designed to work over IPv4 NAT, and the complexity of IPv6 NAT being roughly s/long/long long/g (yes, simplified, but you get my point) and recompiling your NAT code, I'm not sure what will be the barrier to IPv6 NAT. I would love to see a solid technical reason why IPv6 NAT will NOT work. In the absense of that I will stick to my guns and say that it will work and be available, and most likely sooner rather than later. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpI8tsAOOC3H.pgp Description: PGP signature
Important IPv6 Policy Issue -- Your Input Requested
I would like to bring to the attention of Nanog an IPv6 policy issue that I think is slipping under the radar right now. The IETF IPv6 working group is considering two proposals right now for IPv6 private networks. Think RFC-1918 type space, but redefined for the IPv6 world. Those two drafts can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt These drafts came up in the ARIN meeting, and I posted my analysis of the problems with both at: http://www.arin.net/mailing_lists/ppml/2849.html I will post a very brief summary of my objections, for the first (unique-local): - I believe the math is wrong on the rate of collisions, primarily because it assumes in a large organization there is a central coordination function to pick and distribute these addresses. However, since the whole point of unique local addresses is that there need be no coordination, I can easily see a case where a large conglomerate (Ford, GE, whatever) coming together with another will have both sides bringing hundreds, if not thoundsands of prefixes to the table as each division or other subgroup picks their own. - I think the likelyhood people will use the suggested hash methods to pick addresses is extremely low. People will either pick human friendly (1, 2, 3, 4, etc) or treat the space more like CIDR (where there is central delegation), both of which move the likelyhood of collision to near 1. In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today. The second proposal (ula-central) is much more dangerous. - It is not good engineering to give something away for free with no method of recovery, even if that resource is plentiful. - The IETF should not be creating a new worldwide RIR. - The IETF should not be dictating fees (free). (more to the point, a worldwide RIR, with the language and other issues will be expensive, yet it has no method of income) - Since this is a free method of globally unique space it has a high likelyhood of being routed on portions of the public internet. Indeed, this problem was quickly dismissed by the authors (see http://www1.ietf.org/mail-archive/web/ipv6/current/msg03848.html), who completely missed the boat. It's not the rich who would demand their prefix be routed, but the poor. We already have situations where parts of Africa and Asia claim the fees for IP space are too high. If they had access to free global space they would jump on it, and later if the rest of the world wanted to contact that region they would almost certainly have to route it as well. - The ownership should be private, yet the reason for a registry is to verify ownership and prevent hoarding. I'm not sure how those are combatable. - I think the IPv6 groups continue in their fantasy that people will manage multiple, complete overlay networks to fix numbering issues. More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet. Since this is a list of providers, I encourage you to read the drafts, and submit your comments to the working group. The information for the working group is at http://www.ietf.org/html.charters/ipv6-charter.html, and includes their mailing list archives and information on how to subscribe and/or post. Even if you disagree with me, much like voting the important thing is that you voice your opinion. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpxra1uPC1XO.pgp Description: PGP signature
Re: Important IPv6 Policy Issue -- Your Input Requested
In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote: Just out of interest, why do you think 1918-style space for v6 is needed? I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6. Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6. However, both of these proposals go well beyond how 1918 space works today, and both make promises of global uniqueness that are at best inappropriate, at worst a road to disaster. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp3IhQIqfPjN.pgp Description: PGP signature
Re: Important IPv6 Policy Issue -- Your Input Requested
In a message written on Mon, Nov 08, 2004 at 03:08:13PM -0500, Joe Abley wrote: I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.) By applications I did not mean software programs but rather methods of designing networks. I know of lots of networks that use RFC1918 addresses because of a (perceived, whatever) scarcity of IPv4 addresses, but presumably that argument doesn't necessarily follow for v6 networks, where ever customer site gets a /48. A company may change providers often and want to use 1918 style space to not have to renumber part of the network, or may choose IPv6 NAT as superior to overlay networks. Indeed, I suspect overlay networks are going to be hugely unpopular. This sounds like a direct path to IPv6 NAT. While I do not encourage IPv6 NAT, anyone who thinks IPv6 will put the NAT Genie back in the bottle is smoking some serious crack. Lots of people like NAT for lots of reasons, and I am 100% positive there will be IPv6 NAT used by a lot of people. One obvious use if these proposals pass is to use your non-routable global unique prefix internally and NAT at the borders. Since a lot of people think this is effective security, I think it will be a common configuration. Perhaps the non-availability of RFC1918 addresses would provide a useful incentive for future v6 network architects to install globally-unique addresses on all hosts? Perhaps I am the only one that thinks that would be a good thing ;-) Many people share your opinion, and I think it is a good one to voice. That said at the end of the day most engineers are going to treat IPv6 as IPv4 with bigger addresses. I know most of the IPv6 proponents just wrote me off as a loon by saying that, but I do believe it's reality and you need look no further than the existing test networks to see that it's the case. People who have become used to CIDR, and NAT and such aren't going to forget those idea's because someone told them rigid boundaries are good and you don't need private space anymore. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Important IPv6 Policy Issue -- Your Input Requested
organization is an ISP, please don't allow them on the Internet. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpIMWJAZgOxZ.pgp Description: PGP signature
Re: APNIC Privacy of customer assignment records - implementation update
In a message written on Thu, Sep 23, 2004 at 05:56:42PM -0400, Joe Abley wrote: The proposal (which comes from APNIC members, not from APNIC staff) concerns non-portable addresses assigned to end-users. I don't know about anybody else, but I've never had any luck getting a response from people in that category anyway; it's invariably the upstream ISPs who respond (if anybody does), and there is no suggestion that their contact details will be able to be hidden. There are several proposals in various stages before ARIN and RIPE about this same issue. APNIC simply beat everyone to the punch, but most of the other groups are going down the same path. The interesting case brought by several providers is that some residential DSL providers are now assigning /29's to end users to support multiple boxes. In some cases these additional boxes are service provider boxes to provide value-add services (think, a voice or video gateway box). This creates the very real situation where grandma is now published in whois. grandma doesn't like the spam, doesn't want to be listed (she already has an unlisted phone number) and even if her machine is owned and spewing forth spam contacting her is just going to result in confusion. To that end the service provider would like to not list her, protect her privacy, and when people query have only their block and contact show up so they can field the call and either block her port, or have a (hopefully more helpful) customer service person help her clean her infected machine or whatever. Generally the people who actually work abuse all have a similar report: end user assignments in whois are worthless. End users fall into one of two catagories: 1) grandma, where contacting her is going to get you nowhere because they don't know what you're talking about. 2) An abuser (spammer, ddoser, whatever). These people either won't respond, or will respond but take no action, in both cases hoping to string you along and make you either go away, or at least buy some more time while they tie you up dealing with them. Because of this most of the people dealing with abuse are already ignoring end user contact information and going straight to the upstream ISP anyway. This brings us to why these proposals are getting traction in all the RIR's. Spending thousands of hours maintaining data that many (most? nearly all?) of the users say is useless is silly. Indeed, this is the same thing many of the people who have alredy responded to this thread have said, only turned on it's head. I treat all APNIC data as worthless easily translates into APNIC shouldn't keep the data when you're one of the people paying the costs to upkeep the data. Chicken and egg, or egg and chicken? I'm not really sure. That said, the current rules basically ensure that at some point in the future, when everyone needs a /29, everyone on the planet will be listed in whois. That to me is the truely absurd part. I don't understand people who think every DSL, and every cable modem user should be listed in whois /purely by the fact that they have a couple of static IP addresses/. I can't imagine how that makes anything better for anyone. Many people will automatically tie this into another issue, but it is a separate issue. Upstreams, or more importantly LIR's (in registry speak) need to have valid contact information and need to act on complaints. I'm not quite sure how we enforce those requirements. However, the lack of being able to enforce those requirements does not make listing everyone any better of a solution. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpx6vVNt3du2.pgp Description: PGP signature
Re: DS-3 extended demarc photos
In a message written on Fri, Jul 30, 2004 at 09:02:38AM -0700, Michel Py wrote: - The equipment can't be powered by the span (power-over-fiber, anyone?). The phone company does not trust anyone for power and even though the entire room is on UPS and the customer also has a huge diesel generator, they bring batteries. Note that like most telco gear everything runs on redundant 48VDC power. With Verizon I know you can have them use your -48VDC power. This requires them to come out and inspect your power plant, and for you to sign a couple of legal forms that amount to we have no liability if the power fails. MFS has used building power on several occasions with just an inspection of the site. Of course, this requires you to have -48VDC with batteries. If all you have is AC, no matter how redundant, or DC with is fed directly from rectifiers (no batteries on the -48VDC side) they will probably still insist on batteries in their own rack. So, it's not quite a does not trust anyone, but for practical matters in non-(telco)datacenter buildings that is true. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpTv7FSbbfU2.pgp Description: PGP signature
Re: concern over public peering points [WAS: Peering point speed publicly available?]
In a message written on Tue, Jul 06, 2004 at 04:32:14AM +, vijay gill wrote: Paul, I think you took a left at the pass and went down the wrong road here. I am not saying ethernet doesn't scale or even vni/pni doesn't scale, but the mentality embodied in the approach throw it over the wall doesn't bode well if you are to scale. Throw it over the wall can be interpreted many ways. Everyone running their cable wherever they want with no controls, and abandoning it all in place makes a huge mess, and is one way to think about it. However, there are lots of telco MMR's, with either rows of racks or cages where every party runs their own fiber. Typically trays are provided in the colo cost, and the parties run the fiber in the trays and use the fiber management, label their jumpers, and more often than not pull out unused cables. If cages are involved dropping the cable over the cage is a common practice. Walking into these facilities you find they are generally neat and organized. I believe the problem Vijay is referencing isn't throw it over the wall, but rather where people have to hide the fact that they are throwing it over the wall. When some colo providers want to do things like charge a 0-mile local loop for a fiber across the room people think it's too much, and run their own over the wall fiber. However since it's technically not allowed it's hidden, unlabeled, abandoned when unused, and creates a huge mess. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp5FS9twMz0r.pgp Description: PGP signature
Re: ultradns reachability
In a message written on Fri, Jul 02, 2004 at 05:55:13PM -0700, Matt Ghali wrote: DNS traffic, surprisingly, is not very fat. It is no HTTP nor SMTP. The engineering behind appropriately sizing a unicast fallback would be pretty trivial, especially compared to building a somewhat-robust anycast architecture. This statement may be true for many DNS servers, but I suspect it is completely false for the roots, or for the GTLD's. Perhaps the folks from .org or from f-root would like to comment on how hard it would be to handle the whole load from a single box, particularly when you consider they are all high profile DDoS targets as well. If it were trivial, more GTLD's would be doing it. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpIUv2wbknuR.pgp Description: PGP signature
Re: ultradns reachability
In a message written on Fri, Jul 02, 2004 at 10:22:09AM -0400, Joe Abley wrote: This leaves the anycast servers providing all the optimisation that they are good for (local nameserver in toplogically distant networks; distributed DDoS traffic sink; reduced transaction RTT) and provides a fall-back in case of effective reachability problems for the anycast nameservers. This is so trivial, I continue to be amazed that PIR hasn't done it. I talked to Rodney about this a long time ago, as well as a few other people. What in practice seems simple is complicated by some of the software that is out there. See: http://www.nanog.org/mtg-0310/pdf/wessels.pdf Note in the later pages what happens to particular servers under packet loss. They all start to show an affinity for a subset of the servers. It's been said that by putting some non-anycasted servers in with the anycasted servers what can happen is if the anycast has issues many things will latch on to the non-anycasted servers and not go back even when the anycast is fixed. How serious this is for something like .org I have no idea, but it's clear all the software has issues, and until they are fixed I don't think this is just a slam dunk. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpl7qJSgADVu.pgp Description: PGP signature
Re: what's going on with yahoo and gmail lately?
In a message written on Mon, Jun 21, 2004 at 11:33:59AM -0400, Randy Bush wrote: it is easy to generate a lot of bytes. it is hard to generate content. this list is a rekknown example. Content is in the eye of the viewer. While you may have no use for a spiffy new camera phone, and e-mailing video clips to each other a teenager might value having an e-mail account not provided by their parents where friends can send all the video clips they want without running out of disk space. Just because you use a text e-mail client and don't like your e-mail HTML formatted with 250kb JPEG's as signatures doesn't make you part of the majority (at least, of e-mail users). Sadly, far too many people want to send an HTML formatted message, with embedded company logos and graphical signatures attaching videos, or various Microsoft Office formatted documents (if you want to give it a business spin). To the users, that is all content. To you it is likely bloat. I know many corporate e-mail users (eg, account execs, sending flashy proposals) who would blow through a gigabyte of e-mail in under a month. While I never want such trash to appear in my e-mail box, as a provider of network services I take great pleasure that people want to do that to their e-mail, because in the end it is more bits moving across my network. If google helps people send bigger e-mails, with more attachments and more graphics and so on good for them! More bits for all of us to bill. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp3mtp61M9Jq.pgp Description: PGP signature
Akamai DNS Issue?
From here neither www.google.com, nor www.apple.com work. Both seem to return CNAMES to akadns.net addresses (eg, www.google.akadns.net, www.apple.com.akadns.net), and from here all of the akadns.net servers listed in whois are failing to respond. Can someone confirm from another location? Comments from Akamai? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpfJT8Kq8B1k.pgp Description: PGP signature
Re: AboveNet major backbone issues
In a message written on Sat, Jun 12, 2004 at 01:02:54PM -0500, Edward Henigin wrote: Anyone have any more information? Leo? We loaded some global config changes last night. Sometime after they were loaded BadThings(tm) happened. We're still working with vendors to find the exact causes and ensure that we don't have further problems going forward. Things appear stable at this time, but we may have to make additional changes depending on what the vendors tell us to work around the issues involved. The plan is still evolving, and I'm not leading that charge so I have limited data at this time. Customers who have problems should send in a traceroute (bidirectional if at all possible) to the usual support channels. Sometimes you're the windshield, sometimes your the bug. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpi22LJJNBhG.pgp Description: PGP signature
Re: Cisco HFR
I don't think Reuters was impressed: From http://news.yahoo.com/news?tmpl=storyu=/nm/20040525/tc_nm/tech_cisco_router_dc_2 ] Routers, which look like pizza boxes piled atop each other, are one of ] the most boring pieces of equipment to look at, but probably the most ] crucial as they are used to direct information and data on a network. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp2XZoR1LnUi.pgp Description: PGP signature
Re: TCP/BGP vulnerability - easier than you think
I point out NetBSD released this: ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc Of interest is this paragraph: ] Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did ] not even check that a RST's sequence number was inside the window. RSTs ] anywhere to the left of the window were treated as valid. It's a good thing the 4.4BSD stack was unpopular, otherwise it might be in a lot of programs. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Sprint Help
In a message written on Thu, Mar 18, 2004 at 12:15:19PM -0500, Joe Marr wrote: I have a customer with a large citrix farm at hop 15. The customer has several remote offices, one as far away as Japan. One of their offices has been experiencing slow performance with their citrix connections. It's not Your problem is right here: 14 urish-pitts-gw.centrepc.net (67.97.250.166) 100 msec * 100 msec NT in many configs defaults to a TCP Window size of 8k, other NT and Server 2000 default to 16k. At one window per RTT that's 80k/sec or 160k/sec maximum throughput over a 100ms link. 80k/sec is not fast enough to make Citrix (which must send large portions of the screen) usable. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize Note, bigger is not better, if you go make it 64k you're likely to just crash your machine. Google for TCP Window Size and read one of the 50,000 papers available before you tweek the value. More to the point: This is becoming an acute problem in ISP support (at least, if you offer more than dial speeds). We get several queries per week from customers who put boxes in a New York and LA colo on GigE, and then can't get more than a 200k/sec FTP and want to complain about the backbone. Reality is they can get the full 1k/sec if they just fix their boxes. It's purely an end host issue. And yes, it is a Windows issue. Commercial and Free unix systems are generally all on 32k default windows, with a few at 64k default windows. These still need to be tuned for really high speed links, but don't make people complain. Microsoft waited too long to up these values (XP is 32k) so the masses of older servers show slow performance for no good reason. They really should update with a service pack. Cable/DSL providers who have software that tweeks users computer settings (which I have issues with, but if you do it...) should think about tweeking the value up for 98/NT/2000 users as part of the default software install. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Sprint Help
In a message written on Thu, Mar 18, 2004 at 11:08:21AM -0800, Michel Py wrote: Leo Bicknell wrote Your problem is right here: 14 urish-pitts-gw.centrepc.net (67.97.250.166) 100 msec * 100 msec NT in many configs defaults to a TCP Window size of 8k, other NT and Server 2000 default to 16k. This seems premature as a conclusion to me. If they don't have issues with Japan where the best RTT they can get is around 130ms I don't see why 100ms would be an issue. Because these are theoretical maximums. Very minor other issues (eg some packet reordering, 5-10ms of jitter, a single lost packet every now and then) will easily cut this in half. 130ms link at 95% of max (about the best you do on a clean link) would be 59k/sec, a 100ms link with 10ms jitter would drop to around 50% of max, or 40k/sec, or 33% slower. I bet setting the windows to 32k on both sides fixes his problem. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Strange public traceroutes return private RFC1918 addresses
In a message written on Tue, Feb 03, 2004 at 08:15:13AM -0600, Terry Baranski wrote: The performance gain achieved by using jumbo frames outside of very specific LAN scenarios is highly questionable, and they're still not standardized. Are jumbo Internet MTUs seen as a pressing issue by ISPs and vendors these days? While the rate of request is still very low, I would say we get more and more requests for jumbo frames everyday. The pressing application today is larger frames; that is don't think two hosts talking 9000 MTU frames to each other, but rather think IPSec or other tunneling boxes talking 1600 byte packets to each other so they don't have to split 1500 byte Ethernet packets in half. Since most POS is 4470, adding a jumbo frame GigE edge makes this application work much more efficiently, even if it doesn't enable jumbo (9k) frames end to end. The interesting thing here is it means there absolutely is a PMTU issue, a 9K edge with a 4470 core. There is also a lot of work going on in academic networks that uses jumbo frames. I suspect in a few more years this will make it into more common applications. In a message written on Tue, Feb 03, 2004 at 04:40:15PM +0200, Petri Helenius wrote: Me wonders why people ask for 40 byte packets at linerate if the mtu is supposedly larger? This is a problem that is going to get worse. I support IP you have to support a 40 byte packet. As long as that exists, DDOS tools will use 40 byte packets, knowing more lookups are harder on the software/hardware in routers. At the same time I suspect software is going to continue to slowly move to larger and larger packets, because at the higher data rates (eg 40 gige) it makes a huge difference in host usage. You can fit 6 times in the data in a 9K packet that you can in a 1500 byte packet, which means 1/6th the interrupts, DMA transfers, ACL checks, etc, etc, etc. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Strange public traceroutes return private RFC1918 addresses
In a message written on Tue, Feb 03, 2004 at 08:40:22PM +0200, Petri Helenius wrote: If you're paying for 40 byte packets anyway, there is no incentive to ever go beyond 1500 With a 20 byte IP header: A 40 byte packet is 50% data. A 1500 byte packet is 98.7% data. A 9000 byte packet is 99.7% data. Anyone who pays by the bit should like large packets better than small packets, as you pay for less overhead bandwidth. Note that a 1500 byte IP in IP packet becomes 1520, and then gets fragmented to 1500 and a 40 byte packet (20 data, 20 header). That's only 97.3% efficient, where as a single 1520 byte packet, if it could be carried, is 98.7% efficient. Obviously talking in smaller numbers, but to a lot of VPN vendors 1.4% improvement in bandwidth usage, bus usage, or avoiding the path through the device that fragments a packet in the first place is a big win. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Strange public traceroutes return private RFC1918 addresses
In a message written on Tue, Feb 03, 2004 at 09:53:30PM +0200, Petri Helenius wrote: Sure, if you control both endpoints. If you don´t and receivers have small (4k,8k or 16k) window sizes, your performance will suffer. Maybe we should define if we´re talking about record breaking attempts or real operationally useful things here. Google and Akamai are just two examples of companies with hundreds of thousands of machines where they move large amounts of data between them and have control of both ends. Many corporations are now moving off-site backup data over the Internet, in large volumes between two end points they control. The Internet is not just web servers feeding dial-up clients. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Impending (mydoom) DOS attack
Having looked for some information to educate myself and my employer, I will say a weakness right now is that there is limited info about this worm. I have yet to see any good information on how effective the attack might be, or what some basic prevention steps (eg filtering) might do to the worm. Backbones don't often have people that disassemble worms. It would be nice to find some way for the anti-virus companies to share more details quicker with various backbones in order to effectively combat the DDOS portion of worms. If anyone has any good analysis on the current worm (other than it attacks www.sco.com), that would be welcome. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Impending (mydoom) DOS attack
In a message written on Fri, Jan 30, 2004 at 04:18:05PM -0800, Donovan Hill wrote: I think we should help out SCO by creating new wildcard entries into our DNS servers that point *.sco.com to 127.0.0.1 as well as blackholing all SCO SWIPd IP Address Space. I'm going to be one of the last people who will defend SCO recent actions. However, as much as I hate, and hate is the word, SCO I feel the need to speak up after your comments. Bruce Perens has said it far better than I ever could at http://perens.com/SCO/DOS/. Please read what he has to say. We (Open Source, ISPs, etc) must, MUST, come to SCO's defense on this one. I am doing what I can with my employer to do just that. Allowing attacks like this to succeed, either directly or indirectly is far more harmful than allowing SCO to stay online. We cannot condone these actions for any reason, the end does not justify the means in the case of worms. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: example.com/net/org DNS records
In a message written on Sun, Jan 04, 2004 at 05:51:40PM -0800, Randy Bush wrote: pedantic point: no, they are not 'owned' by anybody. they are *reserved*, and should not be used by anybody. To be really pedantic, from http://www.faqs.org/rfcs/rfc2606.html: ] 2. TLDs for Testing, Documentation Examples ] ]There is a need for top level domain (TLD) names that can be used for ]creating names which, without fear of conflicts with current or ]future actual TLD names in the global DNS, can be used for private ]testing of existing DNS related code, examples in documentation, DNS ]related experimentation, invalid DNS names, or other similar uses. I don't think I'm going out on a limb to suggest that names like example.com should be used by _everybody_ in documentation examples, least they pick something that might actually be used in the future. To wit, the point is not that they should not be used by anyone, as you suggest, but rather, like RFC 1918 space, should be used by everyone for documentation, example configurations, and the like to insure they never conflict with a real service. The idea that if someone tries to use them they are presented with an intelligent error message that seeks to educate them is pleasing. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Routeviews and possible 0/0 route
In a message written on Thu, Dec 18, 2003 at 03:12:17PM -0800, David Meyer wrote:
Nope to the former. Someone (6461) is advertising it. We
Speaking for 6461, if a customer asks for a default route, we send
them one.
The {problem,cool thing} about route-views is many people send it a full
table. That can {cause all sorts of analysis problems,give you a view
into things you wouldn't normally see}. YMMV.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: AS Path Loops in practice ?
In a message written on Thu, Dec 11, 2003 at 11:07:03PM +, Stephen J. Wilcox wrote: Perhaps I'm missing something having not done this myself but why arent the customers just using private ASNs? That would also remove the 'must default' clause. Not enough, customers already use them internally, other things use them (eg, route servers), easier to talk customers through configs on the phone, allows customers who have IP space but not an ASN to announce to the Internet without the provider having to announce directly. I'll bet there are more I can't remember. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: AS Path Loops in practice ?
In a message written on Tue, Dec 09, 2003 at 03:13:12PM +0100, Niels Bakker wrote: One cannot have discontiguous networks in the same ASN. It's pretty simple: two routing policies, two ASes, two ASNs. Unfortunately you weren't able to convince your customer of this. This is simply not true, and trying to push it as an absolute elimintes a very good way of configuring customers and conserving resources. Most (all) large ISP's have a customer ASN. This allows a customer to connect in multiple places, run BGP, and get something approximating real redundancy to that carrier. However, rather than allocate one ASN to each customer, all customers use the same customer ASN. Yes, that means they must default to the provider (and/or have the provider provide a default route) to reach the other customers using this technique. I believe there are a number of providers with hundreds, or perhaps even thousands of customers using this feature, saving lots of ASN's and causing no problems. Externally this looks fairly neat, there is a single ASN behind the backbone AS with all the customers in it. To make this work you do need to enforce some restrictions. First, the customer ASN must never be connected to another network (this is for multiple connections to a single provider only) to prevent the wonky AS path issues, and second the customer must have a default via some mechanism. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Above.net problems ??
In a message written on Wed, Nov 26, 2003 at 09:35:16AM +0100, Laurent Frigault wrote: The sessions reset again 35 minutes ago. Missing prefixes are back and above.net network seems reachable again. We did restore full service overnight last night (well, probably early in the morning for those in Europe), our operations should be back to normal. If anyone is still seeing above.net issues please open a ticket through the normal channels. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Above.net problems ??
In a message written on Wed, Nov 26, 2003 at 05:39:33PM +0100, Jerome Fleury wrote: Is there any relationship between this europeanwide above.net failure and the huge amount of DNS requests to lockup.zonelabs.com which failed that every ISP (at least in France) seem to have encountered last night ? The zonelabs.com zone is hosted on Above.net NS servers. I replied privately, but then saw this also went to Nanog. I'm also looking into that problem. My initial observation: 1) AboveNet DNS servers were down for some people in Europe. 2) ZoneLab's other nameservers are both on the same lan and connected to our network. 3) ZoneLab's software seems to have an overly agressive retry (I've been told 2 queries per second per machine) when it can't resolve a DNS name. Clearly we can only directly address #1, which is a top priority for us, we are trying to make the customer aware of why #2 and #3 are bad. I haven't proven #3 yet, it's based on other peoples reports, so I might be wrong about the software's exact behavior. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: TAT 14 failure
In a message written on Tue, Nov 25, 2003 at 07:24:27PM +, [EMAIL PROTECTED] wrote: still seeing decent ping times. anyone detect an actual outage or issue? Best info we have is that there are two outages. One has existed for the last 3 weeks or so between Tuckerton (New Jersey) and Bude (UK). It takes out the southern path across the atlantic. There is a second outage between Bude (UK) and Katwijk (NL). For circuits that landed in London or France this (should have) taken out the redundant path for those circuits. Circuits from Tuckerton (New Jersey) or Manasquan (New Jersey) to Katwijk (NL), Norden (DE), or some city in Denmark who's name I forget should still be up on the northern path. So, if you're in London or France your circuits are likely to be down, however some people in those locations used Contentinal capacity to link up to Katwijk, in which case they might still be operational. Both problems are undersea issues, so don't expect speedy resolution if you are down. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Above.net problems ??
In a message written on Tue, Nov 25, 2003 at 05:08:29PM -0500, hostmaster wrote: anyone having trouble with above.net at the moment ? AboveNet is having issues due to the second cable cut on TAT-14. In addition I have just received some information that appears to be some helpful ISP's leaking some of our routes. Maybe it's an innocent misconfiguration, but if not please stop. In any event, I'm trying to track that down now and make it better. We're working as hard as we can to fix the problems. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Router with 2 (or more) interfaces in same network
In a message written on Tue, Nov 11, 2003 at 08:35:34AM +, Sugar, Sylvia wrote: I am curious to know if its possible to have a router with its two interfaces, say configured as, 1.1.1.1/16 and 1.1.1.2/16. Theoretically, i see nothing which can stop a router from doing this. Cisco's don't let you do this. I have always considered that broken, although I'm sure Cisco thinks it's a feature. Other routers (of note FreeBSD boxes) do this just fine. In almost all cases I've seen it done it was for more bandwidth to the box (typically inbound only, because there are no good tools on Unix boxes to split the traffic between the outgoing interfaces). I've seen it done a lot in labs where you have something like this: client 1 | | client 5 client 2 +B+ client 6 client 3 | | client 7 client 4 | | client 8 | | file-server-router-box | Internet Where all the clients are in one subnet, there are two interfaces, and the networks are separated (today the left and right groups on two different switches, I drew the old school picture of thinwire with a bridge in the middle. While this will work (with some boxes, again Cisco's won't let you configure the same subnet on two interfaces), it is at best a hack that helps in some specific instances. It is quite clearly not good network design. Maybe they have one of those specific instances but I'd get a lot more detail and be sure before you offer up this hack as otherwise you've got a messy config that didn't do what the customer wanted anyway. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Router with 2 (or more) interfaces in same network
In a message written on Tue, Nov 11, 2003 at 10:34:31AM -0500, Richard A Steenbergen
wrote:
I'm not sure how Cisco is wrong on this one. If you want 2 router
interfaces to have the same route and you actually want both of them to
work, it means at the very least you must have a non point-to-point
medium, such as Ethernet. In this case, the correct configuration would be
a bridge-group and IRB, creating a virtual routed interface with 2
physical ports for bridging.
Correct config yes, however it doesn't have some of the load balancing
properties the other hack method does.
Given how many other ways Cisco will let you shoot yourself in the
foot, this particular feature seems odd. I've asked about it
before though, and it seems to a under-the-hood issue due to the
way they do arp.
I love FreeBSD, but it's routing code is probably the thing you least want
to look to for examples on how things should be. BTW there is a netgraph
module for L2 hash-based load balancing (aka etherchannel without the
PAgP/LACP), but yeah the lack of ECMP and a reasonable switching method to
support it falls into the category of the previous sentence. :)
Well, s/FreeBSD/{Linux,SunOS,HP-UX,OSF/1,probably others}/. I've
seen this done a lot with various unix boxes. Never tried on a
Juniper. My point was simply that there are boxes that will let
you do this, and that some people do it with great success to solve
specific problems. Doesn't mean it's not a hack, or that an ISP
should support that type of configuration.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
In a message written on Wed, Oct 29, 2003 at 09:35:13AM -0600, Kuhtz, Christian wrote: Simply ignoring present reality isn't a globally wise solutions. Hence we have broken VPN products incapable of dealing with NAT. Some are capable of dealing with NAT just fine, and are readily available. Enough said. The danger here isn't that it can be made to work, but that as network operators we are driving application vendors to a very dangerous lowest common denominator. The VPN people have already figured out: A) The technology must run over a TCP connection that encodes no local endpoint information so it can pass through NAT. B) The technology must be able to run on TCP port 80 to bypass overly restrictive filters. Other applications are doing the same. Many of the file sharing services can already meet both of these points. The end result is that in the near future it will be much harder, or impossible for network operators to collect statistics based on traffic type or to filter particular types of traffic without being able to dig into the payload itself and see what type of traffic is passing. Some people see this as a problem, some do not. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: [arin-announce] IPv4 Address Space (fwd)
In a message written on Wed, Oct 29, 2003 at 02:24:54PM -0600, Kuhtz, Christian wrote: Isn't that the whole point of running a VPN connection? Yes. What I'm saying is network operators are slowly forcing everyone to run _everything_ over a VPN like service. That's fine, but it makes network operators unable to act on the traffic at the same level they can today. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: IAB concerns against permanent deployment of edge-based filtering
In a message written on Sat, Oct 18, 2003 at 07:39:37AM -0700, [EMAIL PROTECTED] wrote: why the heck does the IAB think they should tell me how to run my network? I think the IAB has a legitimate point. Network operators rely today on the fact that different services use different ports, so they can block particular types of access/behavior by blocking ports. However, this behavior has already started to change how applications work. We've all seen the streaming media clients, or IM programs that will use port 80 to get past a firewall, even though they are not http traffic. Virus writers have done the same thing. New VPN technologies use SSL, on the SSL web server port, but then send IP packets over them, not web requests. There is a real danger that long-term continued blocking will lead to everything on one port (probably 80). This will have the end result that ISP's will be unable to filter out the bad traffic anymore by using a port based filter, nor will they be able to collect statistics or other usage data. Additionally, this moves the problem up the stack as if everything runs on port 80 some intelligent demuxer will be needed at a higher layer for a box that wants to run multiple services. I'm not saying ISP's shouldn't filter, but the long term filtering is a problem. It will cause application developers to do things that will make long term filtering not work, in the end. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: IAB concerns against permanent deployment of edge-based filtering
In a message written on Sat, Oct 18, 2003 at 12:26:21PM -0400, Eric Gauthier wrote: Again, I definitely agree with the IAB's recommendation. However, its difficult to defend this point of view in practice since most of the equipment does basic packet filtering in hardware or with minimal cost to peformance. So, I just can't figure out how to sit in front of our administration and justify the replacement of a zero-cost solution with the cost of added staff and equipment to mitigate these security risks, especially when the up side is just not limiting the potential for deployment of future applications. Well, but you've hit the nail on the head. The fitler solution is _NOT_ zero cost, it is deferred cost. I suggest you phrase it that way. It's a way of deferring the cost to later, with interest. The longer you use it, the higher that interest payment will be, in the form of new and different attacks you can't block. Phrasing it to the bean counters that it is deferring the cost, with interest, and suggesting that simultaneously some money be spent on user education, better software, or whatever is appropriate to insure you don't have a huge baloon payment later might help put it in terms they can understand. Similar parallels can be drawn to antibiotics -- the over use will eventually render them ineffective. It's a very similar situation, and sometimes you have to just invest in not getting sick in the first place (wash your hands...patch your system). -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: more on VeriSign to revive redirect service
What I think will be interesting is who has the bind patch this time around. The first time many companies didn't deploy the bind patch for reasons ranging from taking a few days to study the impact to not being able to deploy new software on their nameservers that quickly to not being able to get management buy in on blocking wildcard records. If Verisign turns the service back on without ICANN approval I expect a much larger number of people, and perhaps some larger networks to implement the bind patch this time around. It's unfortunate, as this is not the right way to run a network. When left with no choice, engineers will work around any problem. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Internet privacy
In a message written on Thu, Oct 02, 2003 at 01:22:12PM -0700, Owen DeLong wrote: What valid reason is there for allowing a domain owner to be unlisted and uncontactable. If you want to remain anonymous, then you don't need a domain. It is possible to be anonymous and contactable. Is that that good enough (for domains, IP allocations, or other things served up via whois)? Is it key we know the owners real identity, or just know enough information to be able to contact them? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Proposed changes to the AUP.
Two recent e-mails made me take a new look at the Nanog AUP, and I'd like to propose several changes to help clarify the policy. Several recent discussions have descended into the weeds. I'll take my share of the blame for my participation. That said, one on-list event, and several off list events have raised some lingering questions about the Nanog AUP and how it is enforced. I believe that there are a couple of changes to the AUP that would help prevent these threads from happening, and those are the issues I want to raise. If you're not familiar, the AUP is at http://www.nanog.org/aup.thml. I suspect many of you have no idea how the Nanog AUP is enforced, so I will go into that first. Moments ago we saw a glimpse on the list. The first attachment to my message (it's not in the archive yet to give you a URL) entitled srh-jrace is a copy of an e-mail I believe Susan accidently copied to [EMAIL PROTECTED] If you look at the CC list you'll see the intended target was [EMAIL PROTECTED] To help show that assumption is probably correct, I attach three more messages, first, second, and third. These are three cases, in chronological order, where I have been given similar warnings for AUP violations. For full context, these three messages were part of the following threads: first - http://www.cctec.com/maillists/nanog/historical/0109/threads.html#01538 second - http://www.cctec.com/maillists/nanog/historical/0110/threads.html#00577 (Note, there are at least three other thread roots right under it as some follow ups didn't get attributed correctly.) third - http://www.merit.edu/mail.archives/nanog/threads.html#14454 To be clear, I'm not trying to appeal my conviction on any of these, the first thread clearly drifted way off topic, the second I clearly mention the law and politics. The third gives me a bit more trouble, as the reason I posted was to see if anyone could operationally use this new (admittedly legal) tool, but heck, it was about law so I'm ok with being wrong on that one. I show you these as I am unhappy about the method by which these were handled. So, what are my proposals? Simple: 1) Change item 6 on http://www.nanog.org/aup.html to read prohibited rather than discouraged. Discouraged suggests to me general discussion about those topics is bad, but if it has operational significance or general interest on the list it may still be appropriate. However, it appears that there is no clear way to define what would or would not be appropriate, and that the enforcement is more in line with prohibited. Changing that one word should make it much more clear, and remove all doubt. Most likely item #3 should also be prohibited and not discouraged as well. 2) The current AUP states: ] Individuals who violate these guidelines will be contacted personally ] and asked to adhere to the guidelines. If an individual persists ] in violating the guidelines, the convener of NANOG, Merit Network, ] Inc., will take action to filter the offender's messages to the ] list. I have several problems with this: * There is no way for the nanog membership to review that the policy is being applied evenly and fairly. * Where there are ambiguities in the appropriateness of a topic there is no way to know that the moderators are using the same criteria the general membership would use. * It does nothing to educate other mailing list participants as to what is or is not appropriate. This method provides a gentle and constant reminder of the AUP that always provides new and relevant examples. * It does nothing to stop the thread. Several people have received these after others for the same thread -- I think we all have an implicit assumption that if it's allowed to continue by the moderators it must be ok to reply. To that end, I propose the following new method of handling things, which I believe is more in-line with what other mailing lists do: When inappropriate messages are sent to the list the convener will reply both to the list and to the poster pointing out that the topic is in violation of the AUP and should cease. Chronic offenders will be notified personally that their messages may be filtered or that they may be removed from the list as deemed appropriate by the conveners. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org From [EMAIL PROTECTED] Thu Sep 25 09:11:13 2003 Return-Path: [EMAIL PROTECTED] Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h8PDBC8h005650 for [EMAIL PROTECTED]; Thu, 25 Sep 2003 09:11:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BD132912AA; Thu, 25 Sep 2003 09:08:30 -0400 (EDT
Re: Another DNS blacklist is taken down
In a message written on Wed, Sep 24, 2003 at 11:28:39AM -0500, Justin Shore wrote: So, my question for NANOG is how does one go about attracting the attention of law enforcement when your network is under attack? How does the target of such an attack get a large network provider who's customers are part of the attack to pay attention? Is media attention the only way to pressure a response from either group? These DDoS attacks have received some attention in mainstream media: People will pay attention as soon as there is money in black lists. ISP's are businesses. If losing the customer is cheaper than helping them far too many will choose to lose the customer. Many black lists don't pay the ISP at all, indeed they are offered as free services for the good of the community. As a result they get the response that any freeloader would, none. For better or for worse you get to vote with your dollars, which really means no dollars, no vote, no support. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Another DNS blacklist is taken down
In a message written on Wed, Sep 24, 2003 at 01:28:19PM -0500, Justin Shore wrote: True. However I also subsribe those beliefs. When an ISP knowingly allows a spammer to sign up for network service, knowing full well what they are planning to do with it (read: pink contracts), and ignores abuse complaints then what other form of action is there than to use collateral damage at that ISP? Providers more often than not intentionally put The answer is to take the high road and just list the spammer. If, as you suggest, the ISP knowingly signs up the spammer then they already expect the collateral damage, are probably, in general ok with it, and you're not going to have any effect in getting them to change. However, by listing larger and larger blocks of unrelated customers you piss off random end users, and more importantly the mail admins that use -- and could support your RBL. I know more than a few mail admins who gave up on various RBL's after they went off the deep end, blocking more legitimate mail under the guise of trying to force ISP's to do something than spam. I suspect a well run RBL that was able to take the high road, and offered good responce time would find mail admins would pay a small subscription fee, they could buy bandwidth from a provider, and more importantly since they were a paying customer and not a kook they would get excellent support from ISP's in tracking DDOS attacks. That said, I don't think the RBL users often understand the complexity of the issue, which further annoys ISP's. I know I've been involved in several issues where a reputable e-commerce site buys service quite above board. They then have an affiliate program, where people can sign up online and get goods. A number of spammers then sign up, joe-job the e-commerce company and make off with a few hundred dollars in goods. In the cases I've been involved with the e-commerce company immediately terminates them for violating the terms of the affiliates agreement, but it only takes two or three of these instances for the RBL's to start blocking the company, screaming pink contracts and blocking the ISP's other users. So, while the RBL's hurt the ISP's, and the ISP's tie up the RBL's time with an issue they aren't going to be able to solve the real spammer gets away scott free, and the ISP has to deal with other customers who have been caught in the collateral damage of the RBL. Just once I'd like to see an RBL come to my employer saying we've found this spam we think transited your servers and would like to work with you to find the real source and block it. Insted they all seem to send an e-mail to the effect of You pathetic worthless $*@@#$#$. Stop sending this crap and terminate your customer in the next 10 minutes, or else and then proceed 10 minutes later to list every IP ever affiliate with the ISP. No wonder the same abuse people aren't eager to help when the RBL comes back and asks for help. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: williams spamhaus blacklist
In a message written on Wed, Sep 24, 2003 at 05:14:04PM -0400, [EMAIL PROTECTED] wrote: The moment they started blacklisting IPs that never sent spam. (AKA williams corporate mail servers). For those who care: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL10731 I quote: ] WilTel Communications Group's Corporate Mail Relays ] Continued hosting of Eddy Marin spam gang and others have caused this ] listing. Previous warnings and spam reports had no effect. So, they have decided since WilTil has one (alleged?) spammer customer none of wiltel should be allowed to send or receive e-mail anymore. The complete list of Williams issues is at: http://www.spamhaus.org/sbl/listings.lasso?isp=wcg As per usual, no amount of collateral damage is deemed unacceptable. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
New CA Law
Word is Gray Davis signed this law, http://info.sen.ca.gov/pub/bill/sen/sb_0151-0200/sb_186_bill_20030911_enrolled.html today. It seems to be a pretty strong anti-spam bill. Given all the talk of black lists and DDOS's and the like does anyone think this will make a difference? Is anyone planning on using the law to recover damages? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Verisign Responds
http://www.icann.org/correspondence/lewis-to-twomey-21sep03.htm I quote: ] As to your call for us to suspend the service, I would respectfully ] suggest that it would be premature to decide on any course of action ] until we first have had an opportunity to collect and review the ] available data. One would think it would be equally premature to roll out the service without first asking the appropriate people for their opinion first, starting with ICANN. Looks like the lawsuits are going to be the ones to settle this dispute...anyone think there's a chance of ICANN pulling .COM and .NET from Verisign due to breach of contract? I think it's highly unlikely. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Worst design decisions?
In a message written on Thu, Sep 18, 2003 at 03:53:44PM -0700, Ben Browning wrote: Cisco V-notched power cables - Design feature geared around getting suckers to buy a power cable for 45USD. Uh, you might want to be careful with these connections. You'll note the IEC-320 C13/C14 connectors (eg, what you find on PC's) are 15 Amps, but only 65 degC rated. The IEC-320 C15/C16 (with the notch) are also 15 Amps, but are rated to a pin temperature of 120 degC. I doubt Cisco did it to be a PITA, electrical codes probably required it for some reason. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Verisign suggestion
In a message written on Thu, Sep 18, 2003 at 12:25:48AM -0400, Gerald wrote: They don't pay a thing for all of these domains that they are now accepting queries for. It would seem to me to our benefit as an Internet community to word this in our favor and send Verisign a bill for manipulating their monopoly on the .net and .com zones. My suggestion: I've seen a lot of knee-jerk responses on the list to this issue, but this one is the first idea I think actually holds up to more detailed inspection. Domain speculators have been registering typos for years, paying money for them, and redirecting you to all sorts of things. While this may not win them any friends it is generally accepted. Verisign can now do that without paying for each mistyped domain, giving them a huge (economic) advantage. [Note: yes, there are technical advantages, like they get everything with one record, but money talks.] Now, as much as I hate ICANN, I do think they are entitled to their cut of each one of these domains. If I worked at ICANN I would write a script to find domains, show that some large number of gTLD's respond, and then show Verisign only paid for a fraction of that number. Verisign's liability here is huge, if you just assume 36 characters (a-z0-9) and 64 character long domain names you could charge them for 36^64 domains. I strongly encourage ICANN to bill them for all the domains they are now redirecting (eg, all mathematically possible, more detailed analysis required), and for the domain speculators who've been registering for years to sue them for unfair monopolistic practices, or something, since they clearly have an unfair advantage. Heck, you might even be able to get an injunction against them pretty quick. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: DNS anycast considered harmful (was: .ORG problems this evening)
In a message written on Thu, Sep 18, 2003 at 09:57:23AM -0400, Todd Vierling wrote: The problem with UltraDNS, the point which many on this people are missing, is that at least some UltraDNS sites are advertising *all* anycast networks simultaneously (see traceroutes below). Yes, all == 2 at the moment, but this argument holds for any value of all. Having just looked at this for some work functions I must agree. A truely robust anycast setup has two addresses (or networks, or whatever), but only one per site. From the momentary outage while BGP reconverges to the very real problem of the service being down and the route still being announced there are issues with all anycast addresses going to one site. Number your sites from 1..N, have all odds announce one address, all evens the other. DNS servers will still use the closest (due to RTT checking), but will now also have a backup that does not go to the same site in steady state, but is still very close as well. I strongly suggest the UltraDNS people look at that configuration if they aren't doing it now. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: .ORG problems this evening
In a message written on Thu, Sep 18, 2003 at 10:05:15AM -0400, Todd Vierling wrote: Anycast is *NOT* a redundancy and reliability system when dealing with application-based services like DNS. Rather, anycast is a geographically I think you'll find most people on the list would disagree with you on this point. Many ISP's run anycast for customer facing DNS servers, and I'll bet if you ask the first reason why isn't because they provide faster service, or distribute load, but because the average customer only wants one or two IP's to put in his DNS config, and gets real annoyed when they don't work. So it is a redundancy and reliability thing, the customer can configure (potentially) one address, and the ISP can have 10 servers for it so if one dies all is well. Is it appropriate for a gTLD? Now that's a whole different can of worms. Personally I think they should return the two anycast addresses, and as many actual server addresses as will fit in the packet. This is the best of both worlds. When it works, geographicly distributed load, redundancy at the IP layer, quick responces. When one of the failure modes is encountered (eg, stuck route) DNS has the information it needs to switch to a backup as well. Redundancy is good. Redundancy at two levels is even better, particularly when they can back each other up. Plus, in this case it costs them nothing, they just have to tweek a config. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Cross-country shipping of large network/computer gear?
I'm not sure if any of them are here, or if they would make their info known...but I'm sure vendors have some good data. I know Cisco's online ordering tool has about a bazillion (and yes, that's the right term) shippers, and I'm sure they track the number of problems reported. No doubt other vendors do as well. Anyone friends with someone in the logistics department at a big hardware vendor care to comment? :) -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Tier-1 without their own backbone?
In a message written on Wed, Aug 27, 2003 at 04:39:42PM -0500, Matthew Sweet wrote: Alot of carriers that have a Nationwide backbone actually lease their circuits (Layer 1 and 2) through various other carriers. There are actually a lot more layers than that, not that most people interested in buying a circuit should care. Possible ownership changes occur at: - Owner of the right of way. - Owner of the duct. - Owner of the cable in the duct. - Owner of the fiber in the cable. - Owner of the wavelength on the fiber. - Owner of the circuit on the wavelength. - Owner of the channel on the circuit. - Owner of the VC on the channel (at least, for MPLS, ATM, and Frame) - Owner of the router. (I'll stop there for backbone purposes.) When people ask about ownership, I think they generally want to know the answer to three related questions: 1) Do you have the ability to turn up additional capacity in time? 2) Do you own the right bits of infrastructure so you can control cost (with right being the operative word, not a specific level)? 3) Do you have enough control over the chain above such that it won't be broken if someone who owns another part goes Chapter 7|11? I do wonder who owns it all. Most companies, even if they own their own fiber (fiber in the cable, or cable in the duct) don't own the duct or right of way. Many of the right of way owners don't do circuit or IP services at all. As a practical matter, I'm not sure it matters a whole lot where the divide is, as long as the company has it structured so the answers to those three questions are positive. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
In a message written on Wed, Aug 27, 2003 at 12:15:18AM -0400, John Payne wrote: If this is true, then why do the european NAP mailing lists (which push IRR filtering) have an almost constant stream of oops, our customer announced everything to us and we leaked it. Because European naps have more smaller and clueless players. I know more than a few people (because they ask for peering) who have an IRR entry that is 1 prefix for the ISP, and 1 prefix for their only BGP customer. It should be of no surprise they get that customer configured wrong. It should also be of no surprise that most of the real ISP's would never consider peering with those types of networks. Of course, those small and clueless players exist elsewhere, but in general you don't see them connected to exchange points in other parts of the world. Filtering peers is not the way to go. Filtering customers and trusting peers to do the same is. (Whether that trust explictly mentioned in a peering agreement or whatever). You're right, but you missed a part of that solution. ISP's should filter customers, and trust peers to do the same. That also means they need to qualify their peers in some way to insure they aren't peering with someone who doesn't understand that. Just a shame that not everyone filters their customers. And although it has been a while, I know I've seen a route-leak from 6461 at AMS-IX. (Probably last year sometime) 6461 filters all customers by prefix list. Note too, filtering customers does not eliminate route leaks, it just removes the most obvious and often cause. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote: If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... [snip] Is it really that hard? Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. The fundamental problem with the IRR Everywhere notion is simple. If everyone filtered everyone, then, drum roll please: Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Now, you can pontificate all you want about the things that would be better if you could filter every session, but the problems are going to be quite similar to the problems of scaling BGP. BGP gets the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). Just as we've had to do with BGP over the years, that's going to mean other built in safeguards a la dampening on the IRR infrastructure. Plus of course, the IRR is actually /FAR WORSE/ than BGP. Why? Well, with BGP there may be 20 possible routes between you and the destination, however only the best is in everyone's tables, with most of the backup routes pruned near the edge of the routing domain. However with filters that doesn't work. If I can hear a route from two providers I have to put it in both provider's filter lists all the time, or else when it fails and BGP switches over I'll reject the route, which is no good. While filtering is very important on the customer edge, it breaks down for the same reasons when you talk about provider to provider filtering. If UUNet can't trust Sprint to send it good, valid routes on the average there is a much deeper problem than filtering will ever solve. In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote: The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices? I'm going to pick on this example. The LINX is interesting in that it is one of the most successful public fabrics worldwide. That cannot be denied. There own statistics https://stats.linx.net/cgi-pub/combined?log=combined.bits show about 23 Gig of traffic moves through there on a daily basis. That said, the LINX is a drop in the bucket. Top ISP's have individual customers with 10 Gig contracts. Public peering in total is non-interesting to backbone providers, which is why so many of them don't do it. To put this in perspective my own employer, AboveNet, who's agressive on public peering as large ISP's go does more traffic to our single largest peer than we do across all the public exchanges worldwide combined. Even if IXP's and NAP's were able to ensure 100% filtering of the public participants it wouldn't make a measurable difference in the global internet. Indeed, I suspect it would only serve to drive more medium sized player away from exchange points and to private interconnects with only the largest players. Almost everyone filters customers. The large ISP's all have the same opinion, if small to medium sized players abuse the system they get depeered and become someone's customer aggressively filtered. The large ISP's then trust each other to do that aggressive filtering. So be careful if you advocate filtering. The IRR, with everyone doing an update for every customer worldwide does not scale, but depeering all the smaller peers and letting a few big guys sort it out does. I don't think that's the result most people pushing filtering want. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote: Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. CW, Level3, Global Crossing and NTT/Verio are small isps? Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :) My rant is on peer-to-peer filtering. Customers should always be filtered by every ISP. Period. ISP's should automate that as much as possible for their customers, and using the IRR is a fine solution. Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed? It's a bad thing because it doesn't scale. It's not a matter of before or not, it's that there is a linear relationship between the size of the internet and the processing needed to be done by each ISP. That doesn't scale. Hmm.. you are missing some of the benifits that I see associated with this. If I have a list of all the prefixes that I could get sourced from MFN/above.net in a easily queryable format, I can install anti-spoofing filters. No, you couldn't. Please go back and take routing 101 again. Internet routing is asymetrical, the source of the packet has nothing to do with where the return route points in the core. If it were that simple we could just use Unicast RPF on all peering links and spoofing would be a thing of the past. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Lazy Engineers and Viable Excuses
In a message written on Tue, Aug 26, 2003 at 10:43:00AM -0400, Jared Mauch wrote: Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from. ___T1 to Verio, With BGPVerio__ / \ Customer UUnet \ / ---T1 to Sprint, No BGP-Sprint- Now, the customer, over their two T1 transit circuits does the following: as-path access-list 1 deny .* neighbor verio filter-list 1 in ip route 0.0.0.0 0.0.0.0 sprint Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? Note also, even if these cases are in the IRR, UUNet's filter for Sprint will be larger than the number of routes currently received, since there is no route for this prefix that needs to be in the filter. [Note, I don't suggest this configuration is common or useful on its own, but rather it's a simple enough case it can be used for discussion in e-mail.] -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
