Some naughty person in either BBNPlanet or DeltaCom needs to re-read RFC 1918: traceroute to www.everybuddy.com (209.16.236.3), 30 hops max, 38 byte packets <snip> 12 p1-0.tamqfl1-cr4.bbnplanet.net (4.24.7.186) 50.724 ms 49.658 ms 50.428 ms 13 p0-0.itctampa.bbnplanet.net (4.24.176.6) 44.791 ms 44.299 ms 45.233 ms 14 10.254.0.14 (10.254.0.14) 46.290 ms 45.467 ms 47.701 ms 15 10.52.1.10 (10.52.1.10) 44.798 ms 46.038 ms 48.682 ms 16 1.ATM10-1.IDGAUB7513.TR.deltacom.net (209.192.87.198) 48.998 ms 49.069 ms 49.670 ms <snip>
You think that's bad? 8 oar-gw.customer.ALTER.NET (157.130.99.34) 28.264 ms 27.507 ms 28.202 ms 9 oeb2-atm1-0.columbus.oar.net (199.18.202.12) 45.809 ms 39.453 ms 29.246 ms 10 199.18.112.34 (199.18.112.34) 29.163 ms 29.501 ms 29.201 ms 11 10.255.200.10 (10.255.200.10) 30.086 ms 29.820 ms 29.221 ms 12 10.255.187.90 (10.255.187.90) 36.936 ms 35.646 ms 38.900 ms 13 156.63.105.42 (156.63.105.42) 35.973 ms 35.671 ms 36.004 ms 14 10.10.10.134 (10.10.10.134) 40.842 ms 42.585 ms 39.907 ms OARNet won't have to go to ARIN for address space for the next 10 years if they keep using 1918 space the way they are... --- John Fraizer EnterZone, Inc -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3a mQCNAzlo9RIAAAEEAK03prYoSsHIpASXliiU7HMshrsyT9KrigEKgy/ADVB6noQS Yp5nIlCt4BIV/8oYFloZcNxoo8LDchkDM+0arJcJ9236W+r7nf+UUu8e4hJz0y73 Jq6DEkGY64qbsgF/NBy5xQGnNFyY98KcIbp62m+C5UlTa3NNjIbMmesdFkq5AAUR tClKb2huIEZyYWl6ZXIgPEpvaG4uRnJhaXplckBFbnRlclpvbmUuTmV0PokAlQMF EDlo9RKGzJnrHRZKuQEBa/oEAKiYVn+zfRSeGxA5fdK9be1DpN0ygV0UX0ghIUsg LLAb4bhhGqwXz/my1w5oLIwa4YSOvHzkPzbC0jvEEfbQXlE/bGOqpK8VlznudGy4 DV4p0eu4Ij5gWAdkWmjyI4DfjJL8nVsat9HgE0/IsYi7xwujdvwz6TQWuxmNkQyx D3aS =WdqV -----END PGP PUBLIC KEY BLOCK----- On Fri, 14 Jul 2000, Shawn McMahon wrote:
Some naughty person in either BBNPlanet or DeltaCom needs to re-read RFC 1918:
traceroute to www.everybuddy.com (209.16.236.3), 30 hops max, 38 byte packets <snip> 12 p1-0.tamqfl1-cr4.bbnplanet.net (4.24.7.186) 50.724 ms 49.658 ms 50.428 ms 13 p0-0.itctampa.bbnplanet.net (4.24.176.6) 44.791 ms 44.299 ms 45.233 ms 14 10.254.0.14 (10.254.0.14) 46.290 ms 45.467 ms 47.701 ms 15 10.52.1.10 (10.52.1.10) 44.798 ms 46.038 ms 48.682 ms 16 1.ATM10-1.IDGAUB7513.TR.deltacom.net (209.192.87.198) 48.998 ms 49.069 ms 49.670 ms <snip>
On Fri, Jul 14, 2000 at 12:01:25PM -0400, Shawn McMahon wrote:
traceroute to www.everybuddy.com (209.16.236.3), 30 hops max, 38 byte packets <snip> 12 p1-0.tamqfl1-cr4.bbnplanet.net (4.24.7.186) 50.724 ms 49.658 ms 50.428 ms 13 p0-0.itctampa.bbnplanet.net (4.24.176.6) 44.791 ms 44.299 ms 45.233 ms 14 10.254.0.14 (10.254.0.14) 46.290 ms 45.467 ms 47.701 ms 15 10.52.1.10 (10.52.1.10) 44.798 ms 46.038 ms 48.682 ms 16 1.ATM10-1.IDGAUB7513.TR.deltacom.net (209.192.87.198) 48.998 ms 49.069 ms 49.670 ms <snip>
Certainly BBN, and probably DeltaCom, and anyone else on those previous 11 hops that allowed an RFC 1918 packet to transit. And you too for not filtering it. (Perhaps this is specifically a bogon test, and you've removed your filters, yes?)
[ On Friday, July 14, 2000 at 12:01:25 (-0400), Shawn McMahon wrote: ]
Subject: RFC 1918
Some naughty person in either BBNPlanet or DeltaCom needs to re-read RFC 1918:
If only BBNplanet and DeltaCom (and OARnet, and Rogers@Home, etc.,) were the only offenders.... I've got megabytes full of log files showing guilty parties and that's just from the very few nimrods who try to connect to my measly almost-zero-content servers! I've got even more megabytes of such crap from "owned" M$ boxes that are trying to scan my network, and I happen to know that they're not all just my @Home neighbours either. Of course not all network operators are fully and directly guilty of such abuses -- some are using broken equipment/software that leaks this kind of crap.... Still, they should know better. If I could only send a million-volt, mega-joule, packet back to every firewall that uses an RFC1918 source address to try and tell me that I'm not allowed to do IDENT queries to some server behind it that has already connected to me.... Since I now have a couple year's experience with filtering all RFC-1918 addresses either at the borders or on servers in various situations I can attest to the fact that one of the biggest problems with trying to use RFC-1918 properly in an enterprise situation is that it's damn hard to get everything to work correctly while at the same time honouring the letter and the spirit of the restrictions in RFC1918. I say this just to provide yet one more datum to show why ISPs should *NEVER* use RFC-1918 addresses in any of their public infrastructure, not ever. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (4)
-
John Fraizer
-
Mark Milhollan
-
Shawn McMahon
-
woods@weird.com