Re: cooling door
At 3:17 PM + 3/29/08, Paul Vixie wrote: page 10 and 11 of http://www.panduit.com/products/brochures/105309.pdf says there's a way to move 20kW of heat away from a rack if your normal CRAC is moving 10kW (it depends on that basic air flow), permitting six blade servers in a rack. panduit licensed this tech from IBM a couple of years ago. i am intrigued by the possible drop in total energy cost per delivered kW, though in practice most datacenters can't get enough utility and backup power to run at this density. While the chilled water door will provide higher equipment density per rack, it relies on water piping back to a Cooling Distribution Unit (CDU) which is in the corner sitting by your CRAC/CRAH units. Whether this is actually more efficient depends quite a bit on the (omitted) specifications for that unit...I know that it would have to be quite a bit before many folks would: 1) introduce another cooling system (with all the necessary redundancy), and 2) put pressurized water in the immediate vicinity of any computer equipment. /John
Re: cooling door
At 7:06 PM + 3/29/08, Paul Vixie wrote: While the chilled water door will provide higher equipment density per rack, it relies on water piping back to a Cooling Distribution Unit (CDU) which is in the corner sitting by your CRAC/CRAH units. it just has to sit near the chilled water that moves the heat to the roof. that usually means CRAC-adjacency but other arrangements are possible. When one of the many CRAC units decides to fail in an air-cooled environment, another one starts up and everything is fine. The nominal worse case leaves the failed CRAC unit as a potential air pressure leakage source for the raised-floor and/or ductwork, but that's about it. Chilled water to the rack implies multiple CDU's with a colorful hose and valve system within the computer room (effectively a miniature version of the facility chilled water loop). Trying to eliminate potential failure modes in that setup will be quite the adventure, which depending on your availability target may be a non-issue or a great reason to consider moving to new space. /John
Re: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]
At 9:48 AM -0700 3/13/08, David Conrad wrote: What is _really_ missing is content accessible over IPv6 as it results in the chicken-or-egg problem: without content, few customers will request IPv6. Without customer requests for IPv6, it's hard to make the business case to deploy the infrastructure to support it. If ISP's are waiting for new IPv6-only content to create customer demand to justify their business case for IPv6 enablement, then that's their choice. Reality will win in the end, and my $$ will be on the providers who justified their IPv6 enablement on being able to continue to grow. /John
Re: Access to the IPv4 net for IPv6-only systems
At 12:02 PM +0200 10/3/07, Iljitsch van Beijnum wrote: On 3-okt-2007, at 9:42, Randy Bush wrote: but the reality is ipv4 works and ipv6 doesn't. It has very little deployment at this point in time, that's something different. I'm with Randy on this one... While we will have increased IPv6 deployment as we get closer to IPv4 free pool depletion, the size of the IPv4 installed base is very impressive and the task of moving it all to dual-stack may not be achievable w/o NAT-PT and a set of defined ALG's. the reality is you have a choice. nat-pt or ipv4 with massive natting forever. it's not a choice i like, but it's life. get over it. I'd rather have IPv4 with massive NAT and IPv6 without NAT than both IPv4 and IPv6 with moderate levels of NAT. That's great, guys, if IPv4 with massive levels of NAT actually resembles today's Internet and is actually a viable choice. Once free pool depletion occurs and address reuse enters the equation, we've got high demand for block fragmentation and a tragedy of the commons situation where everyone's motivations are to inject their longer prefixes and yell at others not to do the same. It's a very different circumstance that we have today with NAT and it only gets worse as utilization increases. /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 10:43 AM +0200 10/2/07, Iljitsch van Beijnum wrote: When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally. Yeah right. Youtube is going to switch to IPv6 because I have trouble viewing their stuff through NAT-PT. For you? now? Not likely. About the time that a very large number of new Internet sites are being connected via IP6 because there is little choice, that's a different story. Providers would be likely be telling customers to send their complaints to YouTube, and that everyone's in the same situation until Youtube gets a real connection. The proxytunnel vs NAT-PT differences of opinion are entirely based on deployment model... proxy has the same drawbacks as NAT-PT, only without the attention to ALG's that NAT-PT will receive, and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. For now, HTTPS proxy or a IPv4 tunnel over IPv6 works fine, but most folks don't really care about IPv6 deployment right now. They're looking for a model which works 3 years from now, when the need to deploy IPv6 is clear and present. At that point, there's high value in having a standard NAT-PT / ALGs approach for providing limited IPv4 backwards compatibility. /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 5:36 AM -0400 10/2/07, John Curran wrote: ... tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. c/are/are no longer/ (before my morning caffeine fix) /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 1:50 PM +0200 10/2/07, Iljitsch van Beijnum wrote: ALGs are not the solution. They turn the internet into a telco-like network where you only get to deploy new applications when the powers that be permit you to. At the point in time that NAT-PR is used for backward compatibility (because we're connecting new sites via IPv6) people should be encouraged to rollout their new apps over IPv6, right? What's the problem? and tunnelling is still going to require NAT in the deployment mode once IPv4 addresses are readily available. Yes, but it's the IPv4 NAT we all know and love (to hate). So this means all the ALGs you can think of already exist and we get to leave that problem behind when we turn off IPv4. Also, not unimportant: it allows IPv4-only applications to work trivially. Another advantage is that hosts with different needs can get different classes of tunneled IPv4 connectivity even though they happen to live on the same subnet, something that's hard to do with native IPv4. That's a wonderful solution, and you should feel free to use it. It's particularly fun from a support perspective, because you get to be involved all the way down the host level. A lot of ISP's don't want to be involved in supporting *anything* all the way down to the local host level, and want a simple method for connecting new customers via IPv6 while offering some form of legacy connectivity to rest of of the (IPv4) Internet. You're asserting that they shouldn't be allowed to use NAT-PT for this purpose, despite the fact that it meets their needs? /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 12:56 PM -0500 10/1/07, Stephen Sprunk wrote: ... The fundamental flaw in the transition plan is that it assumes every host will dual-stack before the first v6-only node appears. At this point, I think we can all agree it's obvious that isn't going to happen. NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost. It allows v6-only hosts to appear even if there still remain hosts that are v4-only, as long as one end or the other has a NAT-PT box. The chicken and egg problem is _solved_. When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally. The alternative is that everyone just deploys multi-layered v4 NAT boxes and v6 dies with a whimper. Tell me, which is the lesser of the two evils? Stephen - Very well said... Now the more interesting question is: Given that we're going to see NAT-PT in a lot of service provider architectures to make deploying IPv6 viable, should it be considered a general enough transition mechanism to be Proposed Standard or just be a very widely deployed Historic protocol? Oh wait, wrong mailing list... ;-) /John
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
At 3:11 PM -0400 10/1/07, [EMAIL PROTECTED] wrote: So it boils down to Do you think that once that camel has gotten its nose into the tent, he'll ever actually leave?. (Consider that if (for example) enough ISPs deploy that sort of migration tool, then Amazon has no incentive to move to IPv6, and then the ISP is stuck keeping it around because they don't dare turn off Amazon). If indeed one believes that's there more functionality for having end-to-end IPv6, then presumably their competitors will roll out services which make use of these capabilities, and Amazon will feel some pressure to follow. Operating through NAT-PT is not very exciting and it's not going to take much (e.g. quality video support) to cause major content providers to want to have native end-to-end communication. Amazingly, it creates an actual motivation for existing IPv4 content sites to considering adding IPv6 support, which is something we've lacked to date. /John
Rings done right (was: Re: Bee attack, fiber cut, 7-hour outage)
Has anyone calculated what the cost of doing this correctly once vs the ongoing support/SLA/etc issues of repairing it when it goes boom is? I've gotta believe that for 90% of the situations where diverse routes exist, just being used as dual linear paths, its cheaper in the long term to do it right and cut the size of your outside plant crew (assigned to break/fix) by 90%. :) It is definitely cheaper to do it right the first time, but to keep it right, the operator needs to pay very close attention to each and every circuit groom that they perform, less they end up with a degenerate loop somewhere. Depending on the state of their circuit routing database(s), the exercise of checking for overlap against the other half of the ring can anywhere from trivial to impossible. I don't think operators intentionally foul this up, but it's real easy to get wrong, particular in the fallout after accumulating a bunch of different companies fiber plants and circuit route systems and trying to consolidate everything for savings. I'm just providing this in answer to why can't telcos get this right, as there's no reason to think that grooming activity was at all involved in why this particular carrier got stung... ;-) /John
Re: Apple Airport Extreme IPv6 problems?
At 4:47 PM -0400 9/17/07, Martin Hannigan wrote: On 9/17/07, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 17-sep-2007, at 19:06, Martin Hannigan wrote: Getting back to my original discussion with Barrett, what should we do about naming? I initially though that segregating v6 in a subdomain was a good idea, but if this is truly a migration, v4 should be the interface segregated. For debugging purposes, it's always good to have blah.ipvX.example.com, but the real question is: do you feel comfortable adding records to your production domain names? Although I've been running that way for years and I've had only one or two complaints during that time, I can see how someone could be worried about reduced performance over IPv6 (it's still slower than IPv4 a lot of the time because of tunnel detours etc) or even timeouts when advertised IPv6 connectivity doesn't work for someone, such as a Vista user with a public IPv4 address behind a firewall that blocks protocol 41. Then again, I'm guessing that few people type www.ipv6.google.com rather than www.google.com. And with stuff like mail, where you set up the server names once and forget about it, it's even worse. I see. There isn't really an answer. :-) That's what I am getting at. Not to suggest that this is your responsibility, it's not - it's ours. For now, I'm going to try the unique A/ and segregate the answers by protocol and sub domain the v4 traffic since it's a migration to v6. -M
Re: Apple Airport Extreme IPv6 problems?
At 1:06 PM -0400 9/17/07, Martin Hannigan wrote: Getting back to my original discussion with Barrett, what should we do about naming? I initially though that segregating v6 in a subdomain was a good idea, but if this is truly a migration, v4 should be the interface segregated. RFC 4472 has an excellent discussion of the topic, and while pointing out that your mileage may vary, it recommends the on the same name only when: 1. The address is assigned to the interface on the node. 2. The address is configured on the interface. 3. The interface is on a link that is connected to the IPv6 infrastructure. In addition, if the record is added for the node, instead of service as recommended, all the services of the node should be IPv6- enabled prior to adding the resource record. Not a problem for names which are single services (www.foo.com), but caution is required when the name has multiple services running. /John
Re: Congestion control train-wreck workshop at Stanford: Call for Demos
At 9:21 PM -0400 9/3/07, Joe Abley wrote: Is there a groundswell of *operators* who think TCP should be replaced, and believe it can be replaced? Just imagine *that* switchover, with the same level of transition planning as we received with IPv6... ;-) /John
Re: Congestion control train-wreck workshop at Stanford: Call for Demos
At 7:40 PM -0700 9/3/07, Joel Jaeggli wrote: John Curran wrote: At 9:21 PM -0400 9/3/07, Joe Abley wrote: Is there a groundswell of *operators* who think TCP should be replaced, and believe it can be replaced? Just imagine *that* switchover, with the same level of transition planning as we received with IPv6... ;-) The congestion control mechanism can be replaced independent of the transport. In point of fact linux systems have been using bic-tcp by default since 2004 and nobody noticed... Backwards compatibility is a good thing (and what was not a achieved in the IPv6 case despite repeated claims to the contrary...) /John p.s. bic-tcp (and cubic) certainly have been noticed... We first examined the scenario in which a long-lived Standard TCP and a high-speed transport protocol flow coexist. We observed the well- known unfairness problem: that is, a highspeed transport protocol flow starved the long-lived Standard TCP flow for bandwidth, ... (K. Kumazoe, K. Kouyama, Y. Hori, M. Tsuru, Y. Oie, Can highspeed transport protocols be deployed on the Internet? : Evaluation through experiments on JGNII, PFLDnet 2006, Nara, Japan.) We really don't know how well windows hosts (or Vista hosts with CTCP) actually perform on a shared network of bic-tcp systems.
An informal survey... round II
So with a fairly predictable growth of 3500 routes per month, we're going to have some issues with the current equipment out there (despite this being a rather predictable situation...) So what might happen in three years if we have a sudden inflection in new routes per month due to use by major backbones of non- hierarchically allocated address space for new customer additions? I.E. If at some time unknown around 2010, ISP's stop receiving new allocations from their RIR, and instead use of many smaller recycled IPv4 address blocks, we could be looking at a 10x to 20x increase in routes per month for the same customer growth. Is the equipment being installed *today* and over the next two years capable of sustaining 50K new routes per month, and if so, for how long? Thanks, /John At 4:47 AM + 8/30/07, [EMAIL PROTECTED] wrote: On Wed, Aug 29, 2007 at 06:48:43PM -0400, Jon Lewis wrote: On Mon, 27 Aug 2007, David Conrad wrote: For a few more months. What are upgrade cycles like again? How common are the MSFC2s? I think we'll find out in a few months, when the internet breaks in a whole bunch of places where the admins aren't aware of this issue or operations have been downsized to the point that things are mostly on auto-pilot. I'm guessing there are a good number of Sup2's in use, and that a good % of them think they're fine...as they have 512MB RAM and on the software based routers, that's plenty for current full BGP routes. private replies suggest (w/ lots of handwaving) that perhaps 20-35% of the forwarding engines in use might fit this catagory. Anyone want to bet there will be people posting to nanog and cisco-nsp in a few months asking why either the CPU load on their Sup2's has suddenly shot up or why they keep noticing parts of the internet have gone unreachable?...oblivious to this thread. that would be a sucker bet -- Jon Lewis | I route --bill
Re: An informal survey... round II
At 9:12 AM -0400 8/30/07, William Herrin wrote: On 8/30/07, John Curran [EMAIL PROTECTED] wrote: I.E. If at some time unknown around 2010, ISP's stop receiving new allocations from their RIR, and instead use of many smaller recycled IPv4 address blocks, we could be looking at a 10x to 20x increase in routes per month for the same customer growth. John, Why should we announce tiny recycled blocks? If there is a /16 in the swamp in which half the space is free but its all /24's, why wouldn't wouldn't we allocate all the free /24's to a single entity and instruct the entity to announce it as a holey /16? The existing /24 holders will override (punch holes in) the /16 for their /24's. Consider large ISP's that can no longer obtain from the large blocks (e.g. /12 to /16) but instead must beg/barter/borrow blocks from others which are several orders of magnitude smaller (e.g. /16 through /24) every week to continue growing... such obtained blocks would be announced into the routing system very rapidly as we try to keep IPv4 running post depletion of the free address pool. When this inflection point is reached, how much headroom do we have given equipment being deployed today? /John
Re: An informal survey... round II
At 2:14 PM -0400 8/30/07, Deepak Jain wrote: John -- Great panic starting question. Sorry, not my intent. I'm just trying to get a handle on the state of the art of what's available today, and whether it has some really excellent scaling properties in case we see a much more granular block reuse. It's by no means inevitable, just a probable outcome of any routing-indifferent IP address space market (whether legitimate or not). I'd guess that by 2010, we'll be worried more about IPv6 growth than IPv4 growth but the archives will bite me in the you-know-where in 3 years when I'm wrong (in either direction). I'd love to believe that, but there's real world issues with IPv6 readiness as well as challenges communicating the business need to make the necessary preparations. When we're all still debating in technical fora the need to move to IPv6 versus viability of a heavily NAT'ed IPv4 endgame, you can't expect the folks in boardrooms to commit to any large investment decisions. /John
Re: 2M today, 10M with no change in technology? An informal survey.
At 8:50 PM -0400 8/27/07, Jon Lewis wrote: Unlike Y2K, the end of the useful service life up the Sup2 can easily be pushed further away in time. ASnum NetsNow NetsAggrNetGain % GainDescription There's really only 151129 routes you need to have full routes. Forcing just these top 4 slobs to aggregate reduces your global table by 3619 routes. Forcing the top 30 to aggregate frees up 15809 routes. That's an additional ~5 months at the current rate of new routes (and current ratio of customers per new routed block.) There's a lot more than 3500 new customers per month globally and if we get to the point where they are not coming out of hierarchical PA space, the new monthly routing growth will increase dramatically. /John
Re: An Internet IPv6 Transition Plan
At 2:01 PM +0100 7/26/07, Stephen Wilcox wrote: well, the empirical data which is confirmed here is saying that those 10% are burning most of the v4 addresses and we are not seeing them rollout v6 whether they 'need to' or not Wow... you mean that they're not announcing general IPv6 availability two years before they have to? I'm so surprised. ;-) so you sound right in theory, but in practice your data doesnt show that is occuring and it also suggests those 10% are actively supporting 'the wall' approach. The number of major backbone operators looking into IPv6 is already quite high, and will likely approach 100%. The alternative is carriers having to explain to the analyst community that they lack a business plan for new data customer growth once large IPv4 blocks are no longer generally available. /John
Re: An Internet IPv6 Transition Plan
At 11:18 AM +0100 7/26/07, Stephen Wilcox wrote: um, so thats consistent with what i said.. in fact it implies only a very small number of organisations need to pay close attention and those are the ones best suited to implementing policy changes to ensure their users continue to have a good service this means 90% of orgs can probably wait and see what the 10% do first.. Completely incorrect. In order that we can continue to have reasonable routing growth during new customer add, those 10% need to move to IPv6. While you don't have to move your entire infrastructure to IPv6, you need to add IPv6 to the public-facing servers that you'd like to still be Internet connected. /John
Re: An Internet IPv6 Transition Plan
At 11:52 AM +0100 7/25/07, Stephen Wilcox wrote: On Tue, Jul 24, 2007 at 09:34:01PM +0100, [EMAIL PROTECTED] wrote: However, what I'm trying to understand is why the motivation to rapidly go from v4 to v6 only? What are the factors I'm missing in operating v4/v6 combined for some time? Growth. Lack of IPv4 addresses will put the brakes on growth of the Internet which will have a major impact on revenue growth. Before long stock market analysts are going to be asking tough questions, and CEOs are suddenly going to see the IPv6 light. What exactly will cease to grow tho? The 4 billion IPs that have always been around will continue to be. I think you overestimate the effects.. All the existing big businesses can operate with what they already have, Google and Yahoo are not going to face any sort of crisis for the foreseeable future. And as I've been saying for a while and Randy put in his presentation, supply and demand will simply cause the cost of having public IPs to go up from zero to something tiny - enough to see IPs being put back into the pool to those who really need them. Steve - Putting them back into circulation doesn't work unless its done in very large chucks to major ISPs. If this isn't the model followed, then we will see a lot more routes for the equivalent number of new customers. People complaining about the ability to carry both IPv6 and IPv4 routing need to think carefully about how long we'll actually last if the ISP's are injecting thousands of unaggregatable routes from recovered address space each day. Additionally, the run rate for IPv4 usage approximates 10 /8 equivalents per year and increasing. Even given great legacy recovery, you've only gained a few more years and then still have to face the problem. /John
Re: An Internet IPv6 Transition Plan
At 12:30 PM +0100 7/25/07, Stephen Wilcox wrote: Hi John, I fully agree on that.. but I am disagreeing as to the timescales. There is some opinion that when IANA hands out the last of its IP blocks things will change overnight, and I dont see any reason for that to be the case. I think there are a lot of IPs currently allocated to ISPs but as yet unassigned to customers, and I think there will be a lot of policy changes to make more efficient use of the space that is already out there - I specifically think that will come from ISPs reusing IPs and setting costs that ensure they continually have IPs available to customers willing to pay for them. In the ARIN region, we've got major ISP's coming back every 6 months with high utilization rates seeking their next block to allow customer growth. While I'm certain that some internal recovery is possible, there's a realistic limit of how long any ISP can make their air supply last. I think the combined effect of these things means - we will not be running into a wall at any time - availability of IPs will slowly decrease over time (as cost slowly increases) - adoption of NAT and v6 will be an ongoing trend with no sudden increase Unless the policy changes you suggest somehow dramatically change the current usage rate, we're going to have a very serious rate of change when the IANA/RIR pool hits zero. That sort of defines hitting a wall, by my definition. Please propose the magical policy changes asap... we need to get them through the public process and adopted in record time to have any affect on the usage rate. This means no end of the world as we know it, and no overnight adoption of new technology.. just business as usual in an evolving environment. Note: I'm not advocating an overnight technology deployment; just advising those folks who presently rely on continuous availability of new address blocks from the RIR's that we're going to see a change. At present, there's a few years for these folks to switch to IPv6 for their growth. It requires cooperation from the Internet, in that we all need to recognize that there will be IPv6 customers out there soon, and even if you don't plan on having those, please make your public facing servers IPv6 reachable in the next few years. /John
Re: An Internet IPv6 Transition Plan
At 2:02 PM +0200 7/25/07, David Conrad wrote: This assumes consumption patterns remain the same which is, I believe, naive. In a world where you have to pay non-trivial amounts for address space utilization, people will only use the address space they actually need and you'll see even more proliferation of NAT for client-only services. I believe that we'll see extensive use of NAT for client-only services (just look at many broadband residential services today), but that won't help business customers who want a block for the DMZ servers. They'll pay, but the question is whether they can afford the actual global cost of routing table entry, or whether it will even be accountable. ISP's can figure out the cost of obtaining IPv4 blocks, but the imputed cost of injecting these random blocks into the DFZ routing table is harder to measure and inflicted on everyone else. /John
Re: An Internet IPv6 Transition Plan
At 1:15 PM +0100 7/25/07, Stephen Wilcox wrote: At present, there's a few years for these folks to switch to IPv6 for their growth. It requires cooperation from the Internet, in that we all need to recognize that there will be IPv6 customers out there soon, and even if you don't plan on having those, please make your public facing servers IPv6 reachable in the next few years. I'm not sure there is time for v6 to be ready before companies find different ways to manage this. There are many things that need to happen to enable v6 and I dont think any of them are happening in a big way. Whether the large CDNs deploy v6, if v6 can be purchased in volume as transit are likely to be the major factors.. Steve - Are you unable to make your public facing servers IPv6-reachable? /John
Re: An Internet IPv6 Transition Plan
At 1:15 PM +0100 7/25/07, Stephen Wilcox wrote: I'm not sure there is time for v6 to be ready before companies find different ways to manage this. There are many things that need to happen to enable v6 and I dont think any of them are happening in a big way. Let's agree on 18mo-4yrs of 'greyness' (as you put it), and that indeed different companies find different ways to manage this... Some of the companies are going to select IPv6 because it's has some level of support in existing end systems and network gear (even considering the various implementation flaws, lack of hardware support, etc), and because it supports a generally hierarchical addressing/routing model which works (again, despite recognition that the routing system has some serious long-term scalability questions which need to be looked into). For their choice to work, it's necessary that your public-facing servers accept IPv6 connections. It's really not a hard concept, and it's based on the simple premise stated by Jon: In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. You've stated a long list of items that need to be changed, but that's if you want to serve as an ISP using IPv6 for customers, and change your internal infrastructure to IPv6, and that's not required. You've already said you are going to take another path to manage things, and that's cool. The question is whether you still recognize the need to deploy IPv6 on the very edge of your network for your public services such as web and email. You could even have someone host this for you, it's not that hard, and there's two to 4 years to get it done. If you're saying that no one at all needs to use IPv6, so you aren't going to worry about IPv6 connectivity for your public facing servers, then it would be best to explain how global routing is supposed to work when ISP's aren't using predominantly hierarchical address assignments for their growth. /John
Re: Why do we use facilities with EPO's?
At 12:07 PM -0400 7/25/07, Leo Bicknell wrote: 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. For high-availability sites (Tier III, Tier IV per UpTime Institute), EPO's are one of the most common reasons for outage. I'd highly recommend APC's paper http://www.apcmedia.com/salestools/ASTE-5T3TTT_R2_EN.pdf on the topic. Short-version is that its a safety issue for room occupants and responders. More mature codes tend to require such, particularly in the presence of UPS gear which can be energized unbeknownst to fire fighting personnel. If you don't have water-based fire suppression, have normally unoccupied spaces, and are continuously manned, it's sometimes possible to pass on having an EPO. YMMV by inspector. /John
RE: An Internet IPv6 Transition Plan
Alain - Present residential broadband Internet service is provide the customer with access to/from any public-facing IPv4-based resource Around 2011 (date for discussion purpose only) residential broadband Internet service is provide the customer with access to/from any public-facing IPv6-based Internet resource The specific vision of how to provide such service is left to the provider. The Internet/IAB/IETF/ICANN/ISOC/... history does not proscribe such items as prefix size, static versus dynamic addressing, management models, minimal security, or much else for that matter... It's entirely left to the service provider. There's certainly suggestions, both direct (such as filtering for end-site devices) and indirect (embedding a /48 endsite assumption into the addressing scheme), but at the end of the day its up to the service provider to make their own design tradeoffs and let the market decide if they're right. This overall transition plan simply states that you might want to provide customers with access to sites which are served by IPv6-only sometime around 1 Jan 2011. The will be particularly useful to ISP's who may (for lack of any choice) be using IPv6- only to provide Internet service, and would prefer to be making faithful representations that sites connected in this manner are reachable by everyone out there. This isn't a very hard concept. ISP's will not have access to the previously deep pool of IPv4 address blocks that have allowed their ongoing growth in the past. Continuation of the ISP industry is predicated on enabling IPv6 for public-facing sites over the next few years. /John At 1:41 AM -0400 7/24/07, Durand, Alain wrote: John, Thank you for writing this down, this will help start the discussion. One of the things that is missing IMHO is that there is no clear vision of what the IPv6 Internet will/should looks like. Let me focus on the residential broadband for a minute, I'm fully aware there are other cases, but let's start somewhere. 1) What is the IPv6 'service'? For example, is it reasonable to define a 'basic' level service as web+mail and an 'extended' service as everything else? Random ideas include for example offering a lower cost 'basic' service with v6 that would be 'proxied' to the rest of the v4 Internet 2) What is the connectivity model in IPv6 for the residential customer? 1 address versus prefix delegation? what prefix size? is this prefix 'stable' or 'variable' over time? (ie renumbering is expected) (note: the answer to this question has huge implications) What types of devices are connected? PCs or appliances or sensors? What is the management model in the home? (how much all of this has to be controlable by the user vs made automatic?) Are there 'servers' (ie things that answers connections from the outside) in the home? Is there any kind of DNS delegation happening to the home? 3) What is the security model of all this? I just listened today half mistified to a presentation at IETF that was saying that the 'recommended' deployment model in the home is to put a NAT-like stateful firewall in the home gateway... This would mean that IPv6 would have to inherit all the NAT-traversal technologies from IPv4 to work... Is this really what we want? 4) What about the 'legacy' devices that cannot upgrade to IPv6? What kind of service is expected for those? Does defining an 80% type solution as in 1) take care of them? IMHO, until there is a better understanding of the answers to those questions (and many more I'm sure) to describe what the brave new world of IPv6 looks like, it will be difficult to define any Internet scale transition plan... My $.02 - Alain.
An Internet IPv6 Transition Plan
Folks - There's quite a few IPv6 transition technologies, each with its own camp of supporters based on particular world view of the hardest easiest system elements to change. One of the challenges this poses is that it's very easy to get caught up in the various transition approaches and miss the high-level view of what needs to be accomplished. In an effort to communicate one possible transition plan in a technology agnostic manner, I've written an Internet draft which highlights the expectations that organizations could face over the next few years: http://www.ietf.org/internet-drafts/draft-jcurran-v6transitionplan-00.txt I'd be interested in hearing any and all feedback from the NANOG community on this draft; feel free to send such privately if you'd prefer a degree of anonymity, or have the urge to use language inappropriate in public... ;-) Thanks! /John
Re: An Internet IPv6 Transition Plan
At 10:59 PM -0500 7/23/07, Randy Bush wrote: wilbur: we need to fly though the air! orville: easy, let's make a machine, and we can call it an airplane wilbur: that's cute, but HOW WILL IT WORK? In the references section, you'll find a number of RFC's and ID's which propose answers on how will this work for particular sites (such as enterprise, campus, etc). The reality is that the world is far more diverse than a few RFC's can depict, and further that we don't have a lot of folks with real world experience (yet) who can provide feedback on the viability of these plans. Rumor has it that this will change over time... /John
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
At 9:59 AM -0700 6/28/07, Randy Bush wrote: If you have a plan for continued operation of the Internet during IPv4 depletion, please write it up as an RFC. if you have a simple and usable plan for ipv6 transition, please write it up in any readable form! randy Will do, /John
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
At 6:09 PM +0100 6/28/07, Stephen Wilcox wrote: Hi John, I am not offering an elegant technical solution that would be worthy of an RFC number! :) But I am saying that the Internet of today will evolve organically and that there are a number of ways you can get by with what we have for a long time until things get really ugly. Interesting... We likely differ on how long a long time is, and definitions of what happens when things get really ugly. Justin suggested that ISPs will be hit first because they are the distributors of IPs and when they cant go back for more they will be in trouble. I can turn that around tho, as an ISP if I cant get more IP space but I have customers who NEED public IPs and are willing to pay I will just 'find' some.. if I charge a small nominal monthly fee per IP or start pushing my DSL base onto NAT rather than static or dynamic public IPs I'm sure I can quickly free up a significant portion of IPs that I can capitalise on. You can, and this will work for a while. When it stops working (which is not at all predictable) you're going to need a fairly sizable IPv6 Internet so that you can continue to connect new customers up, and unfortunately, that means we need to start getting folks moving ahead of time since we don't exactly know how long your workarounds will last. I still dont believe the current Internet is a hierarchy. Theres something like 25000 ASNs out there with maybe 3000 of them interconnecting in a serious way (ie peering). If that were a corporate org chart you'd be describing it as flat not hierarchical! I'm guessing we've got tens of millions (if not hundreds of millions) of organizations connected to the Internet, and that's being done with 25000 ASN's and 40 routes... That's absolutely the result of hierarchical provider assigned addressing in extensive use. /John
Re: IPv6 transition work was RE: NANOG 40 agenda posted
At 7:16 PM -0400 6/3/07, Igor Gashinsky wrote: Again, we are working on it, Good to know... it is much harder then it seems, my views are my own, I'm not in any way speaking for my employer, ... Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market... /John
Re: Interesting new dns failures
At 5:30 AM + 5/21/07, Fergie wrote: Why not? The Registrars seem sto being doing a great job of expediting the activation of new domains -- why can't they de-activate them just as quickly when they find out they are being used for malicious purposes? The business interests of the registrars, that's why. Not to defend those doing malicious things, or service providers that consciously hide such for money, but there is another reason why removal/blockage/filtering/etc doesn't always happen in a timely manner, and that's the legal liability. In larger organizations, the potential for liability can result in a real administrative burden of paperwork before getting the green light to terminate. I don't know if that's the case here, but would recommend against jumping to greed as the only possible reason for hesitation in moving against such folks. /John
Re: Paul Vixie: Suspected Arms Dealer
Almost, but DNSSAFE followed by friendlier export laws kept him an honest man... :-) /John
Re: Colocation in the US.
At 3:49 PM -0800 1/24/07, Mike Lyon wrote: I think if someone finds a workable non-conductive cooling fluid that would probably be the best thing. I fear the first time someone is working near their power outlets and water starts squirting, flooding and electricuting everyone and everything. http://en.wikipedia.org/wiki/Fluorinert /John
Re: Collocation Access
At 12:15 AM -0500 12/28/06, Jim Popovitch wrote: At the risk of dragging this to the nth degree... it's already been established that the ID yahoos have no idea on what a real ID looks like vs a false ID (esp considering all the possible combinations of ID). That's certainly true in many cases, but not always. For those folks that do an offline verification of state-issued drivers license/photo ID's, they provide a relatively solid anchor for authentication. Again, this doesn't imply anything about authorization, but you've at least got a strong basis for believing that you are dealing with person so named. /John
Re: Collocation Access
At 3:03 PM -0500 12/28/06, Marshall Eubanks wrote: ... FE goes to colo (where he has been removed from the access list). Shows ID to guards, who knew him well, and is let in, list or no list. ... The FE got the money he wanted. The client got their router back. I am not sure if the guards were reprimanded or not. Client informs colo provider that they were negligent by allowing the theft, and deducts the replacement cost from next invoice? /John
Re: IP adresss management verification
At 10:35 PM +0800 11/13/06, Kanagaraj Krishna wrote: Hi, I'm curious on how regional RIR which allocates ip address, verifies the usage pattern info provided by their members in their application process. Same as other most other filings: A signed and notarized statement from a company officer, with third party audit from an established accounting firm... Wait, I'm using 2012 guidelines. ;-) Use Michael Dillon's answer for now. A more interesting question might be: How does the community think an RIR should best verify information in the application process today, and should that change as we approach the IPv4 event horizon? /John
RE: Collocation Access
At 1:07 PM -0400 10/23/06, Alex Rubenstein wrote: What I've never understood is, that, how a gov't issue ID (for the purposes of allowing entry) is of any use whatsoever. It's not as if someone is doing a instand background check to know if the person is a criminal, or wanted, or whatever. It's trivial to forge a gov't ID. I'll disagree; it's rather challenging to create a state drivers license or state ID card which will also pass third-party database verification. Hence, a requirement for such an ID supplied in advance with enough time to verify it provides a very solid basis of identification. (As smb noted, it says nothing at all about authorization, but that's a different problem which one can address after you have a high enough certainty for identification). /John
Re: New router feature - icmp error source-interface [was: icmp rpf]
At 9:22 AM -0400 9/25/06, Patrick W. Gilmore wrote: Who thinks it would be a good idea to have a knob such that ICMP error messages are always source from a certain IP address on a router? It certainly would beat the alternative of no response at all, but one would hope it wouldn't become common practice since it reduces the information returned (e.g. during a traceroute, you'd lose the sometimes useful information from in-addr about what particular interface was involved). /John
Re: kW Per Rack.
At 4:20 PM -0700 9/13/06, Robert Sherrard wrote: How many of you are currently cooling 7kW+ per cabinet.. are any of you cooling more than 15kW per rack, if so how large is your footprint? Are any of you using water cool racks, by tapping into house water? We're doing 7kW per cabinet via forced chilled air ducted directly into the top of hollow-post racks with ventilation slots opened on forward/side/back depending on the specific equipment needs. Air return is drawn off the structural floor (no raised floor) by computer room air chillers and then back into the duct system. We could increase density but only because the room is completely sealed with only penetrations for fiber, power, and chilled water loops. With a traditional raised-floor environment, you're in a very difficult situation at 15kW (~500 w/sqft). There's a couple of facilities in Northern VA with such a design point, but they very custom with 4 to 5 foot raised-floor due to the airflow. Water cooling to the rack (or at least to the aisle) almost required at that point. /John CTO, ServerVault
Global Crossing/Ashburn - Anyone have RFO or ETA insight?
Folks - Since sometime early this morning, some traffic through Global Crossing in Ashburn has been experiencing packet loss and varying latency consistent with congestion. Global crossing's NOC confirms there is an multiple customer issue, but can't/won't/doesn't-know anything with respect to reason for outage or time to repair... Is anyone working on the other end of the problem who can share some insight? Thanks in advance; sorry to bother the list with operational matters... :-) /John
Re: Global Crossing/Ashburn - Anyone have any SYMPTOMS?
Randy - I actually intentionally didn't post the details or ticket number, as I was looking for other folks already involved (once their NOC said it was a multiple customer issue with the ar2.dca2 router). If you're also affected or engaged on the problem, let me know. Thanks! /John At 5:41 PM -0700 6/21/06, Randy Bush wrote: john: on ops channel, gx senior eng says: o gx backbone crew knows of no multi-cust outage o gx noc knows of nomulti-cust outage so i very much doubt anyone on this list will have an eta for something no one seems to know about. maybe, rather than a public slam with no content, post some symptoms so someone can actually work on it. net geeks don't mind work, just need hard stuff on which to work. randy
Re: data center space
At 9:36 PM -0400 4/19/06, Martin Hannigan wrote: Remember when folks thought Exodus was crazy for 220w per square foot? 265w/sqft can just handle today's typical blade server power density (allowing for a reasonable amount of wire management and slightly less than full blade loading). If you look at the densities of newly released blade servers, it is not hard to hit 300w+ / sq ft.The more amusing part is those attempting to cool this via raised floor systems, as it takes 24 to 30 of raised floor to achieve the necessary airflow, and this is only going to get worse. /John
Re: Could someone from the U.S. DoD contact me.
Lanny - Refer to http://www.first.org/about/organization/teams/dod-cert/ Call the number and enter 0, 1, or 2 depending on incident type. Feel free to contact me (@ +1 617 512 8095) if that doesn't address your need and you have an active incident that you believe to be DoD origin. I am not a contact but can certainly find you one. /John At 3:00 PM -0700 4/2/06, L. Jason Godsey wrote: Could someone from U.S. DoD contact me off list? I've been trying to report what looks like a security problem. I keep getting the run around and transfered to public affairs type mail boxes which end up not working or being full.
Re: XO Connectivity
I believe David's issue was local and has been resolved. /John At 7:15 PM -0500 3/17/06, Steve Sobol wrote: On Thu, 16 Mar 2006, David Coulson wrote: Is anyone seeing issues with XO? We've been seeing some strange BGP resets over night and only about 10% of our routes are best pathed through them (usually more like 40%), even after we reset sessions to other carriers... Not out here, things seem normal. I'm on a Verizon DSL line but have had no trouble getting to any of our biggest clients' sites, most of which sit on XO broadband (either DSL or T1). -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
Re: shim6 @ NANOG
At 1:08 PM -0800 3/6/06, Owen DeLong wrote: I've got no opposition to issuing addresses based on some geotop. design, simply because on the off chance it does provide useful aggregation, why not. OTOH, I haven't seen anyone propose geotop allocation as a policy in the ARIN region (hint to those pushing for it). Does anyone have statistics for the present prefix mobility experiment in the US with phone number portability? It would be interesting to know what percent of personal and business numbers are now routed permanently outside their original NPA assignment area... If one presumes a modest movement rate across the entire population of businesses, and locality for some percent of those moves (which may be hidden from global visibility due to regional interconnects/exchanges), would the resulting global routing table really be any larger then the current AS allocation count? It certainly would result in a lot of happy businesses to have a PI allocation from a local LIR, even if portability wasn't assured if they relocated to another state. /John p.s. personal thoughts only, designed entirely to encourage discussion... :-)
Re: Transit LAN vs. Individual LANs
At 4:03 PM -1000 2/24/06, Scott Weeks wrote: I have 2 core routers (CR) and 3 access routers (AR) ... Optimal solution is to dual-home each AR via PTP links into the CR's. This has the simplest topology, fewest components, highest throughput, and highest availability. The only reason not to do this would the if you have poor pricing on the CR ports or need a larger number of them: Dual-home via PTP: 2 CR ports per AR Dual-home to switched LANs: 4 CR ports + switches If you know you are going to have just a handful of AR's and have reasonable CR port costs, then the costs will be similar and you should take the PTP approach. /John
Re: and here are some answers [was: Quarantine your infected users spreading malware]
At 12:26 PM +0100 2/21/06, Jim Segrave wrote: The philosophical discussion aside (latest one can be found under zotob port 445 nanog on Google), presenting some new technologies that shows this *can* be done changes the picture. http://www.quarantainenet.nl/ From the web site: Only a selected set of web sites will remain available, for example Microsoft update and the websites of several anti-virus software companies. The quarantine server tells users what is going on and how this problem can be resolved. One hopes that the Apple web site and online credit form is included in the list... ;-) /John
Re: and here are some answers [was: Quarantine your infected users spreading malware]
At 7:45 AM -0500 2/21/06, John Curran wrote: From the web site: Only a selected set of web sites will remain available, for example Microsoft update and the websites of several anti-virus software companies. The quarantine server tells users what is going on and how this problem can be resolved. One hopes that the Apple web site and online credit form is included in the list... ;-) Alright, in fairness to MSFT, a pointer to Vista/Longhorn (once available) and instructions to only enter your Admin password during bona fide sw installations would also go a long way towards preventing recurrence... :-) /John
Re: MPLS vs PTP
At 10:32 AM -0800 1/30/06, Andrew Staples wrote: As we roll out a new network, on one of our links it is remarkably cheaper to run a T1 ptp vs. MPLS (running 66% data, 33% voice). Based on comments received from this list (much thanks, you know who you are) MPLS satisfaction seems to be determined by backbone noc competence, not the technology itself. So back to priceif I consider layer1 issues to be equal in either scenario, and aggregation/meshing/hardware is not a real concern, it seems to me that a correctly configured, directly connected pipe would work as well as mpls, with the benefit of local control of my routers and owning any incompetence. As long as you're referring to PTP with the voice packetized in some manner (so as to effectively achieve dynamic bandwidth allocation which you can get with multiple LSP's), then your tradeoff summary is on target. If you are looking at PTP TDM solution with fixed allocation, the PTP alternative wastes any idle voice bandwidth which would otherwise be available for data. /John
Re: the iab simplifies internet architecture!
At 7:10 PM -1000 11/10/05, Randy Bush wrote: reported from tonight's iitf iab (internet archetecture board) plenary. proclaimed by an esteemed iab member from the podium: it is bad in the long term to add hierarchy to routing this will save a lot of work. whew! That is exceptionally good news! It follows that all IPv6 assignments for end-users can therefore be a /64... ;-) /John
Re: cogent+ Level(3) are ok now
At 12:27 PM + 11/1/05, Stephen J. Wilcox wrote: Hi John, Even with cold-potato routing, there is an expense in handling increased levels of traffic that is destined for your network. This increase in traffic often has no new revenue associated with it, because it is fanning out to thousands of flat-rate consumer/small-business connections (e.g. DSL) where billing is generally by peak capacity not usage. not true for cogent tho, we know that virtually all their traffic is usage based transit customers The traffic from Cogent creates additional infrastructure requirements on L3. L3 may (or may not) be able to recover these costs as incremental revenue from the recipients, depending on the particulars of their agreements. One way of mitigating their exposure is to set an upper bound on uncompensated inbound traffic. Mind you, this is entirely hypothetical, as specifics of the Cogent/L3 agreement are not available. However, it is one way to let everyone bill and keep for Internet traffic without an unlimited exposure, and it is an approach that has been used successfully in the past. /John
Re: cogent+ Level(3) are ok now
At 9:40 AM -0500 11/1/05, Patrick W. Gilmore wrote: I think everyone agrees that unbalanced ratios can create a situation where one side pays more than the other. However, assuming something can be used to keep the costs equal (e.g. cold-potato?), Cold-potato only addresses the long-haul; there's still cost on the receiving network even if its handed off at the closest interconnect to the final destination(s). I do not see how one network can tell another: You can't send me what my customers are requesting of you. Depeering seems to say exactly that, no? If your business model is to provide flat-rate access, it is not _my_ responsibility to ensure your customers do not use more access than your flat-rate can compensate you to deliver. Agreed... I'm not defending the business model, only pointing out that some folks may find it easier to bill their peers than customers. /John
Re: cogent+ Level(3) are ok now
At 12:56 AM -0400 10/29/05, Daniel Golding wrote: I have no specific information, but I'm guessing there is a per-mbps charge that kicks in at certain ratio levels. ... I'm having a bit of trouble figuring out Level(3)'s goal in all this. A bit of incremental revenue? For all of this trouble? I could understand feeling that Cogent's ratios are a violation of their peering requirements and depeering them on principle, but if that's the case, why back down for a little cash? I do not have any information on this particular arrangement, but can speak to one possibility... Even with cold-potato routing, there is an expense in handling increased levels of traffic that is destined for your network. This increase in traffic often has no new revenue associated with it, because it is fanning out to thousands of flat-rate consumer/small-business connections (e.g. DSL) where billing is generally by peak capacity not usage. It's also true that some of the most popular Internet destinations will receive transit at bargain rates because of their relative size and buying power. A settlement fee that kicks in only on egregious ratios allows one to more freely interconnect without bearing the full cost burden should the traffic become wildly asymmetric. /John
Re: Level 3's side of the story
At 9:37 PM -0400 10/8/05, Christian Kuhtz wrote: On Oct 8, 2005, at 6:43 PM, John Curran wrote: What I have said that there is *significant* attention to the potential consumer impact of our non-essential IP services, and that's not surprising given the historic public policy in this area. I pointed to the bill under draft merely as documentation of this attention and to note that unless there is a radical shift in policy for telecom consumer protections, we are going to see some form of regulation as more voice moves to the Internet. Perhaps. Your presumption for such prediction is that service will not evolve in a disruptive fashion. No, my prediction is based solely on the current actions of lawmakers to address the perceived social need of reliable phone service. If laws are passed, it's highly likely that the FCC will regulate accordingly, regardless of how amusing the mapping from regulation to reality turns out. /John
Re: Level 3's side of the story
At 4:41 PM -0700 10/7/05, william(at)elan.net wrote: BTW - it sounds like maybe somebody was required to give 30 days notice of service changes to certain customers with good laywers In any industry, it only takes a handful of consumers impacted through no fault of their own to generate significant political regulatory attention. Reasonable-sounding explanations cannot stand if they imply that thousands of innocent parties can be impacted without notice. /John
Re: Level 3's side of the story
At 10:15 PM -0400 10/7/05, Christian Kuhtz wrote: In any industry, it only takes a handful of consumers impacted through no fault of their own to generate significant political regulatory attention. Reasonable-sounding explanations cannot stand if they imply that thousands of innocent parties can be impacted without notice. Nonsense. That only matters when somebody is looking for an opportunity to legislate. You're right: administrators, regulators, and representatives are completely helpless except when making laws, and the reconnection of services (ref: Because Internet users, apparently without notice from Cogent and through no fault of their own, have been impacted, Level 3 has, effective immediately, re-established a free connection to Cogent.) can just as easily be attributed to uncanny judgement on Level 3's part as any other explanation. /John
Re: Level 3's side of the story
At 11:00 PM -0400 10/7/05, Christian Kuhtz wrote: What's your point? Are you seriously suggesting this should be regulated? It doesn't appear necessary at all; industry self-regulation seems to be working just fine here... (one might claim almost too well :-) ) .. let the customers draw their own consequences and conclusions based on the actions of the companies who serve them. Thankfully, Internet connectivity is ubiquitous for the most part, and this is hardly the same as essential services (those who consider it that, are fools not to have diversity). Those un-essential Internet services increasingly carry voice services that are considered essential by many consumers, and for whom diversity is not a realistic option. Leaving them completely open to the consequences of service provider actions would be quite an innovative curve in public policy. /John
Re: Level 3's side of the story
At 11:52 PM -0400 10/7/05, Christian Kuhtz wrote: Sorry, I fundamentally disagree with the point of view that we need to regulate free entry free exit and throw these basic tenets of our economy out the window to encourage continued poor decision making . I'm not advocating that we need to regulate anything, only pointing out that the historic public policy position discourages service impacts to 3rd parties, and even more so when done without notice. If you carry essential consumer services, then there is already existing policy in this area. There is no paradise behind that door. And I don't believe regulation should be used to prevent people from making occasionally poor decisions, which in turn will ultimately do nothing more than raise the price floor and create additional barriers of entry in the market. If you don't have those events happen, bad things never get weeded out. There really is nothing but bad news in store for what you propose, because it isn't as simple of a thing to impose regulation and have mostly good things happen. That's a fine set of beliefs (and I might even agree with some of them). However, they're completely irrelevant to the existing school of thought which is guiding policy and legislation in this area, which is probably best represented by last month's House Telecom committee draft: http://energycommerce.house.gov/108/News/09152005_staff_disc.pdf [1] There you go: mandatory ISP registration, interconnection, consumer protection, and more. Maybe these folks were too busy with other stuff to notice the Internet partition happen earlier in the week? Oh, wait, I remember now: these folks are only matter when legislating. /John [1] A readable (only-slightly-biased) summary: http://www.heritage.org/Research/Regulation/wm860.cfm
Re: Cogent/Level 3 depeering
At 3:22 PM -0400 10/5/05, Richard A Steenbergen wrote: ... Usually these things iron themselves out within a few days, but these are certainly two of the largest and most pigheaded networks to go up against each other, so it could be interesting. Whining about it as a customer is one way to try and convince one side or the other to cave sooner, but you can pretty much be guaranteed that someone will end it before some judicial, regulatory, or law making body steps and makes them. :) Just curious - Has this activity impacted voice services for anyone, and/or has either opened a FCC NORS report? /John
RE: Cogent/Level 3 depeering
At 5:32 PM -0400 10/5/05, Hannigan, Martin wrote: Just curious - Has this activity impacted voice services for anyone, and/or has either opened a FCC NORS report? Why could you open a NORS unless it's impacting LD and meet-me minutes? As of 3 Jan 2005, cable telephony outages of 30 minutes duration and potentially 90 user minutes are now included in the mandatory reporting requirements. 1000 users, 15 hours, isn't all that much when you think about it - At some point in the near future, an split such as this is almost assured of having FCC attention due to the consequential consumer business impact. /John
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
on topic of IPv6 end-user assignments and value of multihoming At 6:23 AM -0400 9/10/05, Marshall Eubanks wrote: However, there are two proposals to ARIN to allow direct micro assignments to end sites, these are supposed to be merged into one by the 16th of this month, so people interested should go over to the ARIN ppml and comment. Marshall - good pointer... It is worth repeating that folks who hold an opinion on this matter either way should quickly get involved, whether that is via mailing-list or in person at the upcoming NANOG/ARIN meeting in LA. Thanks! /John
Re: Katrina: directNIC Stays Online - Blog + Images
At 2:13 AM -0700 9/1/05, Dan Hollis wrote: Some rescue services are refusing to enter due to armed thugs roaming the streets with ak47 assault rifles, carjacking, mugging and murdering people. ... Does not sound like a place any sane person would choose to go to. I don't think risking your life to protect your employer's property is on the job description... While there aren't a lot of systems that are worth the risk, they definitely do exist - think air traffic control, hospital power generation, emergency dispatch, and relief effort coordination. Companies suffer when they're offline, but in the above cases, people can die. The good news is these systems are usually better equipped and protected than the local data center... /John
Re: clec vs ilec, how do you know who's lying?
David, It depends a little on what sort of continuous blame the CLEC is pointing at the ILEC... If the statement is that the ILEC fails to show up multiple times, then cancel with the CLEC and order elsewhere. As someone else pointed out, CLEC's are customers of the ILEC wholesale teams, and while a missed delivery date happens all the time, multiple missed dates on one order means that the CLEC isn't managing the process and escalating as needed. If the reason is due to a lack of facilities claim by the ILEC, then give the CLEC a specific date (which is about 15 days out) to achieve activation. The CLEC should have the ability to prioritize their LEC orders to get this in on time, or even to order expensive retail service, watch it get installed fast despite the supposed facility shortage, and then convert it to special access after the fact. CLEC's remain a great bargain but recognize that they're operating in a regulatory environment that has turned hostile. Long-term, CLEC's may not be able to provide any delivery certainty to customers not on their direct fiber plants... /John At 6:29 PM -0400 7/18/05, David Hubbard wrote: Hello everyone, not sure if this is off topic or not since it is will be operational in nature if I can ever get the service set up. :-) I'm having the pleasure, or lack thereof, of ordering some data connectivity via a very large clec which requires the ilec to provide the local loops. Well we're about two months past the estimated install completion and all I get from the clec is continuous blame pointed at the ilec who has now missed three install dates and in turn has wasted staff time sitting there from 8 to 5 each of the days; assuming they were really scheduled in the first place. I know the two types of entities don't particularly like each other but at this point how do I tell who's lying to me? I have supposed work order numbers for the ilec but I don't have any direct contact with them to see if they are real numbers and if the disposition of the previous work orders are what the clec has told me or if they are messing things up themselves and trying to cover it up. Thanks, David
Re: OMB: IPv6 by June 2008 (OT reminder)
At 9:46 AM -0400 7/8/05, Someone wrote: We can morph the RIRs into ... As a slight aside and w/o any comment on the particular morph'ing proposed, I'd like to remind folks that 2 seats on the ARIN Board of Trustees, and 5 seats on ARIN Advisory Council will be filled later this year, and one of the best ways to morph ARIN to meet the needs of the community is the nomination of clueful folks to serve in these roles. Nominations are due by July 29th, and additional information is available at: http://www.arin.net/elections/index.html Thanks! (and you're being returned to the normal tirade, already in progress... :) /John Chair, ARIN
Re: EPP minutia (was: Re: Gtld transfer process)
At 12:55 AM -0500 1/23/05, [EMAIL PROTECTED] wrote: On Sun, 23 Jan 2005 00:00:29 EST, John Curran said: If you believe that REGISTRAR LOCK meets the need, then I've failed to adequately communicate my requirements. The requirement is my domain remains unchanged despite complete failure or fraud of any number of registrars. Do you have a requirement that the domain remain unchanged even in the face of fraud on the part of the registry itself? I indicated failure or fraud by registrars being the problem, not the registry. The moment that the registrars took it upon themselves to set registrar-lock without explicit direction of the domain holder, they implicitly picked up the ability to clear it without the same explicit direction. So, where's the lock the domain name holder sets which simply can't be cleared without *their* consent? And what level of Yes I really mean it documentation do you consider sufficient to turn this *off* in case you *do* need to change something? Does it have to resist a forged e-mail? Forged fax and hacking your phone system so they can answer the confirmation callback? Forged notarized forms mailed to the registry rescinding the lock? A determined black helicopter attack on the part of a competitor? It needs to survive random errors of omission (unlike the present lock...) Ideally, a digitally signed request backed by a known chain of CA's, followed by a reasonable out-of-band verification process performed by the registry with a positive affirmation loop. There's known art in this area (ref: financial services) and it definitely doesn't look like the current Intra-Registrar domain transfer policy. /John
RE: EPP minutia (was: Re: Gtld transfer process)
At 11:02 PM +1100 1/19/05, Bruce Tonkin wrote: Hello John, It appears that REGISTRAR LOCK has interesting per-registrar implementation variations which do not always put the domain holder's interests first. While the registry does not, per se, have a direct business interest with the domain holder, it should be possible to have a lock state which is more oriented to the critical needs of some business domain holders. For a reasonable fee (and copious amount of documentation), it should be possible for any record holder to instruct the registry to lock the ownership of a domain down in such a way so as to require a similar amount of paperwork to release; thus effectively creating an OWNER LOCK state. These services are actually already available in the competitive registrar market. It is a matter of choosing a registrar that has the right business model and services to suit the registrant. If you believe that REGISTRAR LOCK meets the need, then I've failed to adequately communicate my requirements. The requirement is my domain remains unchanged despite complete failure or fraud of any number of registrars. Because REGISTRAR LOCK is administered by registrars, it cannot meet my requirements of absolute protection of change without direct owner intervention. Also, consider past events, and the DNS community/ICANN response: - DNS community claims that some registrars are being intentionally non-responsive on transfers in order to retain customers revenue - Rather than making failure to respond accurately and timely to a registry request a major issue, the DNS community/ICANN change failure to respond into implicit approval after five days - As a result, there is a an increased chance of hijacking, and some registrars are now automatically setting REGISTRAR LOCK on all their customers How long before folks complain that REGISTRAR LOCK is now in the way of transferring domains, and we end up with an erosion in the meaning of that state? It appears domain name owners for critical infrastructure have no choice but to continuously monitor the infighting among registrars and evolving DNS registry/registrar rules in order to protect themselves. This is a really unfortunate burden, since the vast majority of organizations simply want their domain name to be locked from changes without their direct consent. /John
Re: EPP minutia (was: Re: Gtld transfer process)
At 7:21 PM + 1/18/05, Eric Brunner-Williams in Portland Maine wrote: From: Bruce Tonkin [EMAIL PROTECTED] ... I am interested to hear what members of the NANOG list believe would be a better transfers process. The notion of REGISTRAR LOCK is simply too weak, it can be flipped in minutes. I want something that presents only limited windows of state change (other than NS) opportunity, which I can syncronize to corporate standard paperwork flag days, so it isn't when I hand the keys to the shop to a junior and take the kids on holiday. It appears that REGISTRAR LOCK has interesting per-registrar implementation variations which do not always put the domain holder's interests first. While the registry does not, per se, have a direct business interest with the domain holder, it should be possible to have a lock state which is more oriented to the critical needs of some business domain holders. For a reasonable fee (and copious amount of documentation), it should be possible for any record holder to instruct the registry to lock the ownership of a domain down in such a way so as to require a similar amount of paperwork to release; thus effectively creating an OWNER LOCK state. /John
Re: Standard of Promptness
At 3:03 PM -0500 1/17/05, William Allen Simpson wrote: ... This will work even in the cases where the bogus domain registrant submits false contacts, such as happened in panix.com. There shouldn't be any reason to delay reversion to a known former state. Bill, You indicate a known former state, which implies that you'd allow reverting back multiple changes under your proposed scheme... Out of curiosity, how far back would you allow one to revert to? Any previous state within the last two weeks? Longer, or shorter? Given the potential for disruption through fraudulent demands to revert, one has to carry over previous servers for at least this interval to be safe, or do I misunderstand your proposal? /John
ULA and RIR cost-recovery
I've actually tried to avoid commenting on this thread, but that's obviously not going work... Disclaimer: I am the Chairman of ARIN, but these comments herein are my own musings on this topic and nothing more. At 2:26 PM -0600 11/19/04, Stephen Sprunk wrote: The RIRs' current business models (charging rent for WHOIS and DNS entries) are not compatible with the needs that the IPv6 WG defined, particularly in the cost and paperwork areas. The odds of success appear to favor a new entity for a new function instead of leeching off an old entity that was designed for a different purpose. The cost and paperwork associated with current RIR activities is the consequences of the particular guidelines (think RFC2050) that the community adopted for IPv4 address space. This model includes such parameters as previous assignment history, network deployment plans, expected utilization rate, Internet connectivity, etc. As it turns out, collecting and validating that information takes real people and often a bit of paperwork. (In the case of ARIN, the remainder of costs cover the travel and meetings which are necessary for the open and public policy formation process, and support for ICANN, emerging registries, and the RFC editor function curious folks can find both the budget and detailed auditor's reports online at www.arin.net) The IPv4 guidelines are the root cause here, and it's only going to get more interesting as things get tighter and we begin to look at issues such as address reclamation... Why set up a separate registry system for these addresses instead of making minor changes to the existing one to accommodate this need? There is no reason to invent the square wheel manufacturing plant when we have a perfectly good round-wheel plant which can be easily retooled for a fraction of the cost. If ARIN, RIPE, APNIC, LACNIC, or AfriNIC wish to provide the service specified in the draft, they're welcome to volunteer for that function. That some folks have considered ULAs a threat to ARIN's viability is an indication that it isn't likely. The particular merits of ULA's aside, there is no reason why the cost to administer such cannot be very low, but does not appear to be zero due to the requirements relating to anti-hoarding which will quite likely require human involvement. Again, in the IPv6 WG there were folks who offerred to operate the ULA registry _for free_, You'll get what you pay for -- I recently attended a US Senate committee hearing which dealt with registries and the domain name system. There was an enormous amount of questioning about the reliability of these infrastructure services, and actually not one question about why wasn't it all free... The quality (integrity, availability, and survivability) of your assignment records and inverse DNS services will reflect the investment made. If you so much as have a single offsite escrow of the assignments made to date, you've added an ongoing cost that needs to be recovered. and I'm sure many others would be willing to operate it under the initial-cost-only terms in the draft. The RIRs do not appear to be. I'm sorry; ARIN operates today under a cost-recovery basis... What is the basis of your statement that The RIRs do not appear to be (willing to operate it under the initial-cost-only terms in the draft)? If ARIN's members direct it to provide such a service, and provide guidance that the fees should based initial-only and on a cost recovery, I have a lot of faith that it would occur... That does, of course, presume that the operator community actually agrees with the need for ULA's and draft's philosophy on pricing. /John
Re: IPV6 renumbering painless?
At 12:32 PM -0600 11/13/04, Stephen Sprunk wrote: So you're claiming that any IPv6 PI applicant without your political connections to the IESG, ARIN, IANA, etc. can get a /32? I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The initial allocation size for IPv6 was set by the public policy process to be /32. Association with various Internet bodies has no effect (either way :-) on the received allocation size. From http://www.arin.net/policy: ... 6.5.1.2. Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. I have no public comment regarding the ULA proposal, but want to be clear that it is ARIN's goal to apply policies fairly and equitably to all existing and potential members of the Internet community. I am not aware of any complaints in this area in the history of the organization, and so I'm definitely interested from hearing from anyone who feels otherwise. /John John Curran Chair, American Registry for Internet Numbers (ARIN) -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQZZ7jYdtk0FNoZyOEQL7+gCgslGVJSFLsXAlBcgnTz6QmVD0vygAoIj0 RFK60W+OsZvN+4WCnqXP9zva =xTvs -END PGP SIGNATURE-
Re: IPV6 renumbering painless?
At 12:32 PM -0600 11/13/04, Stephen Sprunk wrote: So you're claiming that any IPv6 PI applicant without your political connections to the IESG, ARIN, IANA, etc. can get a /32? I don't know exactly how many subnets/hosts ISC has, but I seriously doubt ISC could even get a PI /48 if you weren't buddies with the folks making allocation decisions. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The initial allocation size for IPv6 was set by the public policy process to be /32. Association with various Internet bodies has no effect (either way :-) on the received allocation size. From http://www.arin.net/policy: ... 6.5.1.2. Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. I have no public comment regarding the ULA proposal, but want to be clear that it is ARIN's goal to apply policies fairly and equitably to all existing and potential members of the Internet community. I am not aware of any complaints in this area in the history of the organization, and so I'm definitely interested from hearing from anyone who feels otherwise. /John John Curran Chair, American Registry for Internet Numbers (ARIN) -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQZZ7jYdtk0FNoZyOEQL7+gCgslGVJSFLsXAlBcgnTz6QmVD0vygAoIj0 RFK60W+OsZvN+4WCnqXP9zva =xTvs -END PGP SIGNATURE-
Re: How to Blocking VoIP ( H.323) ?
At 9:46 AM -0800 11/12/04, Alexei Roudnev wrote: Not too easy, but I can imagine few alghoritms doing it. Remember that VoIP uses short packets, and you cam always recognize Ack and Tcp packets which should not be disrupted. Jitter does not slow down network, except if it interacts with RTT calculartion in TCP/IP. Agreed; presuming you could find a friendly vendor to code such a feature and who has the reasonable hardware to support (as intentional jitter would make for amusing buffer activity on any high speed links). However, attempting to deploy such in the presence of any competitive market would likely result in widespread customer migration. A government or assured monopoly could deploy it, though, and then charge a premium for those who want it removed (i.e. premium data service) which conveniently happens to match their current voice tariffs... /John
Re: FW: The worst abuse e-mail ever, sverige.net
At 10:16 AM +0200 9/22/04, Lars-Johan Liman wrote: I cannot agree to the block port 25 line of action. You block port 25 until a customer says that they're claim to have setup a responsible mail submission agent and demonstrate the necessary clue density. This can be readily determined by having customer support mail a short form with relevant questions such as Is your mail server RFC2505 compliant?, Please list the mechanism used to secure mail submission to your server?, and Are you prepared to handle SPAM reports for all email originated or relayed? No problem for someone who knows what they're doing but enough to deter the random end user. /John
Re: FW: The worst abuse e-mail ever, sverige.net
At 4:51 PM +0100 9/22/04, Randy Bush wrote: in the north american culture, this is usually termed guilty until proven innocent, and generally discouraged. perhaps we should not deprive the customer of rights/services until they have been shown to have abused them? I am *so* happy that the power grid doesn't operate this way... fuses and circuit breakers are there in your home, the pedestal, and the pole for good reason. Call your power company if you want to upgrade *and* can demonstrate appropriate certified electrical work in advance. /John
Re: RIPE Golden Networks Document ID - 229/210/178
Bill, I agree with your general line of reasoning, but would likely characterize RIPE as an RIR *and* operator forum... formulating and reviewing recommendations on operational matters make some sense as a result. As to the particular set of prefixes, there's a great question as to what criteria make a particular network important... one could easily come up with a list of extremely popular commercial sites (CNN, Amazon, etc.) which might be more noticeable if route damped for an hour. /John At 4:06 AM +1200 9/3/04, Bill Manning wrote: RIPE is the RIR for Europe. RIPE-229 is, from my viewpoint, arbitrary and capricious. the root servers are -ONE- set of interesting servers. what about the web sites that point to these important documents? or the time servers, or my NOC monitoring machines? The idea of an Internet Registry stepping into giving routing advice is a leap of faith. An RIR can tell you what was delegated - but presuming to give advice on what is important for everyone that uses IP protocols is over the top.
Re: Current street prices for US Internet Transit
At 3:05 PM -0400 8/16/04, Patrick W Gilmore wrote: Perhaps some of your assumptions are wrong. Perhaps people are making due with OC48s. Perhaps there is less redundancy or more loading. Perhaps your discount level is too low. Who knows? Did you build an OC192 network with 6 routers and 3 links and etc.? I didn't, so maybe I'm wrong. But given the choices of A) Every single network on at least two continents is selling for less than half their cost or B) An one page e-mail to NANOG may not reflect the complex business realities of the telecommunications world - well, I'll pick B. Amazingly, the term cost actually has different contexts, and these greatly impact the final numbers. For example, the cost model used to justify a given price to a customer can be fully-loaded/fully-allocated or simply incremental... The fully-loaded one will result in the same unit cost every time, whereas the incremental one often doesn't recover the cost of past investment in the network. Of course, if that investment is several years old, has been through a bankruptcy or two, then it might not really matter (until a customer sale results in having to do some new spending for additional capacity...) Do you take on customers at rock-bottom prices which barely cover your out-of-pocket expenses, your payroll, and interest payments, or do you let them go to your competition because no revenue is better than revenue which doesn't let you cover the network growth in 3 or 4 years? This is a question which is being discussed at quite a few ISP's today... /John
Re: Cisco/Juniper right of resale.
At 5:40 PM -0400 8/16/04, Gerald wrote: I believe this is still an open legal argument waiting to be tested. They claim it, but no one has fought it yet. In federal law there is a concept called right of resale. Note article dates when reading: http://www.washingtontechnology.com/news/14_11/federal/758-1.html http://articles.corporate.findlaw.com/articles/file/00353/009275 ... If you buy a serious quantity of equipment (say: $10M+ each year) and are particularly annoying (who, me? ;-), then you can take some amusing contractual steps to insure that you receive the full useful value of your equipment purchases... This includes including the post-warranty maintenance plan costs in your total ownership cost comparison (to bring useful life out to match the three or five years deprecation life) and it also means requiring vendors to allow clear transfer in those cases where you need to remove equipment from the network and they turn down the option to buy it back themselves... Contractual mechanisms work very well, and all it takes is a willingness to turn away vendors in the lobby who otherwise thought you'd buy gear that loses half its resale value on receipt... /John
Re: S.2281 Hearing (was: Justice Dept: Wiretaps...)
At 8:04 AM -0700 6/21/04, Owen DeLong wrote: John, While I agree that not many domestic (or EU) vendors will offer services contrary to the law in this area, do you truly believe this won't simply cause companies that really want to make money in this market to move to places where the laws are less difficult? Afterall, I can get pretty good fiber connectivity in Malaysia or other parts of Asia/SoPac without really needing to worry much about any sort of LI procedures. As long as the company offering the services does so via a web site and can collect on credit card billings (even if they have to keep rotating shell companies that do the billings), money can be made without dealing with US regulations. With respect to enforcement, I am sure there are ways to prevent being caught involving amusing offshore logistics, but that will still prevent the vast majority of US businesses from offering non-2281 compliant services. Frankly, the harder DOJ works on pushing this LI crap down our throats, the more damage they will do to US internet industry and consequently the more job-loss they will create. Terrorists that are sophisticated enough to be a real threat already know how to: 1. Cope with lawful intercept through disinformation and other tactics. 2. Encrypt the communications (voice or otherwise) that they don't want intercepted -- It's just not that hard any more. I think the only advantage to DOJ working this hard on LI capabilities is that it may raise public awareness of the issue, and, may help get better cryptographic technologies more widely deployed sooner. Other than that, I think it's just a lose all the way around. I'm not advocating the DoJ's position on this matter, just trying to clarify it for the list (since it was rather muddled in earlier postings). /John
Re: S.2281 Hearing (was: Justice Dept: Wiretaps...)
At 11:11 PM -0400 6/20/04, Sean Donelan wrote: Every type of electronic communications in the USA may, and probably has been intercepted at one time or another, not just VoIP. Everything outlined in the ETSI standards, and more, is available for purchase today from vendors in the USA. Its a lot more than simply facilitating access. Under Title III, carriers already had to provide reasonable technical assistance, with compensation. The objection generally isn't about facilitating access. Law enforcement already has access, and has shown no reluctance in obtaining court orders for ISPs to give them access. Access isn't the question. This is about assisting law enforcement by facilitating access, which by CALEA is providing mechanisms and capacity for lawful intercept in advance. As you are aware, it is possible to be unable to fulfill a court order for intercept due to technical reasons, and the DoJ sees this as a real distinct possibility for an increasing volume of voice calls if S.2281 is approved as-is. So what is the real problem? What is law enforcement actually asking for? Amazingly, that's contained in the DoJ comments: In both the IP-enabled services and CALEA proceedings at the FCC, the Department of Justice has made the same points that I want to emphasize here this morning: (1) that public safety and national security will be compromised unless court orders for electronic surveillance can be implemented by providers; (2) that assistance requirements should apply to every service provider that provides switching or transmission, regardless of the technologies they employ; and (3) that if any particular technology is singled out for a special exemption from these requirements, that technology will quickly attract criminals and create a hole in law enforcement's ability to protect the public and the national security. Looks pretty clear to me: assistance requirements (i.e. the requirement to have LI capacity and mechanisms in place in advance) should apply to all providers, and in particular, that VoIP providers who do not provide direct PSTN access (e.g. FWD, Skype) should not get an exception here as specified in the draft bill. /John
S.2281 Hearing (was: Justice Dept: Wiretaps...)
The particular hearing that set this all off is the Senate Commerce Committee's review of S.2281 (VoIP Regulatory Freedom Act) that took place on last Wednesday, and in general, the hearing has a higher content to noise ratio than the resulting press coverage. The agenda and statements of the participants can be found here: http://commerce.senate.gov/hearings/witnesslist.cfm?id=1230 S.2281 takes the middle of the road position in areas such as lawful intercept, universal service fund, and E911. At a high-level, those VoIP services which offer PSTN interconnection (and thereby look like traditional phone service in terms of capabilities) under S.2281 pick up the same regulatory requirements. Those VoIP services which do not interconnect are continue to be treated as information services and therefore excluded from these requirements. With respect to facilitating lawful intercept, the opening comments of Ms. Laura Parsky (Deputy Assistant Attorney General, US DoJ) and James Dempsey, Executive Director of the Center for Democracy and Technology (CDT) are quite informative. The DoJ view is that S.2281 is not enough, and any service using switching or transport should facilitate lawful intercept. This position has the advantage of clarity, but there are lots of communications (chat/IM/etc) that are going to hard to decode and make readily available as needed. It is also an expansion of the current framework of CALEA, which specifically sets aside information services including email and messaging. The CDT position is interesting, noting that CALEA came into being to address concerns that law enforcement wouldn't be able to readily pursue lawful intercept orders without directly mandating call intercept capacity in each service provider. This works fine with one application (voice) but that replicating this model for data services makes no sense given the diversity of Internet communications applications. CDT proposes that if law enforcement really needs better intercept capabilities for data applications, it should work on its own decode capabilities or get service bureaus to handle that same, and that the Internet service providers shouldn't have to do anything other supply a copy of the relevant users raw packet stream... Despite the angst on both sides, requiring just those VoIP services which look like traditional phone service (due to PSTN interconnection) as requiring ready lawful intercept capacity will result in the equivalent situation as we have today with CALEA, and appears to be the likely outcome of the debate. Apologies for length, /John
Re: S.2281 Hearing (was: Justice Dept: Wiretaps...)
At 12:06 AM -0400 6/20/04, Sean Donelan wrote: On Sat, 19 Jun 2004, John Curran wrote: S.2281 takes the middle of the road position in areas such as lawful intercept, universal service fund, and E911. At a high-level, those VoIP services which offer PSTN interconnection (and thereby look like traditional phone service in terms of capabilities) under S.2281 pick up the same regulatory requirements. It sounds good, if you assume there will always be a PSTN. But its like defining the Internet in terms of connecting to the ARPANET. Correct. It's a workable interim measure to continue today's practice while the edge network is transitioning to VoIP. It does not address the more colorful long-term situation that law enforcement will be in shortly with abundant, ad-hoc, encrypted p2p communications. What about Nextel's phone-to-phone talk feature which doesn't touch the PSTN? What about carriers who offer Free on-net calling, which doesn't connect to the PSTN and off-net calling to customers on the PSTN or other carriers. Will the bad guys follow the law, and only conduct their criminal activities over services connected to the PSTN? Sean - what alternative position do you propose? /John
Re: Verisign vs. ICANN
At 10:34 AM -0600 6/18/04, John Neiberger wrote: It never ceases to amaze me that some companies will move forward with actions that they know will give them a horrible reputation. Hmm... I'm not going to try to defend Verisign (or ICANN for that matter), but will note that the decision to engage in litigation is often not optional... In many areas of law, failure to act to diligently against infringement can effectively preclude you from pursuing legal recourse in the future. So, companies can find easily find themselves having to file legal actions simply to maintain their right to do so. Also, while drastic, filing suit doesn't preclude adults getting together and working out the the matter before anything makes it to court. It's legal action without any real meaningful attempt to meet and settle in advance which deserves a bad reputation. /John
Re: [Fwd: [IP] Feds: VoIP a potential haven for terrorists]
At 3:44 PM -0400 6/18/04, Daniel Golding wrote: There are three schools of thought here. One is that the VoIP should not be wiretapped at all. This seems a little unrealistic considering that we allow other calls to be tapped. The second school is that VoIP calls should be made no easier or harder to tap than the technology itself warrants through its natural evolution. The FBI or whomever would just have to learn how to work with it as it evolves. The third school of thought is that all VoIP boxes should come with a red rj45 that says FBI use only and a big red button to start the data flowing to said jack. There another axis of the conversation going on, and that is with respect to the scope of voice technologies that require support... One camp believes that all voice communication must provide CALEA and the other believes that just those voice services which provide interconnection to/from the PSTN should need compliance. The latter position is far easier to implement and corresponds to today's capabilities. Under the more generous definition of any voice communication, there's a huge realm of possible applications that might need to be intercepted including IM services, Skype, web chat support protocols, and even audio-enabled chats that are embedded in games. Someone's going to make a killing in stateful packet detection at the metro POP level... /John
Cisco Systems to Purchase Procket Networks...
SAN JOSE, Calif., June 17, 2004 - Cisco Systems, Inc., today announced a definitive agreement to purchase the intellectual property, a majority of the engineering team and select assets from privately-held Procket Networks, Inc. of Milpitas, Calif. Procket Networks is a developer of concurrent services routers and has expertise in silicon and software development. This purchase will add a rich intellectual property portfolio and a team of proven silicon and software architects to Cisco's industry leading routing technology and products. http://newsroom.cisco.com/dlls/2004/corp_061704.html FYI, /John
Re: Cisco Systems to Purchase Procket Networks...
I believe that Tony has escaped that fate... (although the phrasing of the press release could lead one to believe that the engineering team aren't really people, but some form of property that was sold to Cisco ;-) /John At 5:46 PM -0700 6/17/04, Wayne E. Bouchard wrote: So does this mean that Tony Li now works for Mr. Chambers again? :-) On Thu, Jun 17, 2004 at 05:21:58PM -0700, John Curran wrote: SAN JOSE, Calif., June 17, 2004 - Cisco Systems, Inc., today announced a definitive agreement to purchase the intellectual property, a majority of the engineering team and select assets from privately-held Procket Networks, Inc. of Milpitas, Calif. Procket Networks is a developer of concurrent services routers and has expertise in silicon and software development. This purchase will add a rich intellectual property portfolio and a team of proven silicon and software architects to Cisco's industry leading routing technology and products. http://newsroom.cisco.com/dlls/2004/corp_061704.html FYI, /John --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: Default Internet Service (was: Re: Points on your Internet driver's license)
At 6:31 AM -0400 6/13/04, Sean Donelan wrote: If they were, you would expect to see a difference between barns with doors and barns without doors. But in practice, we see people with and without firewalls with infected computers. If you're asserting that having firewalls in the path doesn't have any impact on rate of infection, please provide a link to this data. Sure, I've even seen infected computers in rooms that don't (or should not have had) any connectivity, but that just means it is not a perfect world. Lot's of things make it through firewalls (email-based worms come to mind) but from what I've seen they are quite effective at protecting networks of otherwise helpless comes-out-of-the-box-wide-open PC's. /John
Re: Default Internet Service (was: Re: Points on your Internet driver's license)
At 6:31 AM -0400 6/13/04, Sean Donelan wrote: Network level controls aren't as effective as some people hope at stopping many things. ISPs should stop porn, ISPs should stop music sharing, ISPs should stop viruses, ISPs should stop insert here. Yet somehow users manage to find a way around all of them. In a perfect world, ISPs shouldn't have to worry about content. There is no way to know whether the user wants a particular message and methods at guessing are always imperfect. Despite this, a lot of users would like their ISP to try to do their best to filter spam and viruses out of their mail stream, etc. It really should be an local issue but users ask, so the service appears. However, distinguish content from access. Typical users, particularly in broadband residential connections, have no desire to have anyone remotely access their machine. The same is true with most small business customers. Upon arrival of their first Internet connection, the systems do not magically recognize that end-to-end now could be any endpoint in the Internet and install appropriate filters. Why doesn't it make sense to change the default model so that such are in place under the user demonstrates some understanding of the situation by asking them to be removed? To add one more analogy to the mix, we blindly install on-ramps to the freeway to anyone who asks and certainly a few folks know what is in store once connected. However, the vast majority of ramps are connected to suburban driveways, skate board parks, and middle school playgrounds. It's amazing that we all act surprised when innocents get run over... /John
Re: Points on your Internet driver's license
At 9:02 AM -0700 6/13/04, Owen DeLong wrote: 600A three phase is about bigger bandwidth, not different services. True, there are devices that require three phase power, but, if they don't require more power than is available in a 200A 220V services, guess what, they can be run off of household service by using a transformer to convert the household service to 3phase and handle the voltage conversion as well. A transformer is a simple, and, generally inexpensive device which the user could even make themselves if they so desired (although I don't recommend this). To continue the analogy, 200A 220V household service is like DSL or Cable. 600A 208V three phase is like a T1. 2000A 7KV three phase is like a DS3. To the best of my knowledge, all of these services can be made to work with any electrical device that doesn't require more power (bandwidth) than the service can deliver. In most states, the power company cannot connect service to a home or business until it has been inspected by a building inspector... This is to keep the number of fried customers to the lower possible value. And yes, it is possible to do your own power box work, but expect the inspector to be very thorough if you aren't also a licensed electrician. So, who's checking these local LAN's to make sure they don't melt or burst into flame once hooked up? /John
Re: Points on your Internet driver's license (was RE: Even you can
Paul, Actually, credit agencies don't have a single standard for what bad is; they are obligated to only keep factual data (as can be best determined) in the files. When you cause a credit report to be checked, one or more algorithms are used to score your credit, but the algorithm used is up to the particular inquirer and credit bureau. It's not that hard to make this one work for spammers, but you need some key pieces to all be in place: 1. Common definition for what information is kept 2. ISP's need customer contracts which allow reporting of incidents and terminations to any/all such bureaus 3. ISP's need to figure out how to handle a new site which has no listings. Spammers already figured out that some ISPs do DB credit checks, and have gotten very good at appearing as a new startup a week later. /John At 4:50 PM + 6/13/04, Paul Vixie wrote: [EMAIL PROTECTED] (Owen DeLong) writes: Perhaps what is needed is a reporting agency, similar to the credit reporting agencies, where ISPs can register chronic problem-customers. Eventually, your internet credit rating deteriorates to the point that no ISP will offer you service. it is with some discomfort that i watch the last decade or so of ultimate final solutions to spam be rediscovered on a sleepy nanog weekend. the reason the above analogy fails to hold (and why that proposal isn't a solution) is that credit reporting agencies have an established standard for what bad is -- days overdue on payments. there is no similar standard for a tcp/ip endsystem, and there can be none. a week doesn't go by without some goober-with-firewall complaining that f-root is portscanning him. as112 gets it every day at least two or three times. someone else here reports that his squid proxy is regularly reported by norton's tools because it sets unusual bits in the tcp header. and so on. -- Paul Vixie
Re: Points on your Internet driver's license
My inbox overflows with complaints about the analogy, and the fact that it's the appliances that are shipped broken... I hereby acknowledge the faulty analogy, you can discard your edit buffer if you're in the process of sending me such a note... :-) Hopefully, the appliances (e.g. MS Windows) will get better over time, but in the meanwhile, how do we limit the damage? The end-user wants email and web access, and we give him raw IP access and watch the fireworks... If user education is the answer, then let the user get educated enough to figure out he's NAT'ed and proxied, and then ask to have the raw IP service. /John At 11:26 AM -0700 6/13/04, Randy Bush wrote: In most states, the power company cannot connect service to a home or business until it has been inspected by a building inspector... This is to keep the number of fried customers to the lower possible value. And yes, it is possible to do your own power box work, but expect the inspector to be very thorough if you aren't also a licensed electrician. So, who's checking these local LAN's to make sure they don't melt or burst into flame once hooked up? very broken analogy. as opposed to the house wiring, the lan is not the problem. it's the stove, aka ms windoze. and you don't need to go to the home to inspect it, you know it was broken when it was shipped from the factory. and the user was neither sufficiently warned nor sufficiently educated on how to avoid its worst risks. randy
Internet Credibility Bureau (Re: Points on your Internet driver's license)
You underestimate the profitability of spam and the creativity of such folks in filling out applications. I do think that it's workable, but just don't presume that its going to be airtight. /John At 10:45 AM -0700 6/13/04, Owen DeLong wrote: As I said earlier in private mail to John, I think this will only work if the reporting is done on indivuduals, not companies. For non-corporate business entities, the president of the company should be used as a stand-in for the company. For corporate business entities, the CEO or chairman of the board should be used. I'm betting that spammers will rapidly run out of people willing to forego future internet access in the name of continuing their business fairly rapidly. Owen
Re: Points on your Internet driver's license
At 12:15 PM -0700 6/13/04, Randy Bush wrote: tell us, john, when you were at xo and gte, how much did you educate your users as to to the perils of running open; how much education and notification did you give them about applying security patches; ...? Reasonable question business customers were indeed asked at installation what they were connecting for mail and web servers, told that a firewall was a good idea and pointing at both online and reference books that could get. I don't know what consumer DSL got, but I imagine it was a lot less. In the pre-GTE-I (i.e. BBN) days, we actually went on-site to help customers with their mail relay and local routing configurations. For consumer connections, this just doesn't scale. The consumer is going to acknowledge/clickthru/sign whatever disclaimer you put in front of them in order to get their high speed access. And as much as ISPs might want to fix the problem, they're not going to require a networking quiz before taking the order. how is the user going know the brokenness you net vigilantes propose to impose from the brokenness the other miscreants impose? Nicely put.How about: if their mail and web access works, then its the fault of the net vigilantes and filtered Internet service. If their machine is running 100% on the CPU and rebooting at random after just a few minutes online, then it's those other miscreants... /John
Default Internet Service (was: Re: Points on your Internet driver's license)
The real challenge here is that the default Internet service is wide-open Internet Protocol, w/o any safeties or controls. This made a lot of sense when the Internet was a few hundred sites, but is showing real scaling problems today (spam, major viruses, etc.) One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate. If a site wants wide-open access, just give it to them. If that turns out to cause operational problems (due to open mail proxies, spam origination, etc), then put 'em back behind the relays. /John
Re: Default Internet Service (was: Re: Points on your Internet driver's license)
At 6:58 PM -0700 6/12/04, Randy Bush wrote: One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate. If a site wants wide-open access, just give it to them. If that turns out to cause operational problems (due to open mail proxies, spam origination, etc), then put 'em back behind the relays. guilty until proven innocent, eh? thanks mr ashcroft. Randy, are you objecting to the model for initial connectivity, or the throwing them back behind relays w/o a formal trial? /John
Re: Default Internet Service (was: Re: Points on your Internet driver's license)
At 4:21 AM + 6/13/04, Christopher L. Morrow wrote: We have methods of dealing with these abuse problems today, unfortanately as Paul Vixie often points out there are business reasons why these problems persist. Often the 'business' reason isn't the tin-foil-hat-brigade's reason so much as 'we can't afford to keep these abuse folks around since they don't make money for the company'. I'll argue that we have don't effective methods of dealing with this today, and it's not the lack of abuse desk people as much as the philosophy of closing barn doors after the fact. The idea that we can leave everything wide open for automated exploit tools, and then clean up afterwards manually with labor-intensive efforts is fundamentally flawed. /John
Re: ARIN awol?
ARIN is presently having connectivity problems out of the Chantilly VA office. These are being worked with the relevant providers but there is no ETA at this time. FYI, /John At 10:37 AM -0600 6/2/04, Mike Lewinski wrote: Lots of history entries, nothing usable. Been this way a while now. route-views.oregon-ix.netsh ip bgp 192.149.252.17 BGP routing table entry for 192.149.252.0/24, version 18274110 Paths: (38 available, no best path) - Not advertised to any peer 7660 2516 7911 701 7046 (history entry) 203.181.248.233 from 203.181.248.233 (203.181.248.13) Origin IGP, localpref 100, external Dampinfo: penalty 518, flapped 3 times in 00:30:43 3277 13062 2854 2854 5511 1239 701 7046 (history entry) 194.85.4.55 from 194.85.4.55 (194.85.4.55) Origin IGP, localpref 100, external Community: 3277:13062 3277:65301 3277:65307 Dampinfo: penalty 549, flapped 4 times in 00:41:51 4513 1239 701 7046 (history entry) 209.10.12.28 from 209.10.12.28 (209.10.12.28) Origin IGP, metric 12, localpref 100, external Dampinfo: penalty 498, flapped 3 times in 00:31:36
Re: why use IPv6, was: Lazy network operators
At 10:32 AM +0200 4/18/04, Iljitsch van Beijnum wrote: And customers who do ask, are routinely turned down. Change providers. A request for new functionality from existing customers may not always get the attention it deserves, but I don't know of a provider that doesn't sit up and pay attention when a customer leaves to the competition. And what does it say if you're not willing to go through the hassle to change providers to get IPv6 services? :-) /John
Re: Lazy network operators - NOT
At 9:42 PM -0500 4/17/04, Doug White wrote: Spamming is pervasive mainly due to the inattention or failure to enforce acceptable use policies by the service provider. It's pervasive because its profitable. It's been profitable because even a few weeks of a high-speed circuit can generate millions of messages which don't need much of a response rate to generate revenue. The problem now is that a growing percentage of spam is originating from distributed farms of broadband connected users (Commtouch says 80% in one article, but I'm not yet convinced its that high - http://www.clickz.com/stats/big_picture/applications/article.php/3337751) This would suggest that spam is pervasive largely because of the large number of insecure systems available for origination (via port 25 :-), not because of providers failing to close barn doors after the fact... /John
