Re: Cogent issues in SF area?
The archive.org/Cogent stuff was an issue specific to archive.org's connection to Cogent. Jim Shankland
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
Robert Boyle wrote: Either your firewall/router or the customer's firewall/router is blocking PMTUD packets. I suspect an overzealous firewall admin is blocking all icmp. Which you can't do anything about if the overzealous firewall admin is at the other end of the connection. My repeated, first-hand experience has been that several of the better-known web sites out there will happily send out 1500-byte packets with DF set, then ignore the DEST_UNREACH/FRAG_NEEDED icmp responses they get. If you're on the client end of this, you're sunk unless you initiate the connection specifying a lower MSS. Linux has a nifty iptables option (clamp-mss-to-pmtu) to rewrite the MSS in TCP SYN packets when forwarding a packet onto a link with a lower MTU than the MSS in the packet. Works like a charm. If every packet forwarding device on the Internet did this, PMTUD would not be needed. As is, PMTUD is simply broken, due to widespread firewall misconfiguration. As in so many other cases of Internet misbehavior, you can avoid being part of the problem, but you can't be the solution. Jim Shankland
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
Adrian Chadd wrote: On Thu, Aug 02, 2007, Jim Shankland wrote: Linux has a nifty iptables option (clamp-mss-to-pmtu) to rewrite the MSS in TCP SYN packets when forwarding a packet onto a link with a lower MTU than the MSS in the packet. Works like a charm. If every packet forwarding device on the Internet did this, PMTUD would not be needed. As is, PMTUD is simply broken, due to widespread firewall misconfiguration. As in so many other cases of Internet misbehavior, you can avoid being part of the problem, but you can't be the solution. .. non-TCP traffic? Hmm; I've never actually heard of anybody doing PMTUD on non-TCP traffic, though it's possible. Does anybody actually do it? Jim Shankland
Security gain from NAT (was: Re: Cool IPv6 Stuff)
[EMAIL PROTECTED] writes: Let's not forget all the NAT boxes out there that are *perfectly* willing to let a system make an *outbound* connection. So the user makes a first outbound connection to visit a web page, gets exploited, and the exploit then phones home to download more malware. Yeah, that NAT *should* be providing security, but as you point out, there's that big gap between should and is... :) I will happily (well ...) further concede that NAT does not provide *absolute* security. Let me be the first to mention that NAT provides precisely zero protection against: Hey, kids, just download and run this .EXE to see a cute cartoon of Santa dancing with a polar bear :-). Jim
Re: from the academic side of the house
[EMAIL PROTECTED] writes: The next day, the team used a modified version of TCP to achieve an even greater record. Using the same 30,000 km path, the network was able to achieve a throughput of 9.08 Gbps which is equal to 272,400 Tb-m/s for both the IPv6 multi and single stream categories. In doing so, the team surpassed the current IPv4 records, proving that IPv6 networks are able to provide the same, if not better, performance as IPv4. Good job. Two questions, though: (1) Do the throughput figures count only the data payload (i.e., anything above the TCP layer), or all the bits from the protocol stack? If the latter, it seems a little unreasonable to credit IPv6 with its own extra overhead -- though I'll concede that with jumbo datagrams, that's not all that much. (2) Getting this kind of throughput seems to depend on a fast physical layer, plus some link-layer help (jumbo packets), plus careful TCP tuning to deal with the large bandwidth-delay product. The IP layer sits between the second and third of those three items. Is there something about IPv6 vs. IPv4 that specifically improves perfomance on this kind of test? If so, what is it? Jim Shankland
[no subject]
[EMAIL PROTECTED] writes: Use GigE cards on the servers with a jumbo MTU and only buy IP network access from a service provider who supports jumbo MTUs end-to-end through their network. I'm not sure that I see how jumbo frames help (very much). The principal issue here is the relatively large bandwidth-delay product, right? So you need large TCP send buffers on the sending side, a large (scaled) receive window on the receiver side, and turn on selective acknowledgement (so that you don't have to resend the whole send buffer if a packet gets dropped). At 45 Mb/s and 120 ms RTT, you need to be able to have ca. 700 KBytes of data in flight; round up and call it a megabyte. Having said that, I too have tried to configure Windows to use a large send buffer, and failed. (In my case, it was Windows machines at a remote location sending to Linux machines.) I'm not a Windows person; maybe I didn't try hard enough. In the event, I threw up my hands and installed a Linux proxy server at the remote site, appropriately configured, and went home happy. Jim Shankland
Re: Google wants to be your Internet
Travis H. [EMAIL PROTECTED] writes: IIRC, someone representing the electrical companies approached someone representing network providers, possibly the IETF, to ask about the feasibility of using IP to monitor the electrical meters throughout the US The response was yeah, well, maybe with IPv6. Which is nonsense. More gently, it's only true if you not only want to use IP to monitor electrical meters, but want the use the (global) Internet to monitor electrical meters. I'd love to hear the business case for why my home electrical meter needs to be directly IP-addressable from an Internet cafe in Lagos. Jim Shankland
Re: Google wants to be your Internet
In response to my saying: I'd love to hear the business case for why my home electrical meter needs to be directly IP-addressable from an Internet cafe in Lagos. Jay R. Ashworth [EMAIL PROTECTED] responds, concisely: It doesn't, and it shouldn't. That does *not* mean it should not have a globally unique ( != globally routable) IP address. and Jeroen Massar [EMAIL PROTECTED] presents several hypothetical scenarios. Note that the original goal was for electrical companies to monitor electrical meters. Jeroen brings up backyard mini-nuke plants, seeing how much the power plug in the garden is being used, etc. These may all be desirable goals, but they represent considerable mission creep from the originally stated goal. None of Jeroen's applications requires end-to-end, packet-level access to the individual devices in Jeroen's future (I assume) home. You can certainly argue that packet-level connectivity is better, easier to engineer, scales better, etc., etc.; but it is not *required*. In fact, there are sound engineering arguments against packet-level access: since we've dragged in the backyard nuke plant, consider what happens when everybody has a backyard mini-nuke, with control software written by Linksys, and it turns out that sending it a certain kind of malformed packet can cause it to melt down No matter. Reasonable people can disagree on the question of whether every networkable device benefits from being globally, uniquely addressable. The burden on the proponents is higher than that: there are *costs* associated with such an architecture, and the proponents of globally unique addressing need to show not only that it has benefits, but that the benefits exceed the costs. Coming full circle, the original assertion was that IPv6 was required in order for electric companies to use IP to monitor US electric meters. That assertion is false, and no amount of hand-waving about backyard nuke plants will make it true. The history of IPv6 has been that it keeps receding into the future as people's use of IPv4 adapts enough to make the current benefit of switching to IPv6 smaller than the cost to do so. Perhaps after a decade or so, we're nearing the end of that road. Or perhaps, as F. Scott Fitzgerald once wrote about IPv6, it is: the orgiastic future that year by year recedes before us. It eluded us then, but that's no matter - tomorrow we will run faster, stretch out our arms further And one fine morning - We'll see. Jim Shankland
Re: TCP receive window set to 0; DoS or not?
Richard A Steenbergen [EMAIL PROTECTED] writes: Advertising a window of 0 is a perfectly valid way of telling the other side that you are temporarily out of resoruces, and would like them to stop sending you data Except that that's not what's going on here. This message appears when the TCP peer shrinks the window, withdrawing a previously granted permission to send bytes -- a protocol violation. For example, you're free to tell me (with your window advertisement) that you're authorizing me to send you 32K bytes, and then, after I've sent you 32K bytes, to close the window until you're ready to accept more. You're not free to tell me it's OK to send 32K bytes, then change your mind and advertise a window size of 0 after I've sent you only 16K bytes. To address the DoS question, I don't see how this protocol violation enables a DoS attack. More likely, it's simply somebody's buggy TCP stack misbehaving. That somebody is unlikely to be Windows, MacOS, FreeBSD, or Linux. My money is on some flavor of $50 NAT/home router box. Jim Shankland
Re: TCP receive window set to 0; DoS or not?
Travis Hassloch [EMAIL PROTECTED] writes: The part where it becomes a DoS is when they tie up all the listeners on a socket (e.g. apache), and nothing happens for several minutes until their connections time out. Whether intentional or not, it does have a negative effect. Ah, that makes sense. I was assuming a deliberate attack, which is not actually implicit in the term DoS. A deliberate denial of service is not made easier by shrinking the window. But an implementation that advertises a 0 window in lieu of sending FIN or RST can certainly deny service inadvertently by tying up resources that should have been freed. Jim Shankland
Re: The entire mechanism is Wrong!
Just remember that, as an example, Melbourne IT has probably two orders of magnitude more clients than you. A 24x7 pager service would attract a /lot/ of Emergencies and as such they'd have to consider running at least a muppet level call service outside of hours to filter emergency requests away from the normal signup procedures and over to the People Who Really Fix Things. Of course it's unreasonable to expect a registrar to have to put up with such a burden during off hours: God only knows what kind of silly calls would come in. Emergencies are best handled in a batch during the regular work week. For the stuff that really won't wait, you just put a lawyer on retainer, who can fax off a letter telling the complainant to sod off until Monday morning, or until the moon is in the seventh house and Jupiter aligns with Mars, whichever comes first. I mean, if we can't be on the golf course by 3:00, what are we in this business for, anyway -- right? Jim Shankland
Re: Cable and Wireless Security Contact?
In addition, I've called Erie Forge and Steel, the rightful owners of this block , who've articulated they've gotten numerous complaints about port scanning and spam from this IP block. And let us note in passing the irony of Erie Forge and Steel having its address block forged and stolen. Jim Shankland
Re: Appreciation for Bind patches
Andrew Fried writes: Simply put, I would like to publicly express my appreciation to Mr. Vixie for taking the time to add the root-delegation-only patch for Bind. You speak for many. Andrew Fried, Senior Special Agent United States Department of the Treasury Treasury Inspector General for Tax Administration Strategic Enforcement Division Now go audit Verisign's tax returns for the last 3 years :-).
Re: RPC errors
On the bright side, when double-checking the firewall on my home cable modem setup, it appears that Comcast here in the SF Bay Area has started filtering out incoming port 135 SYN packets -- they get dropped before they hit my firewall. Thanks, Comcast! On the not so bright side, I'm getting a steady stream of port 135 SYNs from my fellow Comcast customers (i.e., presumably on my side of Comcast's filters), which may mean the horses have mostly already left the barn. Jim Shankland
Re: IPv6
David Barak [EMAIL PROTECTED] writes: I think the place you're going to see IPv6 adoption is government networks - I've seen several RFPs from various government offices which are requiring some degree of IPv6 capability. This is going to drive the various large carriers who have these governments as customers to implement a generically working IPv6 solution. This is the same phenomenon that drove the explosive adoption rates of the ISO OSI protocol stack and the Ada programming language. Jim Shankland
Re: redundancy [was: something about arrogance]
Patrick Evans [EMAIL PROTECTED] writes: My first project, if network availability were a key issue, within any organisation would be to a) obtain [an AS number] and b) make use of it. Heh. How many bits in an AS number, again? Jim Shankland
