From wavetossed at googlemail.com Sun Feb 1 08:13:20 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 1 Feb 2009 14:13:20 +0000 Subject: can I ask mtu question In-Reply-To: <761682.59176.qm@web33301.mail.mud.yahoo.com> References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: <877585b00902010613i736a03cdp1d92ca27b35173f2@mail.gmail.com> > > What is max mtu in jumbo frame? > ls it 9000? > You might want to consider what the Internet/2 folks are doing because they have a few years of experience with Jumbo frames. This page < http://noc.net.internet2.edu/i2network/jumbo-frames.html> gives an overview and links to several presentations worth reading. And this link shows you the actual MTUs in use on Internet/2 devices. They are particularly useful for customers who want to send data between data centres because they usually have the ability to set a large MTU on all interfaces on their side. From damian at google.com Sun Feb 1 12:56:04 2009 From: damian at google.com (Damian Menscher) Date: Sun, 1 Feb 2009 10:56:04 -0800 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: <501016.78297.qm@web82903.mail.mud.yahoo.com> Message-ID: <6c98f4060902011056n4cbef433p8c94012c5c42a794@mail.gmail.com> This is directly related to the corrupted malware database. During that time, some messages were incorrectly marked as phishing. Gmail eng is currently working on a way to get those messages re-scanned, but in the meantime you may want to check your spam folder for any urgent messages you're missing: http://gmailblog.blogspot.com/2009/01/this-mornings-spam-filter-issue.html Damian On Sat, Jan 31, 2009 at 9:23 PM, Chris Mills wrote: > Anyone seeing phishing alerts for senders in this thread? > > http://farm4.static.flickr.com/3080/3243440012_d1f6f1e5e7_o.png > > -Chris > > On Sat, Jan 31, 2009 at 4:40 PM, Henry Linneweh wrote: > >> I think they clarify what happened here and are pretty straight up about >> it. >> http://www.nytimes.com/2009/02/01/technology/internet/01google.html?hp >> >> -henry >> >> >> >> >> ________________________________ >> From: Peter Beckman >> To: nanog at nanog.org >> Sent: Saturday, January 31, 2009 6:50:24 AM >> Subject: All Google Search Results: "This site may harm your computer." >> >> This morning whilest Googling, I got a bunch of "Permission Denied" to >> "/interstitial?..." URLs on Google. >> >> Then all my search results got listed as "This site may harm your >> computer." >> >> Is Google broken, or is the functionality of listing sites as broken, >> broken? >> >> http://dl.getdropbox.com/u/423476/google-broken.gif >> >> Beckman >> --------------------------------------------------------------------------- >> Peter Beckman Internet Guy >> beckman at angryox.com http://www.angryox.com/ >> --------------------------------------------------------------------------- >> > -- Damian Menscher :: Security Reliability Engineer :: Google :: +1.650.253.2757 From trey at kingfisherops.com Mon Feb 2 09:48:29 2009 From: trey at kingfisherops.com (Trey Darley) Date: Mon, 2 Feb 2009 16:48:29 +0100 (CET) Subject: Private use of non-RFC1918 IP space Message-ID: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Hi, y'all - Some colleagues and I are running into a bit of a problem. We've been using RFC 1918 Class A space but due to the way subnets have been allocated we are pondering the use of public IP space. As the network in question is strictly closed I don't anticipate any problems with this as the addresses would be unambiguous within our environment. I'm curious if anyone else is doing this. I'd be very interested in corresponding off-list with anyone who's in a similar position. Cheers, --Trey ++----------------------------------------------------------------------------++ Kingfisher Operations Trey Darley - Principal From ops.lists at gmail.com Mon Feb 2 09:52:49 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 2 Feb 2009 21:22:49 +0530 Subject: Private use of non-RFC1918 IP space In-Reply-To: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Message-ID: unless a site you want to reach is on the ip you are using... On Mon, Feb 2, 2009 at 9:18 PM, Trey Darley wrote: > Hi, y'all - > > Some colleagues and I are running into a bit of a problem. We've been > using RFC 1918 Class A space but due to the way subnets have been > allocated we are pondering the use of public IP space. As the network in > question is strictly closed I don't anticipate any problems with this as > the addresses would be unambiguous within our environment. I'm curious if > anyone else is doing this. > > I'd be very interested in corresponding off-list with anyone who's in a > similar position. > > Cheers, > --Trey > ++----------------------------------------------------------------------------++ > Kingfisher Operations > Trey Darley - Principal > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From pstewart at nexicomgroup.net Mon Feb 2 09:51:58 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 2 Feb 2009 10:51:58 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> What reason could you possibly have to use non RFC 1918 space on a closed network? It's very bad practice - unfortunately I do see it done sometimes.... Paul -----Original Message----- From: Trey Darley [mailto:trey at kingfisherops.com] Sent: February 2, 2009 10:48 AM To: nanog at nanog.org Subject: Private use of non-RFC1918 IP space Hi, y'all - Some colleagues and I are running into a bit of a problem. We've been using RFC 1918 Class A space but due to the way subnets have been allocated we are pondering the use of public IP space. As the network in question is strictly closed I don't anticipate any problems with this as the addresses would be unambiguous within our environment. I'm curious if anyone else is doing this. I'd be very interested in corresponding off-list with anyone who's in a similar position. Cheers, --Trey ++---------------------------------------------------------------------- ------++ Kingfisher Operations Trey Darley - Principal ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From jeff at ocjtech.us Mon Feb 2 09:57:00 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 2 Feb 2009 09:57:00 -0600 Subject: Private use of non-RFC1918 IP space In-Reply-To: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Message-ID: <935ead450902020757j32efc29eu9abeef0d4b806e41@mail.gmail.com> On Mon, Feb 2, 2009 at 9:48 AM, Trey Darley wrote: > > Some colleagues and I are running into a bit of a problem. We've been > using RFC 1918 Class A space but due to the way subnets have been > allocated we are pondering the use of public IP space. As the network in > question is strictly closed I don't anticipate any problems with this as > the addresses would be unambiguous within our environment. I'm curious if > anyone else is doing this. I'd recommend against it, because even though the network is not connected to the Internet now you never know what the future holds. Even if it's never connected there are always things that seem to pop up and cause problems. Also, if you're address allocation policy has been so badly managed that you've run out of space in 10.0.0.0/8 adding more IPs to the pool isn't going to help for very long. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From imb at protected-networks.net Mon Feb 2 09:58:32 2009 From: imb at protected-networks.net (Michael Butler) Date: Mon, 02 Feb 2009 10:58:32 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Message-ID: <49871828.5020908@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trey Darley wrote: > Some colleagues and I are running into a bit of a problem. We've been > using RFC 1918 Class A space but due to the way subnets have been > allocated we are pondering the use of public IP space. As the network in > question is strictly closed I don't anticipate any problems with this as > the addresses would be unambiguous within our environment. I'm curious if > anyone else is doing this. This is a *VERY BAD IDEA* - why not take the hit now rather than exponentiate the problem and, in so doing, make it nearly impossible to reverse later? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmHGCgACgkQQv9rrgRC1JLWrACfTxrfxz/6DFCCByldBqMv/MjL ssYAn3Se0GRA+s3Szn9dMUN8c7AlQzj/ =FZWG -----END PGP SIGNATURE----- From patrick at ianai.net Mon Feb 2 09:59:13 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 2 Feb 2009 10:59:13 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <935ead450902020757j32efc29eu9abeef0d4b806e41@mail.gmail.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <935ead450902020757j32efc29eu9abeef0d4b806e41@mail.gmail.com> Message-ID: <3D5C9229-4E59-4B4E-8B4E-D26886749136@ianai.net> On Feb 2, 2009, at 10:57 AM, Jeffrey Ollie wrote: > On Mon, Feb 2, 2009 at 9:48 AM, Trey Darley > wrote: >> >> Some colleagues and I are running into a bit of a problem. We've been >> using RFC 1918 Class A space but due to the way subnets have been >> allocated we are pondering the use of public IP space. As the >> network in >> question is strictly closed I don't anticipate any problems with >> this as >> the addresses would be unambiguous within our environment. I'm >> curious if >> anyone else is doing this. > > I'd recommend against it, because even though the network is not > connected to the Internet now you never know what the future holds. > Even if it's never connected there are always things that seem to pop > up and cause problems. > > Also, if you're address allocation policy has been so badly managed > that you've run out of space in 10.0.0.0/8 adding more IPs to the pool > isn't going to help for very long. It will if you manage it better. Fortunately, there's a /12 and a /24 still left. A /12 is more space than 99.99% of the networks on the Internet need, so why wouldn't that suffice instead of using "real" space. -- TTFN, patrick From streiner at cluebyfour.org Mon Feb 2 10:04:57 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 2 Feb 2009 11:04:57 -0500 (EST) Subject: Private use of non-RFC1918 IP space In-Reply-To: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Message-ID: On Mon, 2 Feb 2009, Trey Darley wrote: > Some colleagues and I are running into a bit of a problem. We've been > using RFC 1918 Class A space but due to the way subnets have been > allocated we are pondering the use of public IP space. As the network in > question is strictly closed I don't anticipate any problems with this as > the addresses would be unambiguous within our environment. I'm curious if > anyone else is doing this. > > I'd be very interested in corresponding off-list with anyone who's in a > similar position. Technically, yes you can use non-RFC1918 space in this way, but is definitely not a good idea. The needs of the people using the network could change at some point in the future, where some degree of Internet connectivity is needed, at which point your support headaches would multiply if you used non-1918 space in this manner. Is there a reason that other 1918 address ranges (172.16/12, 192.168/16) could not be used? jms From petelists at templin.org Mon Feb 2 10:06:43 2009 From: petelists at templin.org (Pete Templin) Date: Mon, 02 Feb 2009 10:06:43 -0600 Subject: Images from DR and NANOG45 Message-ID: <49871A13.6090203@templin.org> NANOG, Here's my compilation of photos from NANOG45 and the Dominican Republic. Most are taken by my girlfriend and I; some taken by others enjoying a chance to experiment. :) Feel free to share with anyone you wish, download, etc.. http://photos.templin.org/gallery/nanog45 Disclaimer: I'm learning HDR techniques, so some of my HDRs leave a bunch to be desired. Pete From jeroen at unfix.org Mon Feb 2 10:07:50 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 02 Feb 2009 17:07:50 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Message-ID: <49871A56.3080804@spaghetti.zurich.ibm.com> Trey Darley wrote: > Hi, y'all - > > Some colleagues and I are running into a bit of a problem. We've been > using RFC 1918 Class A space but due to the way subnets have been > allocated we are pondering the use of public IP space. As the network in > question is strictly closed I don't anticipate any problems with this as > the addresses would be unambiguous within our environment. I'm curious if > anyone else is doing this. Of course you can use public address space, and actually you should have been doing that already for years. The catch is of course that you just get it from your local RIR or LIR, thus making sure it is globally unique, as that is where the problem of RFC1918 lies for most people. Another trick is of course to start moving to IPv6: get a /48 or more from your local LIR/RIR and you have all the IPs you will ever need (unless you plan wrong and ask for too little ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From jgreco at ns.sol.net Mon Feb 2 10:07:11 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 2 Feb 2009 10:07:11 -0600 (CST) Subject: Private use of non-RFC1918 IP space In-Reply-To: <3D5C9229-4E59-4B4E-8B4E-D26886749136@ianai.net> from "Patrick W. Gilmore" at Feb 02, 2009 10:59:13 AM Message-ID: <200902021607.n12G7Br0006570@aurora.sol.net> > On Feb 2, 2009, at 10:57 AM, Jeffrey Ollie wrote: > > On Mon, Feb 2, 2009 at 9:48 AM, Trey Darley > > wrote: > >> > >> Some colleagues and I are running into a bit of a problem. We've been > >> using RFC 1918 Class A space but due to the way subnets have been > >> allocated we are pondering the use of public IP space. As the > >> network in > >> question is strictly closed I don't anticipate any problems with > >> this as > >> the addresses would be unambiguous within our environment. I'm > >> curious if > >> anyone else is doing this. > > > > I'd recommend against it, because even though the network is not > > connected to the Internet now you never know what the future holds. > > Even if it's never connected there are always things that seem to pop > > up and cause problems. > > > > Also, if you're address allocation policy has been so badly managed > > that you've run out of space in 10.0.0.0/8 adding more IPs to the pool > > isn't going to help for very long. > > It will if you manage it better. > > Fortunately, there's a /12 and a /24 still left. And a /16. (What's the /24?) And possibly some other space that is reserved-for-other-purposes. > A /12 is more space > than 99.99% of the networks on the Internet need, so why wouldn't that > suffice instead of using "real" space. If you absolutely, positively *had* to allocate another /8, it'd probably be best to look through Class A space for networks that are not likely to ever appear on the Internet. ISTR a bunch of them are assigned to the US military, for example. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From bruce at yoafrica.com Mon Feb 2 10:10:30 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Mon, 2 Feb 2009 18:10:30 +0200 Subject: Private use of non-RFC1918 IP space In-Reply-To: <49871828.5020908@protected-networks.net> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> Message-ID: <002201c98550$c50a1520$4f1e3f60$@com> Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't encounter any problems using it in a private network. -----Original Message----- From: Michael Butler [mailto:imb at protected-networks.net] Sent: Monday, February 02, 2009 5:59 PM To: trey at kingfisherops.com Cc: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trey Darley wrote: > Some colleagues and I are running into a bit of a problem. We've been > using RFC 1918 Class A space but due to the way subnets have been > allocated we are pondering the use of public IP space. As the network in > question is strictly closed I don't anticipate any problems with this as > the addresses would be unambiguous within our environment. I'm curious if > anyone else is doing this. This is a *VERY BAD IDEA* - why not take the hit now rather than exponentiate the problem and, in so doing, make it nearly impossible to reverse later? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmHGCgACgkQQv9rrgRC1JLWrACfTxrfxz/6DFCCByldBqMv/MjL ssYAn3Se0GRA+s3Szn9dMUN8c7AlQzj/ =FZWG -----END PGP SIGNATURE----- From Skywing at valhallalegends.com Mon Feb 2 10:14:54 2009 From: Skywing at valhallalegends.com (Skywing) Date: Mon, 2 Feb 2009 10:14:54 -0600 Subject: Private use of non-RFC1918 IP space Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6C00B345F00@caralain.haven.nynaeve.net> If you get an address reservation from a registry, then you could certainly use that space in a way that doesn't entail globally-reachable routing. In fact, IIRC one of the RFCs explicitly mentions this possibility in the event that overlapping private use address space usage makes interconnection between two networks otherwise unworkable. However, as everyone else had assumed you might be doing, "borrowing" unassigned or assigned-to-someone-else (for which all "unassigned" can eventually be expected to devolve into) is unwise. ? S -----Original Message----- From: Trey Darley Sent: Monday, February 02, 2009 07:48 To: nanog at nanog.org Subject: Private use of non-RFC1918 IP space Hi, y'all - Some colleagues and I are running into a bit of a problem. We've been using RFC 1918 Class A space but due to the way subnets have been allocated we are pondering the use of public IP space. As the network in question is strictly closed I don't anticipate any problems with this as the addresses would be unambiguous within our environment. I'm curious if anyone else is doing this. I'd be very interested in corresponding off-list with anyone who's in a similar position. Cheers, --Trey ++----------------------------------------------------------------------------++ Kingfisher Operations Trey Darley - Principal From tglassey at earthlink.net Mon Feb 2 10:21:45 2009 From: tglassey at earthlink.net (TSG) Date: Mon, 02 Feb 2009 08:21:45 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: <200902021607.n12G7Br0006570@aurora.sol.net> References: <200902021607.n12G7Br0006570@aurora.sol.net> Message-ID: <49871D99.3000404@earthlink.net> Joe Greco wrote: >> On Feb 2, 2009, at 10:57 AM, Jeffrey Ollie wrote: >> >>> On Mon, Feb 2, 2009 at 9:48 AM, Trey Darley >>> wrote: >>> >>>> Some colleagues and I are running into a bit of a problem. We've been >>>> using RFC 1918 Class A space but due to the way subnets have been >>>> allocated we are pondering the use of public IP space. As the >>>> network in >>>> question is strictly closed I don't anticipate any problems with >>>> this as >>>> the addresses would be unambiguous within our environment. I'm >>>> curious if >>>> anyone else is doing this. >>>> >>> I'd recommend against it, because even though the network is not >>> connected to the Internet now you never know what the future holds. >>> Even if it's never connected there are always things that seem to pop >>> up and cause problems. >>> >>> Also, if you're address allocation policy has been so badly managed >>> that you've run out of space in 10.0.0.0/8 adding more IPs to the pool >>> isn't going to help for very long. >>> >> It will if you manage it better. >> >> Fortunately, there's a /12 and a /24 still left. >> > > And a /16. (What's the /24?) And possibly some other space that is > reserved-for-other-purposes. > > >> A /12 is more space >> than 99.99% of the networks on the Internet need, so why wouldn't that >> suffice instead of using "real" space. >> > > If you absolutely, positively *had* to allocate another /8, it'd probably > be best to look through Class A space for networks that are not likely to > ever appear on the Internet. ISTR a bunch of them are assigned to the US > military, for example. > > ... JG > For which the unauthorized use of could be construed as a military attack if those pirated addresses ever appear on the open Internet from this ISP... No that's also a really bad idea. I find it really troublesome to believe that the subnetting on a site was so complex that it ate an entire /8. What I am betting is that for some reason that ISP wants its addressing to be totally flat and not replicated. Todd From sthaug at nethelp.no Mon Feb 2 11:03:57 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 02 Feb 2009 18:03:57 +0100 (CET) Subject: Private use of non-RFC1918 IP space In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> Message-ID: <20090202.180357.71143925.sthaug@nethelp.no> > What reason could you possibly have to use non RFC 1918 space on a > closed network? It's very bad practice - unfortunately I do see it done > sometimes.... There are sometimes good reasons to do this, for instance to ensure uniqueness in the face of mergers and acquisitions. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mikelieman at gmail.com Mon Feb 2 11:16:04 2009 From: mikelieman at gmail.com (mikelieman at gmail.com) Date: Mon, 02 Feb 2009 17:16:04 +0000 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.180357.71143925.sthaug@nethelp.no> Message-ID: <0016364ee1e4a41fda0461f2b58a@google.com> Some nitwits just grab one out of fat air. I've seen 192.169.xx and 192.254.xx randomly used before. On Feb 2, 2009 12:03pm, sthaug at nethelp.no wrote: > > What reason could you possibly have to use non RFC 1918 space on a > > > > closed network? It's very bad practice - unfortunately I do see it done > > > > sometimes.... > > > > > > There are sometimes good reasons to do this, for instance to ensure > > > uniqueness in the face of mergers and acquisitions. > > > > > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > > > > > From MatlockK at exempla.org Mon Feb 2 11:18:58 2009 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Mon, 2 Feb 2009 10:18:58 -0700 Subject: Private use of non-RFC1918 IP space In-Reply-To: <0016364ee1e4a41fda0461f2b58a@google.com> References: <20090202.180357.71143925.sthaug@nethelp.no> <0016364ee1e4a41fda0461f2b58a@google.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D3197@LMC-MAIL2.exempla.org> I've even seen at a previous place (note: 'previous') that decided to use 40.x.x.x for their internal IP space.... I find it hard to believe a company can mismanage their IP space that 10.0.0.0, 192.168.0.0, and 172.(16-31).0.0 are all used up, but then again, I shouldn't be surprised. Back in '96 or so, an ISP I was working at was giving out /24's for a 14.4 dialup account.... Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: mikelieman at gmail.com [mailto:mikelieman at gmail.com] Sent: Monday, February 02, 2009 10:16 AM To: sthaug at nethelp.no; pstewart at nexicomgroup.net; nanog at nanog.org Subject: Re: Re: Private use of non-RFC1918 IP space Some nitwits just grab one out of fat air. I've seen 192.169.xx and 192.254.xx randomly used before. On Feb 2, 2009 12:03pm, sthaug at nethelp.no wrote: > > What reason could you possibly have to use non RFC 1918 space on a > > > > closed network? It's very bad practice - unfortunately I do see it done > > > > sometimes.... > > > > > > There are sometimes good reasons to do this, for instance to ensure > > > uniqueness in the face of mergers and acquisitions. > > > > > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > > > > > From darcy at druid.net Mon Feb 2 11:20:25 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Mon, 2 Feb 2009 12:20:25 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.180357.71143925.sthaug@nethelp.no> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> Message-ID: <20090202122025.ffa25a66.darcy@druid.net> On Mon, 02 Feb 2009 18:03:57 +0100 (CET) sthaug at nethelp.no wrote: > > What reason could you possibly have to use non RFC 1918 space on a > > closed network? It's very bad practice - unfortunately I do see it done > > sometimes.... > > There are sometimes good reasons to do this, for instance to ensure > uniqueness in the face of mergers and acquisitions. How does that help? If you are renumbering due to a merger, couldn't you just agree on separate private space just as easily? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From Valdis.Kletnieks at vt.edu Mon Feb 2 11:38:47 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 02 Feb 2009 12:38:47 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Mon, 02 Feb 2009 12:20:25 EST." <20090202122025.ffa25a66.darcy@druid.net> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> <20090202122025.ffa25a66.darcy@druid.net> Message-ID: <24002.1233596327@turing-police.cc.vt.edu> On Mon, 02 Feb 2009 12:20:25 EST, "D'Arcy J.M. Cain" said: > On Mon, 02 Feb 2009 18:03:57 +0100 (CET) > sthaug at nethelp.no wrote: > > > What reason could you possibly have to use non RFC 1918 space on a > > > closed network? It's very bad practice - unfortunately I do see it done > > > sometimes.... > > > > There are sometimes good reasons to do this, for instance to ensure > > uniqueness in the face of mergers and acquisitions. > > How does that help? If you are renumbering due to a merger, couldn't > you just agree on separate private space just as easily? They don't renumber, they end up just double-NAT or triple-NAT betweem the merged units. I think one poor soul posted here that they had quintuple-NAT'ing going on due to a long string of mergers.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sthaug at nethelp.no Mon Feb 2 11:44:42 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 02 Feb 2009 18:44:42 +0100 (CET) Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202122025.ffa25a66.darcy@druid.net> References: <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> <20090202122025.ffa25a66.darcy@druid.net> Message-ID: <20090202.184442.104091625.sthaug@nethelp.no> > > There are sometimes good reasons to do this, for instance to ensure > > uniqueness in the face of mergers and acquisitions. > > How does that help? If you are renumbering due to a merger, couldn't > you just agree on separate private space just as easily? It would ensure that you could get the networks to communicate, without IP address conflicts, *before* you started any renumbering. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From patrick at ianai.net Mon Feb 2 11:47:05 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 2 Feb 2009 12:47:05 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <002201c98550$c50a1520$4f1e3f60$@com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: On Feb 2, 2009, at 11:10 AM, Bruce Grobler wrote: > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > encounter any problems using it in a private network. Until IANA runs out and gives that space to Google or MS or Comcast or $WHATEVER_THAT_NETWORK_TALKS_TO. -- TTFN, patrick From cmeidinger at sendmail.com Mon Feb 2 11:50:49 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 2 Feb 2009 18:50:49 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <24002.1233596327@turing-police.cc.vt.edu> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> <20090202122025.ffa25a66.darcy@druid.net> <24002.1233596327@turing-police.cc.vt.edu> Message-ID: <026E8577-1F97-409C-A80D-BEC163B3B0B4@sendmail.com> On 02.02.2009, at 18:38, Valdis.Kletnieks at vt.edu wrote: > On Mon, 02 Feb 2009 12:20:25 EST, "D'Arcy J.M. Cain" said: >> On Mon, 02 Feb 2009 18:03:57 +0100 (CET) >> sthaug at nethelp.no wrote: >>>> What reason could you possibly have to use non RFC 1918 space on a >>>> closed network? It's very bad practice - unfortunately I do see >>>> it done >>>> sometimes.... >>> >>> There are sometimes good reasons to do this, for instance to ensure >>> uniqueness in the face of mergers and acquisitions. Also to avoid being required to NAT at all. Security benefits IMHO from using RFC1918 space in a corporate network - you have an automatic requirement that there must be a NAT rule somewhere in order for a duplex connection to happen. However, in a more open environment like a university or a laboratory, there may be no reason to require all connections to be proxied/translated etc. >> How does that help? If you are renumbering due to a merger, couldn't >> you just agree on separate private space just as easily? > > They don't renumber, they end up just double-NAT or triple-NAT > betweem the > merged units. I think one poor soul posted here that they had > quintuple-NAT'ing going on due to a long string of mergers.... This is a bit off-topic, but I thought I'd mention that this is one reason I recommend use of the 172.16/12 block to people building or renumbering enterprise networks. Most people seem to use 10/8 in large organizations and 192.168/16 in smaller ones, so it raises your chances of not having to get into heavy natting down the road. My theory on this is that most people who don't deal with CIDR on a daily basis find the /12 netmask a bit confusing and just avoid the block at all. Cheers, Chris From leo.vegoda at icann.org Mon Feb 2 11:57:35 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 2 Feb 2009 09:57:35 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: On 02/02/2009 8:10, "Bruce Grobler" wrote: > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > encounter any problems using it in a private network. 1.0.0.0/8 will be allocated in the not too distant future. All currently unallocated unicast IPv4 /8s will be allocated in the not too distant future. Regards, Leo Vegoda From bpfankuch at cpgreeley.com Mon Feb 2 11:58:52 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Mon, 2 Feb 2009 10:58:52 -0700 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202122025.ffa25a66.darcy@druid.net> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> <20090202122025.ffa25a66.darcy@druid.net> Message-ID: <01759D50DC387C45A018FE1817CE27D7540DE98A52@CPExchange1.cpgreeley.com> Using public IP space in general is typically just asking for trouble. I worked with an "ISP" once who decided to use 192.0.0.0/24 for IP's to customers who didn't need a static ip. They did it not knowing what they were doing (oh you mean 192.0.0.0/8 isnt rfc1918) but very quickly they had to change it. In our current customer base we have run into it a few times where someone is using non rfc1918 space internally and propose changing it very quick as we have had several customers who don't know it, but need to get to something in that public space. If you happen to be the funny guy who uses an IP range from some tiny foreign off the wall country because "we will never need to connect to their IP space" remember that IP address allocations change and you won't think it's so funny when the company who provides your anti-virus moves their update servers to match your internal IP space. > There are sometimes good reasons to do this, for instance to ensure > uniqueness in the face of mergers and acquisitions. If you are going to force uniqueness and one of the parties in the merger was super smart in their original deployment and decided to use 10.0.0.0/8 for their network of 300 machines, force them to change to something smarter. Remind them how layer 3 networks inside of a single building work. Even if a network is not publically seen, you have to keep in mind how many machines see it while they might see a public network. A specific customer had a 216.xx.xx.0/24 network for their private production network. Their internal router also saw it and had an ACL on who could access it. Meaning their entire staff couldn't get to their collocated webserver when their provider re addressed that floor in the datacenter. All rambling aside, its much easier to renumber on the front end opposed to ending up with VPN natting that makes you cry on the inside. Think of the person who will take over your network when you eventually leave your position. >This is a bit off-topic, but I thought I'd mention that this is one reason I recommend use of the 172.16/12 block to people building >or renumbering enterprise networks. Most people seem to use 10/8 in large organizations and 192.168/16 in smaller ones, so it raises >your chances of not having to get into heavy natting down the road. My theory on this is that most people who don't deal with CIDR on >a daily basis find the /12 netmask a bit confusing and just avoid the block at all. Also a good point. Most of "support engineers" I run into think that 172.24.0.0 is public IP space. -----Original Message----- From: D'Arcy J.M. Cain [mailto:darcy at druid.net] Sent: Monday, February 02, 2009 10:20 AM To: sthaug at nethelp.no Cc: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space On Mon, 02 Feb 2009 18:03:57 +0100 (CET) sthaug at nethelp.no wrote: > > What reason could you possibly have to use non RFC 1918 space on a > > closed network? It's very bad practice - unfortunately I do see it done > > sometimes.... > > There are sometimes good reasons to do this, for instance to ensure > uniqueness in the face of mergers and acquisitions. How does that help? If you are renumbering due to a merger, couldn't you just agree on separate private space just as easily? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From thegameiam at yahoo.com Mon Feb 2 11:59:05 2009 From: thegameiam at yahoo.com (David Barak) Date: Mon, 2 Feb 2009 09:59:05 -0800 (PST) Subject: Private use of non-RFC1918 IP space Message-ID: <236585.23330.qm@web31811.mail.mud.yahoo.com> --- On Mon, 2/2/09, Patrick W. Gilmore wrote: > > Most ISP's, if not all, null route 1.0.0.0/8 therefore > you shouldn't > > encounter any problems using it in a private network. > > Until IANA runs out and gives that space to Google or MS or > Comcast or $WHATEVER_THAT_NETWORK_TALKS_TO. It all comes down to "what do you mean by 'private network'" doesn't it? If you operate an IP network which is air-gapped from all other IP networks, which IP address you use is irrelevant. If that network interconnects with (only) a provider/customer using RFC 1918 space, you either have to coordinate with them, NAT, or use non-RFC 1918 space. If you run a network which should only communicate with others through a proxy/firewall/NAT device, how much does it matter what's on the inside? Of course, the risk of using IP addresses which are not uniquely assigned to you is that there will be an overlap somewhere. Whether the risk is greater inside or outside of RFC 1918, I leave for others to puzzle out (although it should be noted that organizational M&A activity makes hash of the best-laid IP address schema). David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From darcy at druid.net Mon Feb 2 11:59:35 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Mon, 2 Feb 2009 12:59:35 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.184442.104091625.sthaug@nethelp.no> References: <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> <20090202122025.ffa25a66.darcy@druid.net> <20090202.184442.104091625.sthaug@nethelp.no> Message-ID: <20090202125935.f351d377.darcy@druid.net> On Mon, 02 Feb 2009 18:44:42 +0100 (CET) sthaug at nethelp.no wrote: > > How does that help? If you are renumbering due to a merger, couldn't > > you just agree on separate private space just as easily? > > It would ensure that you could get the networks to communicate, without > IP address conflicts, *before* you started any renumbering. Can you expand? I assume that everyone understand VPNs so connecting over the Internet is not the issue. If you pick a public IP block you still have to agree on that block. How is using a public block different than agreeing on a private one? I apologize if I'm just being dense this morning. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From sthaug at nethelp.no Mon Feb 2 12:06:58 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 02 Feb 2009 19:06:58 +0100 (CET) Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202125935.f351d377.darcy@druid.net> References: <20090202122025.ffa25a66.darcy@druid.net> <20090202.184442.104091625.sthaug@nethelp.no> <20090202125935.f351d377.darcy@druid.net> Message-ID: <20090202.190658.78766688.sthaug@nethelp.no> > > > How does that help? If you are renumbering due to a merger, couldn't > > > you just agree on separate private space just as easily? > > > > It would ensure that you could get the networks to communicate, without > > IP address conflicts, *before* you started any renumbering. > > Can you expand? I assume that everyone understand VPNs so connecting > over the Internet is not the issue. If you pick a public IP block you > still have to agree on that block. How is using a public block > different than agreeing on a private one? Company A uses public IP block A internally. Company B uses public IP block B internally. Company A and B later merge, and connect their networks. No conflict, no renumbering needed (at least not right away). Compare this with company A and B both using overlapping part of for instance 192.168.0.0/16, and then merging. Conflict ensues, renumbering or NATs required in order to connect the networks. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From asenci at gmail.com Mon Feb 2 12:15:06 2009 From: asenci at gmail.com (Andre Sencioles Vitorio Oliveira) Date: Mon, 2 Feb 2009 16:15:06 -0200 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.190658.78766688.sthaug@nethelp.no> References: <20090202122025.ffa25a66.darcy@druid.net> <20090202.184442.104091625.sthaug@nethelp.no> <20090202125935.f351d377.darcy@druid.net> <20090202.190658.78766688.sthaug@nethelp.no> Message-ID: <34A84E68-02F1-46EB-A2F4-8C459C675C2C@gmail.com> What about this? Genius from company A chooses public IP block A. Genius from company B chooses public IP block A. Genius collision detected... On Feb 2, 2009, at 4:06 PM, sthaug at nethelp.no wrote: > Company A uses public IP block A internally. Company B uses public IP > block B internally. Company A and B later merge, and connect their > networks. No conflict, no renumbering needed (at least not right > away). > > Compare this with company A and B both using overlapping part of for > instance 192.168.0.0/16, and then merging. Conflict ensues, > renumbering > or NATs required in order to connect the networks. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no Andre Sencioles Vitorio Oliveira asenci at gmail.com From bygg at cafax.se Mon Feb 2 19:22:39 2009 From: bygg at cafax.se (Johnny Eriksson) Date: Mon, 2 Feb 2009 19:22:39 WET Subject: Private use of non-RFC1918 IP space In-Reply-To: Your message of Mon, 2 Feb 2009 10:51:58 -0500 Message-ID: "Paul Stewart" wrote: > What reason could you possibly have to use non RFC 1918 space on a > closed network? It's very bad practice - unfortunately I do see it done > sometimes.... Really really LARGE scalability testing that needs more addresses than RFC1918 gives you. In a closed lab. Yes, it is ugly. Been there. Sometimes ugly can not be avoided. > Paul --Johnny From darcy at druid.net Mon Feb 2 12:30:47 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Mon, 2 Feb 2009 13:30:47 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.190658.78766688.sthaug@nethelp.no> References: <20090202122025.ffa25a66.darcy@druid.net> <20090202.184442.104091625.sthaug@nethelp.no> <20090202125935.f351d377.darcy@druid.net> <20090202.190658.78766688.sthaug@nethelp.no> Message-ID: <20090202133047.9ecb7d82.darcy@druid.net> On Mon, 02 Feb 2009 19:06:58 +0100 (CET) sthaug at nethelp.no wrote: > Company A uses public IP block A internally. Company B uses public IP OK, so we start out with a bad network design then. > block B internally. Company A and B later merge, and connect their > networks. No conflict, no renumbering needed (at least not right away). Maybe. What if they both happened to choose 1.2.3.4/8? Is this just a matter of decreasing the odds of a conflict? It still seems like bad network management to me. > Compare this with company A and B both using overlapping part of for > instance 192.168.0.0/16, and then merging. Conflict ensues, renumbering > or NATs required in order to connect the networks. Right. One side needs to change a config file in their DHCP server and maybe their internal DNS. If they need to change much more than that then its time for a network re-engineering anyway. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From tico-nanog at raapid.net Mon Feb 2 12:35:29 2009 From: tico-nanog at raapid.net (Tico) Date: Mon, 02 Feb 2009 12:35:29 -0600 Subject: Private use of non-RFC1918 IP space In-Reply-To: <34A84E68-02F1-46EB-A2F4-8C459C675C2C@gmail.com> References: <20090202122025.ffa25a66.darcy@druid.net> <20090202.184442.104091625.sthaug@nethelp.no> <20090202125935.f351d377.darcy@druid.net> <20090202.190658.78766688.sthaug@nethelp.no> <34A84E68-02F1-46EB-A2F4-8C459C675C2C@gmail.com> Message-ID: <49873CF1.5010206@raapid.net> Andre Sencioles Vitorio Oliveira wrote: > What about this? > > Genius from company A chooses public IP block A. > Genius from company B chooses public IP block A. > > Genius collision detected... That's pretty nasty. However this should be able to mitigate some of the ugly scenarios brought up in this thread: http://undeadly.org/cgi?action=article&sid=20090127205841 Mind you, proper due-diligence could avoid most of these, and/or companies not all choosing to use the default 192.168.{0,1}.0/24 that their SOHO Netgear/Linksys router ships configured with. -Tico > > > On Feb 2, 2009, at 4:06 PM, sthaug at nethelp.no wrote: >> Company A uses public IP block A internally. Company B uses public IP >> block B internally. Company A and B later merge, and connect their >> networks. No conflict, no renumbering needed (at least not right away). >> >> Compare this with company A and B both using overlapping part of for >> instance 192.168.0.0/16, and then merging. Conflict ensues, renumbering >> or NATs required in order to connect the networks. >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > Andre Sencioles Vitorio Oliveira > asenci at gmail.com > > > > From darcy at druid.net Mon Feb 2 12:42:05 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Mon, 2 Feb 2009 13:42:05 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <026E8577-1F97-409C-A80D-BEC163B3B0B4@sendmail.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> <20090202122025.ffa25a66.darcy@druid.net> <24002.1233596327@turing-police.cc.vt.edu> <026E8577-1F97-409C-A80D-BEC163B3B0B4@sendmail.com> Message-ID: <20090202134205.dd4c63e6.darcy@druid.net> On Mon, 2 Feb 2009 18:50:49 +0100 Chris Meidinger wrote: > On 02.02.2009, at 18:38, Valdis.Kletnieks at vt.edu wrote: > >>>> What reason could you possibly have to use non RFC 1918 space on a > >>>> closed network? It's very bad practice - unfortunately I do see Of course, this is a different question. the discussion started over people using randomly selected non RFC 1918 space. Using your own public IP block in a closed network is another issue. I see no operational issue there. There is the social issue of using up scarce resources of course. > Also to avoid being required to NAT at all. Security benefits IMHO > from using RFC1918 space in a corporate network - you have an > automatic requirement that there must be a NAT rule somewhere in order > for a duplex connection to happen. However, in a more open environment > like a university or a laboratory, there may be no reason to require > all connections to be proxied/translated etc. In which case you are using properly assigned IP space. > This is a bit off-topic, but I thought I'd mention that this is one > reason I recommend use of the 172.16/12 block to people building or > renumbering enterprise networks. Most people seem to use 10/8 in large > organizations and 192.168/16 in smaller ones, so it raises your > chances of not having to get into heavy natting down the road. My > theory on this is that most people who don't deal with CIDR on a daily > basis find the /12 netmask a bit confusing and just avoid the block at > all. My office is small so I just grabbed 192.168.250.0/24. The 250 was taken from the office address. It was a level of randomness that made conflict with future VPN arrangements less likely. Not impossible, of course. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From dhetzel at gmail.com Mon Feb 2 12:45:28 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 2 Feb 2009 13:45:28 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: <7db2dcf90902021045x5bbb6a41l863b38f71d902ead@mail.gmail.com> On a related note, do you think that 0.0.0.0/8 (excluding 0.0.0.0/32, of course :) ) will be feasible for allocation and use ? On Mon, Feb 2, 2009 at 12:57 PM, Leo Vegoda wrote: > On 02/02/2009 8:10, "Bruce Grobler" wrote: > > > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > > encounter any problems using it in a private network. > > 1.0.0.0/8 will be allocated in the not too distant future. All currently > unallocated unicast IPv4 /8s will be allocated in the not too distant > future. > > Regards, > > Leo Vegoda > > > From rays at maine.edu Mon Feb 2 12:50:20 2009 From: rays at maine.edu (Soucy, Ray) Date: Mon, 2 Feb 2009 13:50:20 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Message-ID: <36243D984F88BA4ABD1E0EFC1E61B9896524C1@fudd.ad.maine.edu> > Some colleagues and I are running into a bit of a problem. We've been > using RFC 1918 Class A space but due to the way subnets have been > allocated we are pondering the use of public IP space. What you are suggesting is unacceptable. You need to allocate your private space more efficiently. It should be enough for anyone. > As the network in > question is strictly closed I don't anticipate any problems with this as > the addresses would be unambiguous within our environment. I'm curious if > anyone else is doing this. No. Nobody else is doing this. You should never make use of address space that has not been assigned to you (either through a regional authority or an RFC) for use, regardless of how closed you think your network is. > I'd be very interested in corresponding off-list with anyone who's in a > similar position. I think you need to post a new request asking for help on how to efficiently allocate RFC 1918 space. >From your website it looks like you're a consultant... If you're acting as a consultant for someone please do not violate the RFCs, they exist for a reason. Ultimately you're creating a nightmare for the person who comes next and is tasked to clean your mess. From sthaug at nethelp.no Mon Feb 2 12:55:49 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 02 Feb 2009 19:55:49 +0100 (CET) Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202133047.9ecb7d82.darcy@druid.net> References: <20090202125935.f351d377.darcy@druid.net> <20090202.190658.78766688.sthaug@nethelp.no> <20090202133047.9ecb7d82.darcy@druid.net> Message-ID: <20090202.195549.112567811.sthaug@nethelp.no> > > Company A uses public IP block A internally. Company B uses public IP > > OK, so we start out with a bad network design then. No. We start with blocks A and B which are both properly allocated by the relevant addressing authorities. > > block B internally. Company A and B later merge, and connect their > > networks. No conflict, no renumbering needed (at least not right away). > > Maybe. What if they both happened to choose 1.2.3.4/8? Is this just a > matter of decreasing the odds of a conflict? It still seems like bad > network management to me. My assumption throughout this whole discussion, which clearly has not been understood, is that the public IP block used internally is a properly allocated by the relevant addressing authority. That is, for me, the whole point of using public addresses to guarantee uniqueness. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From MatlockK at exempla.org Mon Feb 2 13:01:30 2009 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Mon, 2 Feb 2009 12:01:30 -0700 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.195549.112567811.sthaug@nethelp.no> References: <20090202125935.f351d377.darcy@druid.net><20090202.190658.78766688.sthaug@nethelp.no><20090202133047.9ecb7d82.darcy@druid.net> <20090202.195549.112567811.sthaug@nethelp.no> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D31A0@LMC-MAIL2.exempla.org> I see 2 problems off the top of my head with using public IP blocks for private networks. 1) You're not going to be able to reach servers/services/etc that actually have allocated those IP blocks. (May or may not affect you, but that's your issue to deal with in the future). 2) (and more important) It really makes it easy to 'accidentally' announce that public IP block out in the future, unless you have proper announce filters in place (And if something as basic as subnetting isn't done properly, I doubt route filtering is either). This one not only affects you, but affects the netblock that gets mistakenly announced out. RFC1918 space was designed to prevent these issues. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: sthaug at nethelp.no [mailto:sthaug at nethelp.no] Sent: Monday, February 02, 2009 11:56 AM To: darcy at druid.net Cc: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space > > Company A uses public IP block A internally. Company B uses public IP > > OK, so we start out with a bad network design then. No. We start with blocks A and B which are both properly allocated by the relevant addressing authorities. > > block B internally. Company A and B later merge, and connect their > > networks. No conflict, no renumbering needed (at least not right away). > > Maybe. What if they both happened to choose 1.2.3.4/8? Is this just a > matter of decreasing the odds of a conflict? It still seems like bad > network management to me. My assumption throughout this whole discussion, which clearly has not been understood, is that the public IP block used internally is a properly allocated by the relevant addressing authority. That is, for me, the whole point of using public addresses to guarantee uniqueness. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From pstewart at nexicomgroup.net Mon Feb 2 13:01:29 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 2 Feb 2009 14:01:29 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.195549.112567811.sthaug@nethelp.no> References: <20090202125935.f351d377.darcy@druid.net><20090202.190658.78766688.sthaug@nethelp.no><20090202133047.9ecb7d82.darcy@druid.net> <20090202.195549.112567811.sthaug@nethelp.no> Message-ID: <89D27DE3375BB6428DDCC2927489826A01F80178@nexus.nexicomgroup.net> Yeah, agreed.... I had a customer last week call us because we were "blocking them from an important site". After someone called them they found we could access the website no problem... upon further investigation we found their internal IP space had been numbered as 157.166.226.0/24. When we asked them why this IP was used, they told us that a $200/hour network consultant had upgraded their network last week with new Windows servers, new router, new etc. etc. etc.... and that this new IP numbering "sounded like a good number"... Politely told them they were paying too much and next time call someone who knows what they are doing.... "you got ripped off, sorry about your luck".... Oh, and their internal IP space = www.cnn.com ;) Paul -----Original Message----- From: sthaug at nethelp.no [mailto:sthaug at nethelp.no] Sent: February 2, 2009 1:56 PM To: darcy at druid.net Cc: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space > > Company A uses public IP block A internally. Company B uses public IP > > OK, so we start out with a bad network design then. No. We start with blocks A and B which are both properly allocated by the relevant addressing authorities. > > block B internally. Company A and B later merge, and connect their > > networks. No conflict, no renumbering needed (at least not right away). > > Maybe. What if they both happened to choose 1.2.3.4/8? Is this just a > matter of decreasing the odds of a conflict? It still seems like bad > network management to me. My assumption throughout this whole discussion, which clearly has not been understood, is that the public IP block used internally is a properly allocated by the relevant addressing authority. That is, for me, the whole point of using public addresses to guarantee uniqueness. Steinar Haug, Nethelp consulting, sthaug at nethelp.no ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From leo.vegoda at icann.org Mon Feb 2 13:02:33 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 2 Feb 2009 11:02:33 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: <7db2dcf90902021045x5bbb6a41l863b38f71d902ead@mail.gmail.com> Message-ID: On 02/02/2009 10:45, "Dorn Hetzel" wrote: > On a related note, do you think that 0.0.0.0/8 (excluding > 0.0.0.0/32 , of course :) ) will be feasible for > allocation and use ? 0.0.0.0/8 is reserved for self-identification. See RFC 1700: (b) {0, } Specified host on this network. Can only be used as a source address. Regards, Leo Vegoda From dhetzel at gmail.com Mon Feb 2 13:11:03 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 2 Feb 2009 14:11:03 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <7db2dcf90902021045x5bbb6a41l863b38f71d902ead@mail.gmail.com> Message-ID: <7db2dcf90902021111o2b7867efl532a5dd687e19f6b@mail.gmail.com> Does anyone actually use any part of 0/8 other than 0/32 for self identification? On Mon, Feb 2, 2009 at 2:02 PM, Leo Vegoda wrote: > On 02/02/2009 10:45, "Dorn Hetzel" wrote: > > > On a related note, do you think that 0.0.0.0/8 > (excluding > > 0.0.0.0/32 , of course :) ) will be feasible for > > allocation and use ? > > 0.0.0.0/8 is reserved for self-identification. See RFC 1700: > > (b) {0, } > > Specified host on this network. Can only be used as a > source address. > > Regards, > > Leo Vegoda > > From marquis at roble.com Mon Feb 2 13:33:52 2009 From: marquis at roble.com (Roger Marquis) Date: Mon, 2 Feb 2009 11:33:52 -0800 (PST) Subject: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: <20090202193352.29DCD2B21C3@mx5.roble.com> D'Arcy J.M. Cain wrote: > Right. One side needs to change a config file in their DHCP server and > maybe their internal DNS. If they need to change much more than that > then its time for a network re-engineering anyway. That, IME, is the real issue here. The re/engineering that should be part of an M&A is too often under-budgeted. There is not enough staff, time, or budget to do the needful as it were. Same thing occurs across IT. In most cases we see it as deferred maintenance. Hardware and software upgrades, routing updates, security, etc. are all a hard sell when the network is working fine and some other department can better demonstrate a need for budget. In all of these cases IT management needs to make the case, submit the CYAs, and let C-levels take it from there. Be glad you're a network engineer. Deferred maintenance is much more of a problem on the systems administration side of IT. One of the largest ISPs I know has state of the art networks but its server farms are running an OS that has been out of support for years. One of the largest schools I know ran their entire email infrastructure on hardware that hadn't been upgradable for years... all with predictable results. Roger Marquis From drc at virtualized.org Mon Feb 2 13:47:30 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 2 Feb 2009 11:47:30 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: <002201c98550$c50a1520$4f1e3f60$@com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > encounter any problems using it in a private network. Is this true? This will cause endless entertainment when IANA allocates 1.0.0.0/8 sometime within the next two or three years... Regards, -drc From patrick at ianai.net Mon Feb 2 13:49:12 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 2 Feb 2009 14:49:12 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: On Feb 2, 2009, at 2:47 PM, David Conrad wrote: > On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: >> Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't >> encounter any problems using it in a private network. > > Is this true? > > This will cause endless entertainment when IANA allocates 1.0.0.0/8 > sometime within the next two or three years... Just like the "endless entertainment" when IANA has allocated any new / 8 recently. Anyone filtering without either daily (weekly?) checks, or using an automated system (e.g. Team Cymru) is being silly. -- TTFN, patrick From david at davidcoulson.net Mon Feb 2 13:58:21 2009 From: david at davidcoulson.net (David Coulson) Date: Mon, 02 Feb 2009 14:58:21 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: <4987505D.1020102@davidcoulson.net> I'm curious - Any particular technical reason not to assign out of 0.0.0.0/8? Can't say I've ever tried to use it, but I'd think it should work. David Conrad wrote: > Is this true? > > This will cause endless entertainment when IANA allocates 1.0.0.0/8 > sometime within the next two or three years... > From bruce at yoafrica.com Mon Feb 2 14:07:11 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Mon, 2 Feb 2009 22:07:11 +0200 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: <004601c98571$d58c7340$80a559c0$@com> Yep!, go ahead and trace it. -----Original Message----- From: David Conrad [mailto:drc at virtualized.org] Sent: Monday, February 02, 2009 9:48 PM To: Bruce Grobler Cc: NANOG list Subject: Re: Private use of non-RFC1918 IP space On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > encounter any problems using it in a private network. Is this true? This will cause endless entertainment when IANA allocates 1.0.0.0/8 sometime within the next two or three years... Regards, -drc From darcy at druid.net Mon Feb 2 14:09:14 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Mon, 2 Feb 2009 15:09:14 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.195549.112567811.sthaug@nethelp.no> References: <20090202125935.f351d377.darcy@druid.net> <20090202.190658.78766688.sthaug@nethelp.no> <20090202133047.9ecb7d82.darcy@druid.net> <20090202.195549.112567811.sthaug@nethelp.no> Message-ID: <20090202150914.9fe9053c.darcy@druid.net> On Mon, 02 Feb 2009 19:55:49 +0100 (CET) sthaug at nethelp.no wrote: > My assumption throughout this whole discussion, which clearly has not > been understood, is that the public IP block used internally is a > properly allocated by the relevant addressing authority. That is, for > me, the whole point of using public addresses to guarantee uniqueness. OK, I understand. My assumption was that the IP space was assigned randomly since that was the premise that started this discussion. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From david at davidcoulson.net Mon Feb 2 14:11:03 2009 From: david at davidcoulson.net (David Coulson) Date: Mon, 02 Feb 2009 15:11:03 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <004601c98571$d58c7340$80a559c0$@com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <004601c98571$d58c7340$80a559c0$@com> Message-ID: <49875357.3020503@davidcoulson.net> I can mtr to 1.1.1.1 via Qwest :-) Bruce Grobler wrote: > Yep!, go ahead and trace it. > > -----Original Message----- > From: David Conrad [mailto:drc at virtualized.org] > Sent: Monday, February 02, 2009 9:48 PM > To: Bruce Grobler > Cc: NANOG list > Subject: Re: Private use of non-RFC1918 IP space > > On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: > >> Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't >> encounter any problems using it in a private network. >> > > Is this true? > > This will cause endless entertainment when IANA allocates 1.0.0.0/8 > sometime within the next two or three years... > > Regards, > -drc > > > From nanog at daork.net Mon Feb 2 14:19:18 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 3 Feb 2009 09:19:18 +1300 Subject: Private use of non-RFC1918 IP space In-Reply-To: <002201c98550$c50a1520$4f1e3f60$@com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: <2D161455-CADA-4BC1-B874-3629E8E208A8@daork.net> On 3/02/2009, at 5:10 AM, Bruce Grobler wrote: > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > encounter any problems using it in a private network. route-views.oregon-ix.net>sh ip bgp 1.0.0.0 BGP routing table entry for 0.0.0.0/0, version 3321685 ... I think you will find that "most ISPs, if not all" in the DFZ "null route" 0.0.0.0/0. If they don't have a route covering 1.0.0.0/8, of course packets destined to that prefix will be dropped. -- Nathan Ward From stephen at sprunk.org Mon Feb 2 14:28:33 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 02 Feb 2009 14:28:33 -0600 Subject: Private use of non-RFC1918 IP space In-Reply-To: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> Message-ID: <49875771.3060202@sprunk.org> Trey Darley wrote: > Some colleagues and I are running into a bit of a problem. We've been using RFC 1918 Class A space but due to the way subnets have been allocated we are pondering the use of public IP space. As the network in question is strictly closed I don't anticipate any problems with this as the addresses would be unambiguous within our environment. I'm curious if anyone else is doing this. > "Closed" networks nearly always end up getting connected to public networks, either by intent or by accident. If you act as if your network will remain "closed" forever, e.g. by using public addresses that are (or will be) assigned to someone else, you're going to cause a lot of headaches for yourself or your replacement down the road, eventually. Contrary to popular belief, ARIN (and possibly other RIRs) _will_ assign public IPs for private/closed networks if you can explain why RFC1918 space will not suffice for your needs, e.g. because you are running a private internetwork between multiple companies and thus NAT/RFC1918 is simply not viable due to the number of ASes and the difficulty in avoiding collisions or the sheer number of hosts... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From adrian at creative.net.au Mon Feb 2 14:36:32 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 3 Feb 2009 05:36:32 +0900 Subject: Private use of non-RFC1918 IP space In-Reply-To: <2D161455-CADA-4BC1-B874-3629E8E208A8@daork.net> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <2D161455-CADA-4BC1-B874-3629E8E208A8@daork.net> Message-ID: <20090202203632.GA1494@skywalker.creative.net.au> On Tue, Feb 03, 2009, Nathan Ward wrote: > I think you will find that "most ISPs, if not all" in the DFZ "null > route" 0.0.0.0/0. > If they don't have a route covering 1.0.0.0/8, of course packets > destined to that prefix will be dropped. Damn those backup default routes then... violet:~ adrian$ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=246 time=584.909 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=246 time=478.598 ms ... 6 mumble.gblx.net (69.x.y.z) 11.907 ms 14.086 ms 16.931 ms 7 ge-2-0-0-10g.scr2.nyc1.gblx.net (67.17.108.233) 18.269 ms 16.460 ms 16.369 ms 8 64-76-84-39.static.impsat.com.co (64.76.84.39) 218.169 ms * 136.983 ms $ Reminds me of when I found various ISPs in Asia "leaking" routes somehow, and large chunks of RFC1918 space suddenly became reachable. Imagine my surprise when someone started seeing SNMP data for some "auto detected" SNMP agent IPs suddenly started returning statistics. For SNMP community "public". For randomly named kit, like "netgear" and "cisco" hostnames. Adrian (ObAmusing: said corporate suddenly thought they had more assets and wanted us to track it down for them; they wouldn't take "its not yours" as an answer. Why? Because RFC1918 addresses are private, right, and obviously that means they're -only- visible on -their- network. Thankfully I was a consultant and that was absolutely not in my scope of responsibility..) From randy at psg.com Mon Feb 2 14:49:16 2009 From: randy at psg.com (Randy Bush) Date: Tue, 03 Feb 2009 05:49:16 +0900 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090202.180357.71143925.sthaug@nethelp.no> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> Message-ID: i am surprised that no one has mentioned that it is not unusual for folk, even isps, to use space assigned to the us military but never routed on the public internet. i was exceedingly amused when first i did a traceroute from bologna. randy From stephen at sprunk.org Mon Feb 2 14:52:43 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 02 Feb 2009 14:52:43 -0600 Subject: Private use of non-RFC1918 IP space In-Reply-To: <49871D99.3000404@earthlink.net> References: <200902021607.n12G7Br0006570@aurora.sol.net> <49871D99.3000404@earthlink.net> Message-ID: <49875D1B.4010908@sprunk.org> TSG wrote: > I find it really troublesome to believe that the subnetting on a site > was so complex that it ate an entire /8. What I am betting is that for > some reason that ISP wants its addressing to be totally flat and not > replicated. The subnetting doesn't need to be "complex"; they may simply have a large number of small sites, or a moderate number of relatively large sites, that will eat up more than a /8's worth of addresses. There _do_ exist companies with 100,000+ locations and a few dozen devices per location; throw in the necessary aggregation so the routers don't fall over and you're looking at NATing multiple instances of 10/8 -- and I know from experience that's not fun. However, the OP implies that his problem is caused by a poor subnetting scheme in 10/8; the correct solution in that case is to fix the subnetting -- but mgmt may not be willing to pay the labor (or other) costs of that. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From thegameiam at yahoo.com Mon Feb 2 14:53:35 2009 From: thegameiam at yahoo.com (David Barak) Date: Mon, 2 Feb 2009 12:53:35 -0800 (PST) Subject: Private use of non-RFC1918 IP space Message-ID: <688777.58010.qm@web31808.mail.mud.yahoo.com> --- On Mon, 2/2/09, David Coulson wrote: > I'm curious - Any particular > technical reason not to assign out of 0.0.0.0/8? Can't say > I've ever tried to use it, but I'd think it should work. I have long wondered why two entire /8s are reserved for host self identification (0 and 127, of course...) - it's too bad that we can't use either those or class E space while folks {delay | prepare for} ipv6 adoption... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From karnaugh at karnaugh.za.net Mon Feb 2 15:06:42 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 02 Feb 2009 23:06:42 +0200 Subject: Private use of non-RFC1918 IP space In-Reply-To: <0016364ee1e4a41fda0461f2b58a@google.com> References: <0016364ee1e4a41fda0461f2b58a@google.com> Message-ID: <49876062.1020601@karnaugh.za.net> On 2009/02/02 07:16 PM mikelieman at gmail.com wrote: > Some nitwits just grab one out of fat air. > > I've seen 192.169.xx and 192.254.xx randomly used before. > Seen 198/8, 196.200/16 and 172./16 And these people are shocked when I tell them to renumber before I'll touch their network.. From m.hallgren at free.fr Mon Feb 2 15:14:38 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 02 Feb 2009 22:14:38 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: <1233609278.28383.44.camel@home> Le lundi 02 f?vrier 2009 ? 19:22 +0000, Johnny Eriksson a ?crit : > "Paul Stewart" wrote: > > > What reason could you possibly have to use non RFC 1918 space on a > > closed network? It's very bad practice - unfortunately I do see it done > > sometimes.... > > Really really LARGE scalability testing that needs more addresses than > RFC1918 gives you. Use IPv6. Cheers, mh > In a closed lab. Yes, it is ugly. > > Been there. > > Sometimes ugly can not be avoided. > > > Paul > > --Johnny > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From cra at WPI.EDU Mon Feb 2 15:31:43 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 2 Feb 2009 16:31:43 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <49876062.1020601@karnaugh.za.net> References: <0016364ee1e4a41fda0461f2b58a@google.com> <49876062.1020601@karnaugh.za.net> Message-ID: <20090202213143.GO3963@angus.ind.WPI.EDU> On Mon, Feb 02, 2009 at 11:06:42PM +0200, Colin Alston wrote: > On 2009/02/02 07:16 PM mikelieman at gmail.com wrote: >> Some nitwits just grab one out of fat air. >> >> I've seen 192.169.xx and 192.254.xx randomly used before. > > Seen 198/8, 196.200/16 and 172./16 > > And these people are shocked when I tell them to renumber before I'll > touch their network.. I've seen 11/8. From Valdis.Kletnieks at vt.edu Mon Feb 2 15:40:51 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 02 Feb 2009 16:40:51 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Mon, 02 Feb 2009 12:53:35 PST." <688777.58010.qm@web31808.mail.mud.yahoo.com> References: <688777.58010.qm@web31808.mail.mud.yahoo.com> Message-ID: <35113.1233610851@turing-police.cc.vt.edu> On Mon, 02 Feb 2009 12:53:35 PST, David Barak said: > I have long wondered why two entire /8s are reserved for host self > identification( 0 and 127, of course...) It's part of the whole '2**32 addresses should be enough" viewpoint (keep in mind they were coming from NCP, that had a limit of 256 addresses). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mansaxel at besserwisser.org Mon Feb 2 16:09:42 2009 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Mon, 02 Feb 2009 23:09:42 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <34A84E68-02F1-46EB-A2F4-8C459C675C2C@gmail.com> References: <20090202122025.ffa25a66.darcy@druid.net> <20090202.184442.104091625.sthaug@nethelp.no> <20090202125935.f351d377.darcy@druid.net> <20090202.190658.78766688.sthaug@nethelp.no> <34A84E68-02F1-46EB-A2F4-8C459C675C2C@gmail.com> Message-ID: --On m?ndag, m?ndag 2 feb 2009 16.15.06 -0200 Andre Sencioles Vitorio Oliveira wrote: > What about this? > > Genius from company A chooses public IP block A. > Genius from company B chooses public IP block A. > > Genius collision detected... What you do is go to your LIR and ask for a /24 and tell them "I am going to use this for which is at best semi-internal". It has worked for me; I got a PI /24 for the facility management system in a datacenter. (MODBUS over IP stuff, windows machines and embedded boxes sending email alarms about burning UPSes and sauna-hot computer rooms) My colleagues argued that "this network won't ever be connected to anything" but it took all of one week before they were proved wrong and the first contractor VPN box was installed. QED. The really, really, nice thing with registered PI or PA space is that it is pretty unique, bar fatfingering and route hijacking. Once there is a merger, the company with a RIPE db entry for the nonrouted space will have a most convincing position in merger negotiations: "This is our space: _you_ will renumber." Burning v4 space is good. Gets us v6 faster. -- M?ns Nilsson M A C H I N A HUGH BEAUMONT died in 1982!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From bygg at cafax.se Mon Feb 2 23:17:23 2009 From: bygg at cafax.se (Johnny Eriksson) Date: Mon, 2 Feb 2009 23:17:23 WET Subject: Private use of non-RFC1918 IP space In-Reply-To: Your message of Mon, 02 Feb 2009 22:14:38 +0100 Message-ID: Michael Hallgren : > > Really really LARGE scalability testing that needs more addresses than > > RFC1918 gives you. > > Use IPv6. For an IPv4 scalability test? Interesting idea... Apart from the basic incompability here, my opinion of IPv6 is that it just gives you 2^96 more addresses to repeat all the old mistakes with. --Johnny From sethm at rollernet.us Mon Feb 2 16:24:20 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 02 Feb 2009 14:24:20 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: <49875771.3060202@sprunk.org> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49875771.3060202@sprunk.org> Message-ID: <49877294.7050804@rollernet.us> Stephen Sprunk wrote: > Trey Darley wrote: >> Some colleagues and I are running into a bit of a problem. We've been >> using RFC 1918 Class A space but due to the way subnets have been >> allocated we are pondering the use of public IP space. As the network >> in question is strictly closed I don't anticipate any problems with >> this as the addresses would be unambiguous within our environment. I'm >> curious if anyone else is doing this. >> > > "Closed" networks nearly always end up getting connected to public > networks, either by intent or by accident. If you act as if your > network will remain "closed" forever, e.g. by using public addresses > that are (or will be) assigned to someone else, you're going to cause a > lot of headaches for yourself or your replacement down the road, > eventually. > > Contrary to popular belief, ARIN (and possibly other RIRs) _will_ assign > public IPs for private/closed networks if you can explain why RFC1918 > space will not suffice for your needs, e.g. because you are running a > private internetwork between multiple companies and thus NAT/RFC1918 is > simply not viable due to the number of ASes and the difficulty in > avoiding collisions or the sheer number of hosts... > Or you can always get some PA space from an ISP rather easily. ~Seth From pstewart at nexicomgroup.net Mon Feb 2 16:27:11 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 2 Feb 2009 17:27:11 -0500 Subject: Peer Filtering Message-ID: <89D27DE3375BB6428DDCC2927489826A01F802C9@nexus.nexicomgroup.net> Hi folks... I would like to know whether folks are limiting their peering sessions (BGP peering at public exchanges) only by max-prefix typically? Are we the only folks trying to filter all peers using IRR information? We've run across several peers now with 10,000+ prefixes who do not register barely half their prefixes in an IRR ... meaning that we deny the rest by default. I like to think that filtering on IRR is much better (not perfect by any means) as a practice but it's probably more *practical* to just limit max-prefix peers? We can't force our peers to register at a IRR and the only party that pays the price is us in that sense.. Am I thinking right on this? ;) Cheers, Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From Valdis.Kletnieks at vt.edu Mon Feb 2 16:30:10 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 02 Feb 2009 17:30:10 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Mon, 02 Feb 2009 23:17:23 GMT." References: Message-ID: <37237.1233613810@turing-police.cc.vt.edu> On Mon, 02 Feb 2009 23:17:23 GMT, Johnny Eriksson said: > Michael Hallgren : > > > > Really really LARGE scalability testing that needs more addresses than > > > RFC1918 gives you. > > > > Use IPv6. > > For an IPv4 scalability test? Interesting idea... Might wanna consider that if you're doing a scalability *test* that burns over a /8 of IPv4, how do you intend to *deploy* the sucker? Gonna be a bear trying to get a /8 or 3 allocated when The Final Days are upon us already... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From m.hallgren at free.fr Mon Feb 2 16:50:38 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 02 Feb 2009 23:50:38 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: <1233615038.28383.51.camel@home> Le lundi 02 f?vrier 2009 ? 23:17 +0000, Johnny Eriksson a ?crit : > Michael Hallgren : > > > > Really really LARGE scalability testing that needs more addresses than > > > RFC1918 gives you. > > > > Use IPv6. > > For an IPv4 scalability test? Interesting idea... Plaisanterie of sorts... But off "plaisanterie," I ref. the statement above. > > Apart from the basic incompability here, my opinion of IPv6 is that it > just gives you 2^96 more addresses to repeat all the old mistakes with. > Some mistakes, sure; not all. Keep the multihoming game in mind, for instance. Sure is that misuse is much possible also in the IPv6 space! Cheers, mh > --Johnny > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From marty at supine.com Mon Feb 2 19:34:11 2009 From: marty at supine.com (Martin Barry) Date: Tue, 3 Feb 2009 12:34:11 +1100 Subject: Peer Filtering In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01F802C9@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01F802C9@nexus.nexicomgroup.net> Message-ID: <20090203013411.GA10322@supine.com> $quoted_author = "Paul Stewart" ; > > I would like to know whether folks are limiting their peering sessions > (BGP peering at public exchanges) only by max-prefix typically? Are we > the only folks trying to filter all peers using IRR information? No, you're not the only ones. > We've run across several peers now with 10,000+ prefixes who do not > register barely half their prefixes in an IRR ... meaning that we deny > the rest by default. Most peering agreements I have read require either registration of routes in an appropriate place or notification to the other party of an appropriate filter for their routes and/or AS path. In Au we have multi-lateral peering exchanges and at least the one $work is on requires registration of routes with the exchange provider who generates the appropriate filters. cheers marty -- supine: From the Latin for "lying on one's back," to be supine has come to mean "inactive." But as Damien Hirst suggests with his maxim "Minimum effort for maximum effect," there's nothing wrong with being inactive. "An Idler's Glossary" - http://www.hermenaut.com/a158.shtml From mbarker at cyrusnetworks.com Mon Feb 2 19:42:26 2009 From: mbarker at cyrusnetworks.com (Michael Barker) Date: Mon, 2 Feb 2009 20:42:26 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> Message-ID: <99D09C7C026C2942AAE6F2E7EC01CDC91CB637980F@Server12.cmh.cyrusnetworks.com> It's not unheard of to see the government cyber squatting unallocated /8 blocks too. -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, February 02, 2009 3:49 PM To: sthaug at nethelp.no Cc: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space i am surprised that no one has mentioned that it is not unusual for folk, even isps, to use space assigned to the us military but never routed on the public internet. i was exceedingly amused when first i did a traceroute from bologna. randy From nanog at daork.net Mon Feb 2 20:01:50 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 3 Feb 2009 15:01:50 +1300 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: On 3/02/2009, at 12:17 PM, Johnny Eriksson wrote: > Michael Hallgren : > >>> Really really LARGE scalability testing that needs more addresses >>> than >>> RFC1918 gives you. >> >> Use IPv6. > > For an IPv4 scalability test? Interesting idea... > > Apart from the basic incompability here, my opinion of IPv6 is that it > just gives you 2^96 more addresses to repeat all the old mistakes > with. Not quite.. 2^96 = 79228162514264337593543950336 2^128-2^32 = 340282366920938463463374607427473244160 -- Nathan Ward From randy at psg.com Mon Feb 2 20:25:40 2009 From: randy at psg.com (Randy Bush) Date: Tue, 03 Feb 2009 11:25:40 +0900 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: >> Apart from the basic incompability here, my opinion of IPv6 is that it >> just gives you 2^96 more addresses to repeat all the old mistakes >> with. > Not quite.. > 2^96 = 79228162514264337593543950336 > 2^128-2^32 = 340282366920938463463374607427473244160 not quite. let's posit 42 devices on the average lan segment (ymmv). 42*(2^64) = 774763251095801167872 randy From Valdis.Kletnieks at vt.edu Mon Feb 2 21:24:03 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 02 Feb 2009 22:24:03 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Tue, 03 Feb 2009 11:25:40 +0900." References: Message-ID: <49555.1233631443@turing-police.cc.vt.edu> On Tue, 03 Feb 2009 11:25:40 +0900, Randy Bush said: > >> Apart from the basic incompability here, my opinion of IPv6 is that it > >> just gives you 2^96 more addresses to repeat all the old mistakes > >> with. > > Not quite.. > > 2^96 = 79228162514264337593543950336 > > 2^128-2^32 = 340282366920938463463374607427473244160 > > not quite. let's posit 42 devices on the average lan segment > (ymmv). > > 42*(2^64) = 774763251095801167872 Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon. Of course, I've long suspected that the 90% of the universe that's "dark matter" is all contained inside the craniums of all those chucklehead consultants (which is why they're so resistant to interactions with cluons from the rest of reality), so there's unfortunately a definite growth potential there... Anybody feel like starting a pool for when we'll see a posting to NANOG about somebody who's managed to burn through a /32? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From marty at supine.com Mon Feb 2 21:22:21 2009 From: marty at supine.com (Martin Barry) Date: Tue, 3 Feb 2009 14:22:21 +1100 Subject: Peer Filtering In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01F802C9@nexus.nexicomgroup.net> <20090203013411.GA10322@supine.com> Message-ID: <20090203032221.GB10322@supine.com> $quoted_author = "John van Oppen" ; > > Here in the US we don't bother, max-prefix covers it... It seems that > US originated prefixes are rather sporadically entered into the routing > DBs. ...and you are not worried about someone leaking a subset of routes? I understand that most failure cases would trigger a max-prefix but a typo could allow just enough leakage to not hit max-prefix and yet still make something "important" unreachable. cheers marty -- with usenet gone, we just don't teach our kids entertainment-level hyperbole any more. --Paul Vixie http://www.merit.edu/mail.archives/nanog/2006-01/msg00593.html From john at vanoppen.com Mon Feb 2 21:54:20 2009 From: john at vanoppen.com (John van Oppen) Date: Mon, 2 Feb 2009 19:54:20 -0800 Subject: Peer Filtering References: <89D27DE3375BB6428DDCC2927489826A01F802C9@nexus.nexicomgroup.net><20090203013411.GA10322@supine.com> <20090203032221.GB10322@supine.com> Message-ID: Yep agreed... We balance that by keeping the max-prefix no more than about 40% over the current prefix limit on each peer. For us it is a trade-off, accept the routes or don't send the traffic to peering. The couple of times I have seen route leaks that involved one or two routes they were paths that worked, they were just wrong and we ended up just throwing a prefix-list on that peer. The thing is, one basically has to trust one's transit providers which don't always filter well. Given this trusting one's peers at least some-what does not seem too out there. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Martin Barry [mailto:marty at supine.com] Sent: Monday, February 02, 2009 7:22 PM To: nanog at nanog.org Subject: Re: Peer Filtering $quoted_author = "John van Oppen" ; > > Here in the US we don't bother, max-prefix covers it... It seems that > US originated prefixes are rather sporadically entered into the routing > DBs. ...and you are not worried about someone leaking a subset of routes? I understand that most failure cases would trigger a max-prefix but a typo could allow just enough leakage to not hit max-prefix and yet still make something "important" unreachable. cheers marty -- with usenet gone, we just don't teach our kids entertainment-level hyperbole any more. --Paul Vixie http://www.merit.edu/mail.archives/nanog/2006-01/msg00593.html From nanog at arbitraryconstant.com Mon Feb 2 23:30:00 2009 From: nanog at arbitraryconstant.com (Anthony Roberts) Date: Mon, 02 Feb 2009 22:30:00 -0700 Subject: Private use of non-RFC1918 IP space In-Reply-To: <49555.1233631443@turing-police.cc.vt.edu> References: <49555.1233631443@turing-police.cc.vt.edu> Message-ID: > Let's face it - they're going to have to come up with much more creative > $200/hour chucklehead consultants to burn through that much anytime soon. It has been my experience that when you give someone a huge address space to play with (eg 10/8), they start doing things like using bits in the address as flags for things. Suddenly you find yourself using a prefix that should enough for a decent sized country in a half-rack. It's only slightly harder to imagine a /48 being wasted like that. -Anthony From patrick at ianai.net Mon Feb 2 23:35:15 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 3 Feb 2009 00:35:15 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> Message-ID: On Feb 3, 2009, at 12:30 AM, Anthony Roberts wrote: >> Let's face it - they're going to have to come up with much more >> creative >> $200/hour chucklehead consultants to burn through that much anytime >> soon. > > It has been my experience that when you give someone a huge address > space > to play with (eg 10/8), they start doing things like using bits in the > address as flags for things. Suddenly you find yourself using a prefix > that should enough for a decent sized country in a half-rack. > > It's only slightly harder to imagine a /48 being wasted like that. Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. -- TTFN, patrick From Mark_Andrews at isc.org Mon Feb 2 23:39:26 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue, 03 Feb 2009 16:39:26 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Tue, 03 Feb 2009 00:35:15 CDT." Message-ID: <200902030539.n135dQu9032856@drugs.dv.isc.org> In message , "Patrick W. Gilmor e" writes: > On Feb 3, 2009, at 12:30 AM, Anthony Roberts wrote: > > >> Let's face it - they're going to have to come up with much more > >> creative > >> $200/hour chucklehead consultants to burn through that much anytime > >> soon. > > > > It has been my experience that when you give someone a huge address > > space > > to play with (eg 10/8), they start doing things like using bits in the > > address as flags for things. Suddenly you find yourself using a prefix > > that should enough for a decent sized country in a half-rack. > > > > It's only slightly harder to imagine a /48 being wasted like that. > > Except the RIRs won't give you another /48 when you have only used one > trillion IP addresses. > > -- > TTFN, > patrick But they will when you will exceeded 65536 networks. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From stephen at sprunk.org Tue Feb 3 00:01:09 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 03 Feb 2009 00:01:09 -0600 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> Message-ID: <4987DDA5.3060109@sprunk.org> Patrick W. Gilmore wrote: > Except the RIRs won't give you another /48 when you have only used one > trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From nonobvious at gmail.com Tue Feb 3 04:11:00 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Tue, 3 Feb 2009 02:11:00 -0800 Subject: can I ask mtu question In-Reply-To: References: <761682.59176.qm@web33301.mail.mud.yahoo.com> <20090130220000.GA10014@mx.ytti.net> Message-ID: <18a5e7cb0902030211g592a49a6gea36be48e5b75421@mail.gmail.com> >> Which standard are you referring to? AFAIK, nothing above 1500 is >> standardised I've had two different kinds of customer requests for jumbo frames - customers that want very large frames for performance reasons; Many ethernet switches support 9000 or more, some don't, and some technologies like ATM support ~4470. Sometimes the ability to provide them depends on tunnel modes. - customers that want frames that are at least ~1700-1800 bytes so that a few layers of IPSEC or VLAN headers or whatever won't break the 1500-byte packets inside them. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From pstewart at nexicomgroup.net Tue Feb 3 05:12:20 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 3 Feb 2009 06:12:20 -0500 Subject: Peer Filtering In-Reply-To: <20090203032221.GB10322@supine.com> References: <89D27DE3375BB6428DDCC2927489826A01F802C9@nexus.nexicomgroup.net><20090203013411.GA10322@supine.com> <20090203032221.GB10322@supine.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01F80304@nexus.nexicomgroup.net> That was one of our biggest worries.... people make mistakes and route leaks happen..... The unfortunate part we're faced with now is that we have several downstream customers who are multihomed. Because we're filtering out some of the prefixes that are not in an IRR, those routes are not nearly as attractive downstream giving the other carrier involved an advantage..... I can see this is where convenience/economics start to kick in ;( Appreciate all the replies on-list and off-list - it seems there is about 80/20 split on people doing prefix-list vs IRR filtering.... Paul -----Original Message----- From: Martin Barry [mailto:marty at supine.com] Sent: February 2, 2009 10:22 PM To: nanog at nanog.org Subject: Re: Peer Filtering $quoted_author = "John van Oppen" ; > > Here in the US we don't bother, max-prefix covers it... It seems that > US originated prefixes are rather sporadically entered into the routing > DBs. ...and you are not worried about someone leaking a subset of routes? I understand that most failure cases would trigger a max-prefix but a typo could allow just enough leakage to not hit max-prefix and yet still make something "important" unreachable. cheers marty -- with usenet gone, we just don't teach our kids entertainment-level hyperbole any more. --Paul Vixie http://www.merit.edu/mail.archives/nanog/2006-01/msg00593.html ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From sam_mailinglists at spacething.org Tue Feb 3 06:04:22 2009 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Tue, 03 Feb 2009 12:04:22 +0000 Subject: can I ask mtu question In-Reply-To: References: <761682.59176.qm@web33301.mail.mud.yahoo.com> <20090130220000.GA10014@mx.ytti.net> Message-ID: <498832C6.2070506@spacething.org> Ricky Beam wrote: > On Fri, 30 Jan 2009 17:00:00 -0500, Saku Ytti wrote: >> Which standard are you referring to? AFAIK, nothing above 1500 is >> standardised > > None that have ever been accepted. From a quick google for > manufacturer support, 9216 looks like the most popular number. But, > as I said, it boils down to the largest frame *every* device on the > LAN will accept. If there is a single device that only supports > "9000", then that's your limit. And if there's a single non-JF device > in the LAN, it throws a wrench into the whole thing. (This appears to > be one of the sticking points as to why IEEE won't accept the addition > of JF to any specs.) > > --Ricky > > PS: The topic pops up again with super-jumbo frames in 10G networks. > For what it's worth, TCP will negiogate MSS and will work with mismatched MTU in a single LAN segment. Other protocols (e.g. UDP) will be borked though. S From nick at foobar.org Tue Feb 3 06:11:44 2009 From: nick at foobar.org (Nick Hilliard) Date: Tue, 03 Feb 2009 12:11:44 +0000 Subject: Peer Filtering In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01F80304@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01F802C9@nexus.nexicomgroup.net><20090203013411.GA10322@supine.com> <20090203032221.GB10322@supine.com> <89D27DE3375BB6428DDCC2927489826A01F80304@nexus.nexicomgroup.net> Message-ID: <49883480.9060408@foobar.org> > That was one of our biggest worries.... people make mistakes and route > leaks happen..... They do. And it's not just mom+pop providers who occasionally leak an entire table. Big operators do it too. > The unfortunate part we're faced with now is that we have several > downstream customers who are multihomed. Because we're filtering out > some of the prefixes that are not in an IRR, those routes are not nearly > as attractive downstream giving the other carrier involved an > advantage..... I can see this is where convenience/economics start to > kick in ;( One way or another, if you're providing transit, you absolutely need some means of filtering your downstreams using prefix filtering, and also preferable ASN filtering. Otherwise, your downstreams can inject any sort of crap into your table and you're opening yourself up to I-can't-believe-it's-not-youtube-hijacking-again situations. This is really bad and harmful for the internet. Max-prefixes are fine for peering exchanges, where you can just depeer if there's a problem, but they will not protect you against customers doing stupid stuff. The only issue for customers is not whether you do prefix filtering but whether you use IRR information or maintain your own internal database. The latter is re-inventing the wheel, imo. But lots of companies do it anyway. If your peering exchange doesn't provide multilateral peering, ask them to do so. This provides a natural platform for using route server client IRR prefix filtering, and route servers (despite a lot of well known and understood problems associated with them) can be very useful in this regard. Nick From patrick at ianai.net Tue Feb 3 06:50:56 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 3 Feb 2009 07:50:56 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <200902030539.n135dQu9032856@drugs.dv.isc.org> References: <200902030539.n135dQu9032856@drugs.dv.isc.org> Message-ID: On Feb 3, 2009, at 12:39 AM, Mark Andrews wrote: > In message , > "Patrick W. Gilmor > e" writes: >> On Feb 3, 2009, at 12:30 AM, Anthony Roberts wrote: >> >>>> Let's face it - they're going to have to come up with much more >>>> creative >>>> $200/hour chucklehead consultants to burn through that much anytime >>>> soon. >>> >>> It has been my experience that when you give someone a huge address >>> space >>> to play with (eg 10/8), they start doing things like using bits in >>> the >>> address as flags for things. Suddenly you find yourself using a >>> prefix >>> that should enough for a decent sized country in a half-rack. >>> >>> It's only slightly harder to imagine a /48 being wasted like that. >> >> Except the RIRs won't give you another /48 when you have only used >> one >> trillion IP addresses. >> >> -- >> TTFN, >> patrick > > But they will when you will exceeded 65536 networks. Which is exactly what they should do - actually before that one would hope. This is not the "$200/hour chcklehead consultant"'s fault, that is the design. Don't you love the idea of using 18446744073709551616 IP addresses to number a point-to-point link? -- TTFN, patrick From patrick at ianai.net Tue Feb 3 06:52:04 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 3 Feb 2009 07:52:04 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <4987DDA5.3060109@sprunk.org> References: <49555.1233631443@turing-police.cc.vt.edu> <4987DDA5.3060109@sprunk.org> Message-ID: On Feb 3, 2009, at 1:01 AM, Stephen Sprunk wrote: > Patrick W. Gilmore wrote: >> Except the RIRs won't give you another /48 when you have only used >> one trillion IP addresses. > > Are you sure? According to ARIN staff, current implementation of > policy is that all requests are approved since there are no defined > criteria that would allow them to deny any. So far, nobody's shown > interest in plugging that hole in the policy because it'd be a major > step forward if IPv6 were popular enough for anyone to bother > wasting it... Touch?. I assumed if you had an allocation and came back for a second, they would say no. Hrmm, time for me to go get another (or another 1000?) v6 allocations. :) -- TTFN, patrick From trey at kingfisherops.com Tue Feb 3 06:56:21 2009 From: trey at kingfisherops.com (Trey Darley) Date: Tue, 3 Feb 2009 13:56:21 +0100 (CET) Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <4987DDA5.3060109@sprunk.org> Message-ID: <45064.192.101.252.156.1233665781.squirrel@kingfisherops.com> Thanks all for the input. Cheers, --Trey ++----------------------------------------------------------------------------++ Kingfisher Operations Trey Darley - Principal From niels=nanog at bakker.net Tue Feb 3 10:09:42 2009 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 3 Feb 2009 17:09:42 +0100 Subject: can I ask mtu question In-Reply-To: <498832C6.2070506@spacething.org> References: <761682.59176.qm@web33301.mail.mud.yahoo.com> <20090130220000.GA10014@mx.ytti.net> <498832C6.2070506@spacething.org> Message-ID: <20090203160942.GP56621@burnout.tpb.net> * sam_mailinglists at spacething.org (Sam Stickland) [Tue 03 Feb 2009, 13:04 CET]: >For what it's worth, TCP will negiogate MSS and will work with >mismatched MTU in a single LAN segment. No Machine 1 -- switch with 1500 byte MTU -- switch with smaller MTU -- switch with 1500 byte MTU -- machine 2 Same situation as when you have IP routers with smaller MTUs in the path that also do not send ICMP Fragmentation Needed errors (or those are dropped on the way to you) If you configure one of those machines with an MTU equal to or smaller than the smallest MTU in the path then yes TCP (assuming MSS option is used) won't send packets that happen to be too big, but again, same story as for routers vs on a LAN. The problem isn't that machine 1 and 2 in the above example disagree on MTU, the problem is that equipment in the path disagrees on the MTU and cannot (in the case of switches) send notifications of such, or those will not arrive (in the case of stupid firewall admins in control of networks). -- Niels. From sam_mailinglists at spacething.org Tue Feb 3 10:42:19 2009 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Tue, 03 Feb 2009 16:42:19 +0000 Subject: can I ask mtu question In-Reply-To: <20090203160942.GP56621@burnout.tpb.net> References: <761682.59176.qm@web33301.mail.mud.yahoo.com> <20090130220000.GA10014@mx.ytti.net> <498832C6.2070506@spacething.org> <20090203160942.GP56621@burnout.tpb.net> Message-ID: <498873EB.8090306@spacething.org> Niels Bakker wrote: > * sam_mailinglists at spacething.org (Sam Stickland) [Tue 03 Feb 2009, > 13:04 CET]: >> For what it's worth, TCP will negiogate MSS and will work with >> mismatched MTU in a single LAN segment. > > No > > Machine 1 -- switch with 1500 byte MTU -- switch with smaller MTU -- > switch with 1500 byte MTU -- machine 2 > > Same situation as when you have IP routers with smaller MTUs in the > path that also do not send ICMP Fragmentation Needed errors (or those > are dropped on the way to you) > > If you configure one of those machines with an MTU equal to or smaller > than the smallest MTU in the path then yes TCP (assuming MSS option is > used) won't send packets that happen to be too big, but again, same > story as for routers vs on a LAN. The problem isn't that machine 1 > and 2 in the above example disagree on MTU, the problem is that > equipment in the path disagrees on the MTU and cannot (in the case of > switches) send notifications of such, or those will not arrive (in the > case of stupid firewall admins in control of networks). Sorry, I should had clarified. I meant mismatched host MTUs within a jumbo MTU supporting L2 domain. Sam From marquis at roble.com Tue Feb 3 11:39:33 2009 From: marquis at roble.com (Roger Marquis) Date: Tue, 3 Feb 2009 09:39:33 -0800 (PST) Subject: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: <20090203173933.335ED2B21C3@mx5.roble.com> Stephen Sprunk wrote: > Patrick W. Gilmore wrote: >> Except the RIRs won't give you another /48 when you have only used one >> trillion IP addresses. > > Are you sure? According to ARIN staff, current implementation of policy > is that all requests are approved since there are no defined criteria > that would allow them to deny any. So far, nobody's shown interest in > plugging that hole in the policy because it'd be a major step forward if > IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis From zaid at zaidali.com Tue Feb 3 12:19:26 2009 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 3 Feb 2009 10:19:26 -0800 (PST) Subject: Private use of non-RFC1918 IP space In-Reply-To: <16474135.451233684880488.JavaMail.zaid@turing-2.local> Message-ID: <10812089.471233685164238.JavaMail.zaid@turing-2.local> I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. >From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid ----- Original Message ----- From: "Roger Marquis" To: nanog at nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: > Patrick W. Gilmore wrote: >> Except the RIRs won't give you another /48 when you have only used one >> trillion IP addresses. > > Are you sure? According to ARIN staff, current implementation of policy > is that all requests are approved since there are no defined criteria > that would allow them to deny any. So far, nobody's shown interest in > plugging that hole in the policy because it'd be a major step forward if > IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis From paul at telcodata.us Tue Feb 3 12:22:16 2009 From: paul at telcodata.us (Paul Timmins) Date: Tue, 03 Feb 2009 13:22:16 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <10812089.471233685164238.JavaMail.zaid@turing-2.local> References: <10812089.471233685164238.JavaMail.zaid@turing-2.local> Message-ID: <49888B58.5060008@telcodata.us> Zaid Ali wrote: > I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like > > 1. How do we migrate to a IPv6 stack on all servers and I am talking about the > thousands of servers that exist on peoples network that run SaaS, > Financial/Banking systems. > Just upgrade your load balancer (or request a feature from your load balancer company) to map an external IPv6 address to a pool of IPv4 servers. Problem solved. > 2. How do we make old applications speak IPv6? There are some old back-end systems > that run core functions for many businesses out there that don't really have any > upgrade path and I don't think people are thinking about this. > Continue to run IPv4 internally for this application. There's no logical reason that IPv4 can't continue to coexist for decades. Heck, people still run IPX, right? -Paul From mhuff at ox.com Tue Feb 3 12:24:59 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 3 Feb 2009 13:24:59 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <10812089.471233685164238.JavaMail.zaid@turing-2.local> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> Message-ID: <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, we will look at deploying ipv6, but not until then. That's not a technical issue, but rather a business decision, and it's not going to change. We aren't depending our network resources on an external third-party, especially given their track record. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 > -----Original Message----- > From: Zaid Ali [mailto:zaid at zaidali.com] > Sent: Tuesday, February 03, 2009 1:19 PM > To: Roger Marquis > Cc: nanog at nanog.org > Subject: Re: Private use of non-RFC1918 IP space > > I don't consider IPv6 a popularity contest. It's about the motivation > and the willingness to. Technical issues can be resolved if you and > people around you are motivated to do so. I think there are some hard > facts that need to be addressed when it comes to IPv6. Facts like > > 1. How do we migrate to a IPv6 stack on all servers and I am talking > about the > thousands of servers that exist on peoples network that run SaaS, > Financial/Banking systems. > > 2. How do we make old applications speak IPv6? There are some old back- > end systems > that run core functions for many businesses out there that don't > really have any > upgrade path and I don't think people are thinking about this. > > >From a network perspective IPv6 adoption is just about doing it and > executing with your fellow AS neighbors. The elephant in the room is > the applications that ride on your network. > > Zaid > > ----- Original Message ----- > From: "Roger Marquis" > To: nanog at nanog.org > Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific > Subject: Re: Private use of non-RFC1918 IP space > > Stephen Sprunk wrote: > > Patrick W. Gilmore wrote: > >> Except the RIRs won't give you another /48 when you have only used > one > >> trillion IP addresses. > > > > Are you sure? According to ARIN staff, current implementation of > policy > > is that all requests are approved since there are no defined criteria > > that would allow them to deny any. So far, nobody's shown interest > in > > plugging that hole in the policy because it'd be a major step forward > if > > IPv6 were popular enough for anyone to bother wasting it... > > Catch 22? From my experience IPv6 is unlikely to become popular until > it > fully supports NAT. > > Much as network providers love the thought of owning all of your > address > space, and ARIN of billing for it, and RFCs like 4864 of providing > rhetorical but technically flawed arguments against it, the lack of NAT > only pushes adoption of IPv6 further into the future. > > Roger Marquis > -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From zaid at zaidali.com Tue Feb 3 12:32:48 2009 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 3 Feb 2009 10:32:48 -0800 (PST) Subject: Private use of non-RFC1918 IP space In-Reply-To: <49888B58.5060008@telcodata.us> Message-ID: <3765056.511233685963941.JavaMail.zaid@turing-2.local> Yes we all go to NANOG meetings and talk about these solutions but the change has to come from within. its not just a technical solution. There has to be motivation and incentive for people to make this change. Zaid ----- Original Message ----- From: "Paul Timmins" To: "Zaid Ali" Cc: "Roger Marquis" , nanog at nanog.org Sent: Tuesday, February 3, 2009 10:22:16 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Zaid Ali wrote: > I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like > > 1. How do we migrate to a IPv6 stack on all servers and I am talking about the > thousands of servers that exist on peoples network that run SaaS, > Financial/Banking systems. > Just upgrade your load balancer (or request a feature from your load balancer company) to map an external IPv6 address to a pool of IPv4 servers. Problem solved. > 2. How do we make old applications speak IPv6? There are some old back-end systems > that run core functions for many businesses out there that don't really have any > upgrade path and I don't think people are thinking about this. > Continue to run IPv4 internally for this application. There's no logical reason that IPv4 can't continue to coexist for decades. Heck, people still run IPX, right? -Paul From jeroen at unfix.org Tue Feb 3 14:50:42 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 03 Feb 2009 21:50:42 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> Message-ID: <4988AE22.9070403@spaghetti.zurich.ibm.com> Matthew Huff wrote: > It's not just technical. Companies are reluctant to migrate to an IP address > owned by an ISP. We are one of those companies. If and when it is easy for us > to apply and receive our own Ipv6 address space, [..] Because like, ARIN wasn't the first RIR to provide that possibility. http://www.arin.net/registration/guidelines/ipv6_assignment.html I assume you will have IPv6 next week now? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mansaxel at besserwisser.org Tue Feb 3 15:18:42 2009 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Tue, 03 Feb 2009 22:18:42 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> Message-ID: <4EE6E2C5EFEAACBD60261526@rasmus.kthnoc.net> --On tisdag, tisdag 3 feb 2009 13.24.59 -0500 Matthew Huff wrote: > It's not just technical. Companies are reluctant to migrate to an IP > address owned by an ISP. We are one of those companies. If and when it > is easy for us to apply and receive our own Ipv6 address space, we will > look at deploying ipv6, but not until then. That's not a technical > issue, but rather a business decision, and it's not going to change. We > aren't depending our network resources on an external third-party, > especially given their track record. Renumbering will happen. Be prepared or cry louder when it happens. DNS was invented for this, and v4 PA space is functionally equivalent to v6 here. Getting PI space only pushes the inevitable a bit, while lessening the incentives to DTRT wrt IP address mobility. -- M?ns Nilsson M A C H I N A YOW!!! I am having fun!!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From mhuff at ox.com Tue Feb 3 15:35:06 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 3 Feb 2009 16:35:06 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <4EE6E2C5EFEAACBD60261526@rasmus.kthnoc.net> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> <4EE6E2C5EFEAACBD60261526@rasmus.kthnoc.net> Message-ID: <483E6B0272B0284BA86D7596C40D29F984E82B67D6@PUR-EXCH07.ox.com> DNS is great, but there is plenty of stuff to change that doesn't use DNS (ACLS, etc...). The point is, why should we go through the pain of renumbering, and have to do it everytime our relationship with our ISP changes? We aren't going to go there. It isn't renumbering that's the problem, the problem is that it being tied to an external company. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 > -----Original Message----- > From: M?ns Nilsson [mailto:mansaxel at besserwisser.org] > Sent: Tuesday, February 03, 2009 4:19 PM > To: Matthew Huff; 'Zaid Ali'; 'Roger Marquis' > Cc: 'nanog at nanog.org' > Subject: RE: Private use of non-RFC1918 IP space > > --On tisdag, tisdag 3 feb 2009 13.24.59 -0500 Matthew Huff > > wrote: > > > It's not just technical. Companies are reluctant to migrate to an IP > > address owned by an ISP. We are one of those companies. If and when > it > > is easy for us to apply and receive our own Ipv6 address space, we > will > > look at deploying ipv6, but not until then. That's not a technical > > issue, but rather a business decision, and it's not going to change. > We > > aren't depending our network resources on an external third-party, > > especially given their track record. > > Renumbering will happen. Be prepared or cry louder when it happens. DNS > was > invented for this, and v4 PA space is functionally equivalent to v6 > here. > > Getting PI space only pushes the inevitable a bit, while lessening the > incentives to DTRT wrt IP address mobility. > > -- > M?ns Nilsson M A C H I N A > > YOW!!! I am having fun!!! -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From skeeve at skeeve.org Tue Feb 3 15:59:15 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 08:59:15 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090203173933.335ED2B21C3@mx5.roble.com> References: <20090203173933.335ED2B21C3@mx5.roble.com> Message-ID: It isn't ipv6 that needs to support NAT, it is the devices doing dual-stack. This is where NAT-PT (v6-v4 NAT) will come in. My opinion is that we only aren't further along because the hardware vendors are slackers, mostly the low end guys like D-Link, Belkin, Netgear and so on who provide most of the home networking equipment. The big boys have supported v6 NAT and NAT-PT for ages. ...Skeeve -----Original Message----- From: Roger Marquis [mailto:marquis at roble.com] Sent: Wednesday, 4 February 2009 4:40 AM To: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: > Patrick W. Gilmore wrote: >> Except the RIRs won't give you another /48 when you have only used one >> trillion IP addresses. > > Are you sure? According to ARIN staff, current implementation of policy > is that all requests are approved since there are no defined criteria > that would allow them to deny any. So far, nobody's shown interest in > plugging that hole in the policy because it'd be a major step forward if > IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis From skeeve at skeeve.org Tue Feb 3 16:03:06 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 09:03:06 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <10812089.471233685164238.JavaMail.zaid@turing-2.local> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> Message-ID: With new dual-stack border devices people will be able to move bit by bit, and there is no real reason to have to run around and change everything that you have internally. These will change and update over time. These internal applications aren't running on public IP addresses anyway. ...Skeeve -----Original Message----- From: Zaid Ali [mailto:zaid at zaidali.com] Sent: Wednesday, 4 February 2009 5:19 AM To: Roger Marquis Cc: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. >From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid ----- Original Message ----- From: "Roger Marquis" To: nanog at nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: > Patrick W. Gilmore wrote: >> Except the RIRs won't give you another /48 when you have only used one >> trillion IP addresses. > > Are you sure? According to ARIN staff, current implementation of policy > is that all requests are approved since there are no defined criteria > that would allow them to deny any. So far, nobody's shown interest in > plugging that hole in the policy because it'd be a major step forward if > IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis From davet1 at gmail.com Tue Feb 3 16:05:46 2009 From: davet1 at gmail.com (Dave Temkin) Date: Tue, 03 Feb 2009 14:05:46 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> Message-ID: <4988BFBA.4050007@gmail.com> The problem with that solution mainly being that the application itself still needs some sort of intelligence as well as the border device potentially doing L7 operations (header insertion/etc.) - unless you're OK with generally losing all information about the source of incoming traffic at the backend (except for looking at NAT tables...) -Dave Skeeve Stevens wrote: With new dual-stack border devices people will be able to move bit by bit, and t here is no real reason to have to run around and change everything that you have internally. These will change and update over time. These internal applicatio ns aren't running on public IP addresses anyway. ...Skeeve -----Original Message----- From: Zaid Ali [[1]mailto:zaid at zaidali.com] Sent: Wednesday, 4 February 2009 5:19 AM To: Roger Marquis Cc: [2]nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the wi llingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end syste ms that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. >From a network perspective IPv6 adoption is just about doing it and executing w ith your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid ----- Original Message ----- From: "Roger Marquis" [3] To: [4]nanog at nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis References 1. mailto:zaid at zaidali.com 2. mailto:nanog at nanog.org 3. mailto:marquis at roble.com 4. mailto:nanog at nanog.org From skeeve at skeeve.org Tue Feb 3 16:18:40 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 09:18:40 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> Message-ID: Owned by an ISP? It isn't much different than it is now. As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this. Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap. I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now. If I was going to build a v6 network right now, that was purely private and never* going to hit the internet, and I could not afford to be a NIC member or pay the fees... then I would be using the ranges above.... I wonder if that will start a flame war *puts on fire suit*. ...Skeeve * never say never! # http://www.iana.org/assignments/ipv6-unicast-address-assignments -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Wednesday, 4 February 2009 5:25 AM To: 'Zaid Ali'; 'Roger Marquis' Cc: 'nanog at nanog.org' Subject: RE: Private use of non-RFC1918 IP space It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, we will look at deploying ipv6, but not until then. That's not a technical issue, but rather a business decision, and it's not going to change. We aren't depending our network resources on an external third-party, especially given their track record. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 > -----Original Message----- > From: Zaid Ali [mailto:zaid at zaidali.com] > Sent: Tuesday, February 03, 2009 1:19 PM > To: Roger Marquis > Cc: nanog at nanog.org > Subject: Re: Private use of non-RFC1918 IP space > > I don't consider IPv6 a popularity contest. It's about the motivation > and the willingness to. Technical issues can be resolved if you and > people around you are motivated to do so. I think there are some hard > facts that need to be addressed when it comes to IPv6. Facts like > > 1. How do we migrate to a IPv6 stack on all servers and I am talking > about the > thousands of servers that exist on peoples network that run SaaS, > Financial/Banking systems. > > 2. How do we make old applications speak IPv6? There are some old back- > end systems > that run core functions for many businesses out there that don't > really have any > upgrade path and I don't think people are thinking about this. > > >From a network perspective IPv6 adoption is just about doing it and > executing with your fellow AS neighbors. The elephant in the room is > the applications that ride on your network. > > Zaid > > ----- Original Message ----- > From: "Roger Marquis" > To: nanog at nanog.org > Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific > Subject: Re: Private use of non-RFC1918 IP space > > Stephen Sprunk wrote: > > Patrick W. Gilmore wrote: > >> Except the RIRs won't give you another /48 when you have only used > one > >> trillion IP addresses. > > > > Are you sure? According to ARIN staff, current implementation of > policy > > is that all requests are approved since there are no defined criteria > > that would allow them to deny any. So far, nobody's shown interest > in > > plugging that hole in the policy because it'd be a major step forward > if > > IPv6 were popular enough for anyone to bother wasting it... > > Catch 22? From my experience IPv6 is unlikely to become popular until > it > fully supports NAT. > > Much as network providers love the thought of owning all of your > address > space, and ARIN of billing for it, and RFCs like 4864 of providing > rhetorical but technically flawed arguments against it, the lack of NAT > only pushes adoption of IPv6 further into the future. > > Roger Marquis > From skeeve at skeeve.org Tue Feb 3 16:19:58 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 09:19:58 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <483E6B0272B0284BA86D7596C40D29F984E82B67D6@PUR-EXCH07.ox.com> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> <4EE6E2C5EFEAACBD60261526@rasmus.kthnoc.net> <483E6B0272B0284BA86D7596C40D29F984E82B67D6@PUR-EXCH07.ox.com> Message-ID: See my other email. You don't need to use a providers range. ...Skeeve -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Wednesday, 4 February 2009 8:35 AM To: 'M?ns Nilsson'; 'Zaid Ali'; 'Roger Marquis' Cc: 'nanog at nanog.org' Subject: RE: Private use of non-RFC1918 IP space DNS is great, but there is plenty of stuff to change that doesn't use DNS (ACLS, etc...). The point is, why should we go through the pain of renumbering, and have to do it everytime our relationship with our ISP changes? We aren't going to go there. It isn't renumbering that's the problem, the problem is that it being tied to an external company. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 > -----Original Message----- > From: M?ns Nilsson [mailto:mansaxel at besserwisser.org] > Sent: Tuesday, February 03, 2009 4:19 PM > To: Matthew Huff; 'Zaid Ali'; 'Roger Marquis' > Cc: 'nanog at nanog.org' > Subject: RE: Private use of non-RFC1918 IP space > > --On tisdag, tisdag 3 feb 2009 13.24.59 -0500 Matthew Huff > > wrote: > > > It's not just technical. Companies are reluctant to migrate to an IP > > address owned by an ISP. We are one of those companies. If and when > it > > is easy for us to apply and receive our own Ipv6 address space, we > will > > look at deploying ipv6, but not until then. That's not a technical > > issue, but rather a business decision, and it's not going to change. > We > > aren't depending our network resources on an external third-party, > > especially given their track record. > > Renumbering will happen. Be prepared or cry louder when it happens. DNS > was > invented for this, and v4 PA space is functionally equivalent to v6 > here. > > Getting PI space only pushes the inevitable a bit, while lessening the > incentives to DTRT wrt IP address mobility. > > -- > M?ns Nilsson M A C H I N A > > YOW!!! I am having fun!!! From skeeve at skeeve.org Tue Feb 3 16:28:29 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 09:28:29 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <4988BFBA.4050007@gmail.com> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <4988BFBA.4050007@gmail.com> Message-ID: And for those kinds of applications, yell at your vendors to come up with a solution. They say that there is about 2 years of ipv4 left. Then we?re screwed. If people sit with their thumbs up their asses now, and are not out planning budgets and migration strategies, they will be caught when they want to do network expansions. Note? the running out of IPv4 will NOT effect your current operations in any way. Your providers transit will (or already has) become dual stack, and you will continue to be able to talk to the internet as a whole unless native v6 only content starts to appear, which it will and then problems will appear. This situation will be able to go on for years without your changing anything?.. unless you want these applications to keep communicating with the ever growing internet on ipv6? and if you do, plan for it? decide if you?re going to do it now, in a year, or in 10 years and how you want to look to your shareholders or stakeholders? because eventually, they will ask? they may not want to pay for it just now? but there is a lot of things you can do before you have to start paying real money for things. - Getting your assignment/allocation - Developing your documentation/plan of how it will be assigned internally - Start to identify what parts of your infrastructure will not cope (everyone will need to use NAT-PT internally for some 10 years or more) - Start talking to your hardware and software vendors about v6 and understanding their product roadmaps, timelines and so on. With all this, when it becomes inevitable you won?t have to suddenly do a ton of work?. Or you could buy ?Migrating my corporate network to IPv6 for Dummies? ?Skeeve From: Dave Temkin [mailto:davet1 at gmail.com] Sent: Wednesday, 4 February 2009 9:06 AM To: skeeve at skeeve.org Cc: 'Zaid Ali'; 'Roger Marquis'; nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space The problem with that solution mainly being that the application itself still needs some sort of intelligence as well as the border device potentially doing L7 operations (header insertion/etc.) - unless you're OK with generally losing all information about the source of incoming traffic at the backend (except for looking at NAT tables...) -Dave Skeeve Stevens wrote: With new dual-stack border devices people will be able to move bit by bit, and there is no real reason to have to run around and change everything that you have internally. These will change and update over time. These internal applications aren't running on public IP addresses anyway. ...Skeeve -----Original Message----- From: Zaid Ali [mailto:zaid at zaidali.com] Sent: Wednesday, 4 February 2009 5:19 AM To: Roger Marquis Cc: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. >From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid ----- Original Message ----- From: "Roger Marquis" To: nanog at nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis From skeeve at skeeve.org Tue Feb 3 16:30:22 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 09:30:22 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <49875357.3020503@davidcoulson.net> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <004601c98571$d58c7340$80a559c0$@com> <49875357.3020503@davidcoulson.net> Message-ID: Well Quest is stupid for allowing unallocated space to transit it's network. I've seen ISP's in which a traceroute to 192.168.0.1 got into their network, and to their upstreams before being killed off at some point.... sheesh -----Original Message----- From: David Coulson [mailto:david at davidcoulson.net] Sent: Tuesday, 3 February 2009 7:11 AM To: Bruce Grobler Cc: 'NANOG list' Subject: Re: Private use of non-RFC1918 IP space I can mtr to 1.1.1.1 via Qwest :-) Bruce Grobler wrote: > Yep!, go ahead and trace it. > > -----Original Message----- > From: David Conrad [mailto:drc at virtualized.org] > Sent: Monday, February 02, 2009 9:48 PM > To: Bruce Grobler > Cc: NANOG list > Subject: Re: Private use of non-RFC1918 IP space > > On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: > >> Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't >> encounter any problems using it in a private network. >> > > Is this true? > > This will cause endless entertainment when IANA allocates 1.0.0.0/8 > sometime within the next two or three years... > > Regards, > -drc > > > From skeeve at skeeve.org Tue Feb 3 16:47:41 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 09:47:41 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: OK, I will make an (what looks to this list) embarrassing admission. We use 1.0.0.0/8 for our internal ranges, but this is on a small scale. We do it because of the kind of business we do... we manage many other much larger networks which already use every possible overlapping RFC1918 network you can imagine... we have half a dozen networks using 192.168.0, and even more using many varied masks in the 10.0.0.0/8. We already have issues with the overlapping networks as is, without making it worse for us by using on of them. I chose to go the 1.0.0.0 path because: - It wont conflict with my customers and us doing our business - As long as it is not APNIC who gets it, the chances of it conflicting will be extremely minimal (rolls dice) - We don't design customer networks with non-RFC1918 ranges unless there is some extreme reason - Yes it is potentially allocate-able in the future, but if it happens I will deal with it then - just renumber or see the next point - We will be fully IPv6 within 6-9 months with a separate VLAN which will support legacy equipment with NAT-PT... this will still be an issue interconnecting to customer networks, but we will think of something. ..Skeeve -----Original Message----- From: David Conrad [mailto:drc at virtualized.org] Sent: Tuesday, 3 February 2009 6:48 AM To: Bruce Grobler Cc: NANOG list Subject: Re: Private use of non-RFC1918 IP space On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > encounter any problems using it in a private network. Is this true? This will cause endless entertainment when IANA allocates 1.0.0.0/8 sometime within the next two or three years... Regards, -drc From skeeve at skeeve.org Tue Feb 3 16:48:43 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 09:48:43 +1100 Subject: FW: News Delivery Report (Failure) Message-ID: Broken? ...Skeeve -----Original Message----- From: mail [mailto:postmaster at mail.theyscrewedusagain.com] Sent: Wednesday, 4 February 2009 9:05 AM To: skeeve at skeeve.org Subject: News Delivery Report (Failure) Your Article "RE: Private use of non-RFC1918 IP space" (Wed, 4 Feb 2009 09:03:06 +1100) could not be successfully delivered to the following news groups :- homeless.security News Server: news.barkto.com Response: 441 Faulty message ID format Your message is quoted below :- From: "Skeeve Stevens" Newsgroups: homeless.security Path: mail.theyscrewedusagain.com To: "'Zaid Ali'" , "'Roger Marquis'" References: <16474135.451233684880488.JavaMail.zaid at turing-2.local> <10812089.471233685164238.JavaMail.zaid at turing-2.local> In-Reply-To: <10812089.471233685164238.JavaMail.zaid at turing-2.local> Subject: RE: Private use of non-RFC1918 IP space Date: Wed, 4 Feb 2009 09:03:06 +1100 Lines: 71 Organization: eintellego Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmGLAntiH4eXFtJRiuUjFBXl6Hk+QAHrz0w Content-Language: en-au Cc: nanog at nanog.org X-BeenThere: nanog at nanog.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: skeeve at skeeve.org List-Id: North American Network Operators Group ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From heather.schiller at verizonbusiness.com Tue Feb 3 17:00:51 2009 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Tue, 03 Feb 2009 18:00:51 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: <4987DDA5.3060109@sprunk.org> References: <49555.1233631443@turing-police.cc.vt.edu> <4987DDA5.3060109@sprunk.org> Message-ID: <4988CCA3.3050207@verizonbusiness.com> Stephen Sprunk wrote: > Patrick W. Gilmore wrote: >> Except the RIRs won't give you another /48 when you have only used one >> trillion IP addresses. > Keyword: *Another* > Are you sure? According to ARIN staff, current implementation of policy > is that all requests are approved since there are no defined criteria > that would allow them to deny any. So far, nobody's shown interest in > plugging that hole in the policy because it'd be a major step forward if > IPv6 were popular enough for anyone to bother wasting it... > > S > I believe Stephen is thinking of initial allocation policy - because a subsequent allocation policy in the ARIN region exists: (and it's been modified atleast once in the last few years) Justification to obtain another netblock is .94 HD-Ratio in the current allocation Endusers (minimum allocation is a /48) For a /48 that's about 72% utilization or 184 /56's assigned/used ISP's (minimum allocation is a /32) For a /32 that's about 37% utilization or 6,183,533 /56's assigned ARIN provides a handy chart: http://www.arin.net/policy/nrpm.html#six7 From deepak at ai.net Tue Feb 3 17:09:46 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 3 Feb 2009 18:09:46 -0500 Subject: IPv6 space (was: RE: Private use of non-RFC1918 IP space ) In-Reply-To: References: <200902030539.n135dQu9032856@drugs.dv.isc.org> Message-ID: > Which is exactly what they should do - actually before that one would > hope. This is not the "$200/hour chcklehead consultant"'s fault, that > is the design. > > Don't you love the idea of using 18446744073709551616 IP addresses to > number a point-to-point link? > Let's not ignore that all IPv6 allocations are basically charged-for, so my expectation is that there will be fewer "idle" allocations that can't be recovered running around (when an org has to justify $36,000 per year [after 2012], forever, some bean counter may ask why... especially if they can get a "sensibly" sized allocation from their provider for a fraction of that cost). I'm not sure if that is cynical, or optimistic, but since the allocations are not free, there seems to be less incentive to squat. Deepak Jain AiNET From heather.schiller at verizonbusiness.com Tue Feb 3 17:14:45 2009 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Tue, 03 Feb 2009 18:14:45 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> Message-ID: <4988CFE5.4060606@verizonbusiness.com> Skeeve Stevens wrote: > Owned by an ISP? It isn't much different than it is now. > > As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this. > > Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap. > > I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now. RFC4193 - Unique Local IPv6 Unicast Addresses http://www.iana.org/assignments/ipv6-address-space FC00::/7 Unique Local Unicast [RFC4193] ..maybe they should have called it RFC1918 for IPv6. FWIW, 2001:0DB8::/32 was allocated by APNIC. Not quite the same as being an RFC/IANA delegated/reserved netblock. --heather ==================================================== Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management help4u at verizonbusiness.com ===================================================== From jeroen at unfix.org Tue Feb 3 17:17:58 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 04 Feb 2009 00:17:58 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> Message-ID: <4988D0A6.3070303@spaghetti.zurich.ibm.com> Skeeve Stevens wrote: [please fix your line length, my screen is still not a 100"] > Owned by an ISP? It isn't much different than it is now. > > As long as you are multi-homed you can get a small allocation (/48), > APNIC and ARIN have procedures for this. > > Yes, you have to pay for it, but the addresses will be yours, unlike > the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share > and hope we never interconnect/overlap. > > I can't find a RFC1918 equivalent for v6 with the exception of > 2001:0DB8::/32# which is the ranges that has been assigned for > documentation use and is considered to NEVER be routable. In that /32 > are 65536 /48's... way more than the RFC1918 we have now. Documentation is exactly that: Documentation. Do not EVER use that in a real box. If you need 'RFC1918 alike' space then go for ULA (RFC4193). Also see http://www.sixxs.net/tools/grh/ula/ for a semi-registered version of that. If you want "guaranteed unique" then go to a RIR. > If I was going to build a v6 network right now, that was purely > private and never* going to hit the internet, and I could not > afford to be a NIC member or pay the fees... then I would be using > the ranges above.... I wonder if that will start a flame war *puts on fire suit*. Google goes straight through that suit, I suggest you use it and read up on IPv6. Even the Wikipedia entry contains this information. google(rfc1918 ipv6) or http://en.wikipedia.org/wiki/Private_network Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From owen at delong.com Tue Feb 3 17:25:03 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 3 Feb 2009 15:25:03 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> Message-ID: <7094FC6A-E554-49C6-9C37-9363F30E0534@delong.com> On Feb 3, 2009, at 2:18 PM, Skeeve Stevens wrote: > Owned by an ISP? It isn't much different than it is now. > > As long as you are multi-homed you can get a small allocation (/48), > APNIC and ARIN have procedures for this. > To clarify, you can get whatever size assignment you need, but, the default unless you request larger and can justify it is a /48. To put this in perspective, a /48 is 65536*4billion*the total IPv4 address space. Further, it's enough space for 65,536 subnets with 64 bit host addresses. Likely, this is enough for most end-user organizations, but, if you are part of an organization that needs more, you can get it simply by justifying your additional needs. > Yes, you have to pay for it, but the addresses will be yours, unlike > the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just > share and hope we never interconnect/overlap. > In the ARIN region, the end-user annual fees are quite low. I don't see this as a significant barrier to entry to most end-user organizations. > I can't find a RFC1918 equivalent for v6 with the exception of > 2001:0DB8::/32# which is the ranges that has been assigned for > documentation use and is considered to NEVER be routable. In that / > 32 are 65536 /48's... way more than the RFC1918 we have now. > There is the ULA-Random space, but, I'm not sure if that got ratified or was rescinded. I really don't see a need for RFC-1918 in the IPv6 world. RFC-1918 was intended to solve a problem with a shortage of address space by allowing disparate private networks to recycle the same numbers behind NAT or for use on non-connected networks. There is no such shortage in IPv6. I think it is wiser to number non-connected IPv6 networks from valid unique addresses since there is no shortage. > If I was going to build a v6 network right now, that was purely > private and never* going to hit the internet, and I could not afford > to be a NIC member or pay the fees... then I would be using the > ranges above.... I wonder if that will start a flame war *puts on > fire suit*. > I don't know what the APNIC fees and membership requirements are. However, in the ARIN region, you do not need to be a member to get address space. The renewal fee for end-user space is $100/year. If you can't afford $100/year, how are you staying connected to the network or paying to power your equipment? Owen > ...Skeeve > > > * never say never! > # http://www.iana.org/assignments/ipv6-unicast-address-assignments > > > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Wednesday, 4 February 2009 5:25 AM > To: 'Zaid Ali'; 'Roger Marquis' > Cc: 'nanog at nanog.org' > Subject: RE: Private use of non-RFC1918 IP space > > It's not just technical. Companies are reluctant to migrate to an IP > address > owned by an ISP. We are one of those companies. If and when it is > easy for us > to apply and receive our own Ipv6 address space, we will look at > deploying > ipv6, but not until then. That's not a technical issue, but rather a > business > decision, and it's not going to change. We aren't depending our > network > resources on an external third-party, especially given their track > record. > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > >> -----Original Message----- >> From: Zaid Ali [mailto:zaid at zaidali.com] >> Sent: Tuesday, February 03, 2009 1:19 PM >> To: Roger Marquis >> Cc: nanog at nanog.org >> Subject: Re: Private use of non-RFC1918 IP space >> >> I don't consider IPv6 a popularity contest. It's about the motivation >> and the willingness to. Technical issues can be resolved if you and >> people around you are motivated to do so. I think there are some hard >> facts that need to be addressed when it comes to IPv6. Facts like >> >> 1. How do we migrate to a IPv6 stack on all servers and I am talking >> about the >> thousands of servers that exist on peoples network that run SaaS, >> Financial/Banking systems. >> >> 2. How do we make old applications speak IPv6? There are some old >> back- >> end systems >> that run core functions for many businesses out there that don't >> really have any >> upgrade path and I don't think people are thinking about this. >> >>> From a network perspective IPv6 adoption is just about doing it and >> executing with your fellow AS neighbors. The elephant in the room is >> the applications that ride on your network. >> >> Zaid >> >> ----- Original Message ----- >> From: "Roger Marquis" >> To: nanog at nanog.org >> Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada >> Pacific >> Subject: Re: Private use of non-RFC1918 IP space >> >> Stephen Sprunk wrote: >>> Patrick W. Gilmore wrote: >>>> Except the RIRs won't give you another /48 when you have only used >> one >>>> trillion IP addresses. >>> >>> Are you sure? According to ARIN staff, current implementation of >> policy >>> is that all requests are approved since there are no defined >>> criteria >>> that would allow them to deny any. So far, nobody's shown interest >> in >>> plugging that hole in the policy because it'd be a major step >>> forward >> if >>> IPv6 were popular enough for anyone to bother wasting it... >> >> Catch 22? From my experience IPv6 is unlikely to become popular >> until >> it >> fully supports NAT. >> >> Much as network providers love the thought of owning all of your >> address >> space, and ARIN of billing for it, and RFCs like 4864 of providing >> rhetorical but technically flawed arguments against it, the lack of >> NAT >> only pushes adoption of IPv6 further into the future. >> >> Roger Marquis >> > > From nanog at daork.net Tue Feb 3 17:43:21 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 4 Feb 2009 12:43:21 +1300 Subject: Private use of non-RFC1918 IP space In-Reply-To: <7094FC6A-E554-49C6-9C37-9363F30E0534@delong.com> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> <7094FC6A-E554-49C6-9C37-9363F30E0534@delong.com> Message-ID: <79BBA445-FA0B-4679-B32F-9881FDA2A517@daork.net> On 4/02/2009, at 12:25 PM, Owen DeLong wrote: > There is the ULA-Random space, but, I'm not sure if that got > ratified or was > rescinded. I really don't see a need for RFC-1918 in > the IPv6 world. RFC-1918 was intended to solve a problem with a > shortage > of address space by allowing disparate private networks to recycle > the same > numbers behind NAT or for use on non-connected networks. There is no > such shortage in IPv6. I think it is wiser to number non-connected > IPv6 networks > from valid unique addresses since there is no shortage. ULA is useful for organisations that cannot get an RIR allocation/ assignment, so are likely to need to re-number. If they number on ULA *in addition to* whatever space their ISP gives them, they do not need to alter any internal DNS, ACLs, etc. etc. if/ when they re-number. An easy example of a good use for ULA might be the internal recursive DNS server addresses that the DHCPv6 server hands out. If they are so inclined, they might even re-number dynamically if they get their prefix using PD. -- Nathan Ward From peterc at luddite.com.au Tue Feb 3 18:05:57 2009 From: peterc at luddite.com.au (Peter J. Cherny) Date: Wed, 04 Feb 2009 11:05:57 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <7094FC6A-E554-49C6-9C37-9363F30E0534@delong.com> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> <7094FC6A-E554-49C6-9C37-9363F30E0534@delong.com> Message-ID: <4988DBE5.2050804@luddite.com.au> Owen DeLong wrote: >... > I don't know what the APNIC fees and membership requirements are. A succinct summary, see below ! > However, in the ARIN region, you do not need to be a member to get > address space. The renewal fee for end-user space is $100/year. > If you can't afford $100/year, how are you staying connected to the > network or paying to power your equipment? APNIC fees are an order of magnitude (or more) higher ! http://www.apnic.net/member/feesinfo.html#non_mem_fee ftp://ftp.apnic.net/apnic/docs/non-member-fees-2008 (APNIC-118) I quote from APNIC-118 : A host address in IPv4 is defined as a /32 and a site address in IPv6 is defined a /48. The initial fee for an assignment or allocation of IP addresses is AU$1.27 per host or site address, with a minimum fee of AU$10,384. After the first year of the initial assignment or allocation, there is an annual registration fee is AU$0.127 per host or site address, with a minimum fee of AU$1,038.40. From skeeve at skeeve.org Tue Feb 3 18:38:16 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 11:38:16 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <4988DBE5.2050804@luddite.com.au> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> <7094FC6A-E554-49C6-9C37-9363F30E0534@delong.com> <4988DBE5.2050804@luddite.com.au> Message-ID: Exactly..... So.. do I have to be in the US to get ARIN space? Technically space you get is announceable anywhere in the world... Can I just have a /32 from ARIN please and not pay the ton of money that APNIC ask for? I can setup a POBOX in New York if that will help? ;-) Actually, that is an interesting question... If I have a network I am building in the US/other locale, but I am based here, can I become an ARIN/RIPE/etc member and get a range out of them? ...Skeeve -----Original Message----- From: Peter J. Cherny [mailto:peterc at luddite.com.au] Sent: Wednesday, 4 February 2009 11:06 AM To: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space Owen DeLong wrote: >... > I don't know what the APNIC fees and membership requirements are. A succinct summary, see below ! > However, in the ARIN region, you do not need to be a member to get > address space. The renewal fee for end-user space is $100/year. > If you can't afford $100/year, how are you staying connected to the > network or paying to power your equipment? APNIC fees are an order of magnitude (or more) higher ! http://www.apnic.net/member/feesinfo.html#non_mem_fee ftp://ftp.apnic.net/apnic/docs/non-member-fees-2008 (APNIC-118) I quote from APNIC-118 : A host address in IPv4 is defined as a /32 and a site address in IPv6 is defined a /48. The initial fee for an assignment or allocation of IP addresses is AU$1.27 per host or site address, with a minimum fee of AU$10,384. After the first year of the initial assignment or allocation, there is an annual registration fee is AU$0.127 per host or site address, with a minimum fee of AU$1,038.40. From skeeve at skeeve.org Tue Feb 3 18:57:36 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 11:57:36 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: OK. Following myself up, and referencing a link someone else gave me in regards to IPv6 http://en.wikipedia.org/wiki/Private_network Has the entry: Private use of other reserved addresses Several other address ranges, in addition to the official private ranges, are reserved for other or future uses, including 1.0.0.0/8 and 2.0.0.0/8[1]. In recent years, large companies have begun to use this address space internally. Though discouraged, it appears to have become an accepted practice among larger companies to use these reserved address spaces when connecting two private networks, to eliminate the chance of address conflicts when using standards-based private ranges. --- Now I'm not using this as justification.... just interesting to see people have put it up there, and comment that a lot of large companies are using 1/8 and 2/8 for private networking. ...Skeeve -----Original Message----- From: Skeeve Stevens [mailto:skeeve at skeeve.org] Sent: Wednesday, 4 February 2009 9:48 AM To: 'David Conrad'; 'Bruce Grobler' Cc: 'NANOG list' Subject: RE: Private use of non-RFC1918 IP space OK, I will make an (what looks to this list) embarrassing admission. We use 1.0.0.0/8 for our internal ranges, but this is on a small scale. We do it because of the kind of business we do... we manage many other much larger networks which already use every possible overlapping RFC1918 network you can imagine... we have half a dozen networks using 192.168.0, and even more using many varied masks in the 10.0.0.0/8. We already have issues with the overlapping networks as is, without making it worse for us by using on of them. I chose to go the 1.0.0.0 path because: - It wont conflict with my customers and us doing our business - As long as it is not APNIC who gets it, the chances of it conflicting will be extremely minimal (rolls dice) - We don't design customer networks with non-RFC1918 ranges unless there is some extreme reason - Yes it is potentially allocate-able in the future, but if it happens I will deal with it then - just renumber or see the next point - We will be fully IPv6 within 6-9 months with a separate VLAN which will support legacy equipment with NAT-PT... this will still be an issue interconnecting to customer networks, but we will think of something. ..Skeeve -----Original Message----- From: David Conrad [mailto:drc at virtualized.org] Sent: Tuesday, 3 February 2009 6:48 AM To: Bruce Grobler Cc: NANOG list Subject: Re: Private use of non-RFC1918 IP space On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > encounter any problems using it in a private network. Is this true? This will cause endless entertainment when IANA allocates 1.0.0.0/8 sometime within the next two or three years... Regards, -drc From Mark_Andrews at isc.org Tue Feb 3 18:55:51 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 04 Feb 2009 11:55:51 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Wed, 04 Feb 2009 11:38:16 +1100." Message-ID: <200902040055.n140tpBr055477@drugs.dv.isc.org> In message , "Skeeve Stevens" writes: > Exactly..... > > So.. do I have to be in the US to get ARIN space? Technically space you get > is announceable anywhere in the world... > Can I just have a /32 from ARIN please and not pay the ton of money that > APNIC ask for? > I can setup a POBOX in New York if that will help? ;-) > > Actually, that is an interesting question... If I have a network I am > building in the US/other locale, but I am based here, can I become an > ARIN/RIPE/etc member and get a range out of them? If you are build in the US you will presumable connecting it the US so you should be getting the space from ARIN. This will help with address allocations aligned with the geography. I can well seen US sites filtering all APNIC allocations and using a covering prefix to reach APNIC sites as one way to handle route growth. > ...Skeeve > > -----Original Message----- > From: Peter J. Cherny [mailto:peterc at luddite.com.au] > Sent: Wednesday, 4 February 2009 11:06 AM > To: nanog at nanog.org > Subject: Re: Private use of non-RFC1918 IP space > > Owen DeLong wrote: > >... > > I don't know what the APNIC fees and membership requirements are. > > A succinct summary, see below ! > > > However, in the ARIN region, you do not need to be a member to get > > address space. The renewal fee for end-user space is $100/year. > > If you can't afford $100/year, how are you staying connected to the > > network or paying to power your equipment? > > APNIC fees are an order of magnitude (or more) higher ! > > http://www.apnic.net/member/feesinfo.html#non_mem_fee > ftp://ftp.apnic.net/apnic/docs/non-member-fees-2008 (APNIC-118) > > I quote from APNIC-118 : > > A host address in IPv4 is defined as a /32 and a site address > in IPv6 is defined a /48. > > The initial fee for an assignment or allocation of IP > addresses is AU$1.27 per host or site address, with a minimum > fee of AU$10,384. > > After the first year of the initial assignment or allocation, > there is an annual registration fee is AU$0.127 per host or > site address, with a minimum fee of AU$1,038.40. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From mpalmer at hezmatt.org Tue Feb 3 19:25:37 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 4 Feb 2009 12:25:37 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> Message-ID: <20090204012537.GB11448@hezmatt.org> On Wed, Feb 04, 2009 at 11:57:36AM +1100, Skeeve Stevens wrote: > OK. > > Following myself up, and referencing a link someone else gave me in regards > to IPv6 > > http://en.wikipedia.org/wiki/Private_network > > Has the entry: > > Private use of other reserved addresses > > Several other address ranges, in addition to the official private ranges, > are reserved for other or future uses, including 1.0.0.0/8 and 2.0.0.0/8[1]. > In recent years, large companies have begun to use this address space > internally. [citation required] - Matt From skeeve at skeeve.org Tue Feb 3 19:29:36 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 12:29:36 +1100 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090204012537.GB11448@hezmatt.org> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <20090204012537.GB11448@hezmatt.org> Message-ID: I agree... I'd love to know where they got that from... who even wrote it? ...Skeeve -----Original Message----- From: Matthew Palmer [mailto:mpalmer at hezmatt.org] Sent: Wednesday, 4 February 2009 12:26 PM To: nanog at nanog.org Subject: Re: Private use of non-RFC1918 IP space On Wed, Feb 04, 2009 at 11:57:36AM +1100, Skeeve Stevens wrote: > OK. > > Following myself up, and referencing a link someone else gave me in regards > to IPv6 > > http://en.wikipedia.org/wiki/Private_network > > Has the entry: > > Private use of other reserved addresses > > Several other address ranges, in addition to the official private ranges, > are reserved for other or future uses, including 1.0.0.0/8 and 2.0.0.0/8[1]. > In recent years, large companies have begun to use this address space > internally. [citation required] - Matt From steve at ibctech.ca Tue Feb 3 19:33:23 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 03 Feb 2009 20:33:23 -0500 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <497D1764.4050709@ibctech.ca> References: <497D1764.4050709@ibctech.ca> Message-ID: <4988F063.1030201@ibctech.ca> For all the kind folk who have been asking how my project is going, I'll summarize here. - I've enabled strict uRPF filtering on all interfaces that I am certain what the source will be. - I've implemented a mix of loose uRPF combined with ACL's on interfaces that I know have multi-homed clients - On all interfaces that run the risk of blocking traffic by accident, I've implemented strict inbound ACL's for known-bad (combined always with Team Cymru BGP learnt bogons), and with logging counter ACLs for all other traffic. After a couple more days, I should be able to focus more strictly on these interfaces - I've made significant changes to my 'core', moving from static routes to an iBGP mesh over OSPF learnt loopbacks. This will allow me to implement a couple of host-based routing daemon boxes for the easy insertion of sinkhole routes in the event of significantly bad behaviour. With my scripting knowledge, preparing a recommended sinkhole route for insertion, ready for admin approval will be easy, and so will having the route removed automatically (or manually) if the attack has ceased. I like the idea of traffic flowing to a host-based machine to null as opposed to null'ing it on the router, as (from what I can tell) it will make it easier to track the flow of the problem ingress and egress - Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6. The division of the v6 space still overwhelms me, so I guess I'll do what someone else stated in another thread if I mess this one up: go to ARIN for another 1000 /32's :) (no, I'll learn from my mistake, and be ready for next one) Cheers, and thanks! Steve From nanog at daork.net Tue Feb 3 19:40:17 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 4 Feb 2009 14:40:17 +1300 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <4988F063.1030201@ibctech.ca> References: <497D1764.4050709@ibctech.ca> <4988F063.1030201@ibctech.ca> Message-ID: On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: > - Currently, (as I write), I'm migrating my entire core from IPv4 to > IPv6. I've got the space, and I love to learn, so I'm just lab-ing > it up > now to see how things will flow with all iBGP v4 routes being > advertised/routed over v6. Don't advertise v4 prefixes in v6 sessions, keep them separate. If you do, you have to do set next-hops with route maps and things, it's kind of nasty. Better to just run a v4 BGP mesh and a v6 BGP mesh. -- Nathan Ward From steve at ibctech.ca Tue Feb 3 19:43:32 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 03 Feb 2009 20:43:32 -0500 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: References: <497D1764.4050709@ibctech.ca> <4988F063.1030201@ibctech.ca> Message-ID: <4988F2C4.3090100@ibctech.ca> Nathan Ward wrote: > On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: > >> - Currently, (as I write), I'm migrating my entire core from IPv4 to >> IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up >> now to see how things will flow with all iBGP v4 routes being >> advertised/routed over v6. > > > Don't advertise v4 prefixes in v6 sessions, keep them separate. > > If you do, you have to do set next-hops with route maps and things, it's > kind of nasty. > > Better to just run a v4 BGP mesh and a v6 BGP mesh. Ok. I've been having problems with this. What I was hoping for (even though I'm testing something that I know won't work) is that I can break something so I could push v4 traffic over a v6-only core. Is there _any_ way to do this (other than NAT/tunnel etc)? Steve From skeeve at skeeve.org Tue Feb 3 19:53:32 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 4 Feb 2009 12:53:32 +1100 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: References: <497D1764.4050709@ibctech.ca> <4988F063.1030201@ibctech.ca> Message-ID: Agreed. Keeping it separate works very well. Can be the same interface sure... but do it as a separate session. ...Skeeve -----Original Message----- From: Nathan Ward [mailto:nanog at daork.net] Sent: Wednesday, 4 February 2009 12:40 PM To: nanog list Subject: Re: [Update] Re: New ISP to market, BCP 38, and new tactics On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: > - Currently, (as I write), I'm migrating my entire core from IPv4 to > IPv6. I've got the space, and I love to learn, so I'm just lab-ing > it up > now to see how things will flow with all iBGP v4 routes being > advertised/routed over v6. Don't advertise v4 prefixes in v6 sessions, keep them separate. If you do, you have to do set next-hops with route maps and things, it's kind of nasty. Better to just run a v4 BGP mesh and a v6 BGP mesh. -- Nathan Ward From nanog at daork.net Tue Feb 3 19:51:16 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 4 Feb 2009 14:51:16 +1300 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <4988F2C4.3090100@ibctech.ca> References: <497D1764.4050709@ibctech.ca> <4988F063.1030201@ibctech.ca> <4988F2C4.3090100@ibctech.ca> Message-ID: <8896CE14-9EEE-4F4C-8CF1-93925DF95B10@daork.net> On 4/02/2009, at 2:43 PM, Steve Bertrand wrote: > Nathan Ward wrote: >> On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: >> >>> - Currently, (as I write), I'm migrating my entire core from IPv4 to >>> IPv6. I've got the space, and I love to learn, so I'm just lab-ing >>> it up >>> now to see how things will flow with all iBGP v4 routes being >>> advertised/routed over v6. >> >> >> Don't advertise v4 prefixes in v6 sessions, keep them separate. >> >> If you do, you have to do set next-hops with route maps and things, >> it's >> kind of nasty. >> >> Better to just run a v4 BGP mesh and a v6 BGP mesh. > > Ok. I've been having problems with this. > > What I was hoping for (even though I'm testing something that I know > won't work) is that I can break something so I could push v4 traffic > over a v6-only core. > > Is there _any_ way to do this (other than NAT/tunnel etc)? MPLS - "The MP is for Multi Protocol!" Otherwise, no, you don't get to use IPv6 addresses as next hops for IPv4 routes, which I think is what you're asking to do. Run IPv4 and IPv6 in parallel, iBGP for v4, iBGP for v6. Same for eBGP to peers/customers. Running v4 and v6 in one BGP session is weird and is asking for confusion, IMHO. You get the same with OSPF - you run OSPFv2 and OSPFv3 in parallel. -- Nathan Ward From owen at delong.com Tue Feb 3 19:56:05 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 3 Feb 2009 17:56:05 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: <20090204012537.GB11448@hezmatt.org> References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <20090204012537.GB11448@hezmatt.org> Message-ID: <2A8853FE-9147-4C52-B835-C7D2C44923FD@delong.com> On Feb 3, 2009, at 5:25 PM, Matthew Palmer wrote: > On Wed, Feb 04, 2009 at 11:57:36AM +1100, Skeeve Stevens wrote: >> OK. >> >> Following myself up, and referencing a link someone else gave me in >> regards >> to IPv6 >> >> http://en.wikipedia.org/wiki/Private_network >> >> Has the entry: >> >> Private use of other reserved addresses >> >> Several other address ranges, in addition to the official private >> ranges, >> are reserved for other or future uses, including 1.0.0.0/8 and >> 2.0.0.0/8[1]. >> In recent years, large companies have begun to use this address space >> internally. > > [citation required] > > - Matt I've added a blurb to this page expressing the risks associated with such use. Owen From steve at ibctech.ca Tue Feb 3 20:10:02 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 03 Feb 2009 21:10:02 -0500 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: References: <497D1764.4050709@ibctech.ca> <4988F063.1030201@ibctech.ca> Message-ID: <4988F8FA.3080402@ibctech.ca> Skeeve Stevens wrote: > Agreed. Keeping it separate works very well. Can be the same interface > sure... but do it as a separate session. Yeah, that's what I thought, and that is exactly what I've been doing thus far. I was hoping to have a v6-only core, but in order to get the current project done, I'll have to stay with your (and Nathan's) recommendation. I'm not ready for MPLS (but I am interested in the theory of it's purpose), so when I'm done what I'm doing now, I'll look at it. At that time, if implemented, I'll be the most complex, smallest ISP in Canada ;) This has been an awesome journey, and I've learnt an immense amount via all of the recommendations, reading and exercising. Thanks guys, Steve From jacques at siberia.co.za Tue Feb 3 20:40:17 2009 From: jacques at siberia.co.za (Jacques Marneweck) Date: Tue, 3 Feb 2009 21:40:17 -0500 Subject: outblaze contact Message-ID: Hi, I'm looking to chat to someone from outblaze. If anyone works at outblaze or has a contact there can you chat to me offlist. Regards --jm From ross at ign.com Tue Feb 3 21:52:44 2009 From: ross at ign.com (Ross Dmochowski) Date: Tue, 3 Feb 2009 19:52:44 -0800 Subject: Database backed DNS Management Solutions Message-ID: <609FCB2B-0B00-4B49-9BC2-AF07B2451510@mimectl> Dear NANOG: I hope I can solicit some feedback from this venerable group. :-) Currently, my group operates 16 BIND servers across 5 datacenters, handling internal and external namespace duties. These servers are responsible for both internal and external forward and reverse name and IP spaces. There are also a number of Windows AD servers that hold their own namespaces, that the BIND servers slave from this info from, so names resolve between these domains. Windows AD forwards queries for internal zones it does not own to the appropriate namespace holder. So Windows DNS server interoperability is a business requirement. Some of these zones are dynamic, some are static. None of the dynamic zones are populated via DHCP, but by self-registration. We have heretofore used some in-house scripts for managing this, but obviously, the thought of keeping and managing this data in something other than its current form has caught on in our minds, and so therefore we are looking at a proposal put forth, to replace all of our BIND servers with a PowerDNS infrastructure. BIND has been the backbone of the Internet, and so many of us are wary of replacing BIND, when in essence, BIND itself is not the issue, nor is it broken. Has anyone done any in house comparance of PowerDNS versus BIND-DLZ? Googling has led to some useful info but no useful side by side comparances that are not obviously partisan. I favor something like ProBIND2, that keeps the data in the DB, but does not tie the serving of the data, etc to anything other than BIND. Any success/horror stories from implementing BIND management solutions is very welcome. If anyone has any success/horror stories about PowerDNS, BIND-DLZ, or a system like ProBind2 or NetDB (from Stanford) to manage BIND and its configurations in a DB, I would be very interested in hearing them. :-) Thank you. Best Regards, Ross S. Dmochowski Sr. Linux Administrator IGN/Gamespy/Fox Interactive Media ross at ign.com From ilopezlists at sandboxitsolutions.com Tue Feb 3 22:19:54 2009 From: ilopezlists at sandboxitsolutions.com (Israel Lopez - Lists) Date: Tue, 03 Feb 2009 20:19:54 -0800 Subject: Database backed DNS Management Solutions In-Reply-To: <609FCB2B-0B00-4B49-9BC2-AF07B2451510@mimectl> References: <609FCB2B-0B00-4B49-9BC2-AF07B2451510@mimectl> Message-ID: <4989176A.2050005@sandboxitsolutions.com> At the last place I worked at we had an installation of NicTool v1.2. We pushed out DNS updates for our hosting company over 4 servers, two local and two off-site. It was very nice to work with, but I havent used it in the 2.x iteration. http://www.nictool.com/ - Give it a look-over. Supports BIND, TinyDNS, and PowerDNS. -Israel Ross Dmochowski wrote: > Dear NANOG: > > I hope I can solicit some feedback from this venerable group. :-) > > Currently, my group operates 16 BIND servers across 5 datacenters, > handling internal and external namespace duties. These servers are > responsible for both internal and external forward and reverse > name and IP spaces. > > There are also a number of Windows AD servers that hold their own namespaces, > that the BIND servers slave from this info from, so names resolve between these > domains. Windows AD forwards queries for internal zones it does not own > to the appropriate namespace holder. > > So Windows DNS server interoperability is a business requirement. > > Some of these zones are dynamic, some are static. > None of the dynamic zones are populated via DHCP, but by self-registration. > > We have heretofore used some in-house scripts for managing this, but > obviously, the thought of keeping and managing this data in something > other than its current form has caught on in our minds, and > so therefore we are looking at a proposal put forth, to replace all > of our BIND servers with a PowerDNS infrastructure. > > BIND has been the backbone of the Internet, and so many of us are > wary of replacing BIND, when in essence, BIND itself is not the issue, > nor is it broken. > > Has anyone done any in house comparance of PowerDNS versus BIND-DLZ? > Googling has led to some useful info but no useful side by side > comparances that are not obviously partisan. > > I favor something like ProBIND2, that keeps the data in the DB, but does not > tie the serving of the data, etc to anything other than BIND. > > Any success/horror stories from implementing BIND management solutions is > very welcome. > > If anyone has any success/horror stories about PowerDNS, BIND-DLZ, or > a system like ProBind2 or NetDB (from Stanford) to manage BIND and its configurations > in a DB, I would be very interested in hearing them. :-) > > Thank you. > > Best Regards, > Ross S. Dmochowski > Sr. Linux Administrator > IGN/Gamespy/Fox Interactive Media > ross at ign.com > From fiberoptic at rizon.net Wed Feb 4 01:19:17 2009 From: fiberoptic at rizon.net (fiberOptiC) Date: Wed, 4 Feb 2009 00:19:17 -0700 Subject: Database backed DNS Management Solutions In-Reply-To: <4989176A.2050005@sandboxitsolutions.com> References: <609FCB2B-0B00-4B49-9BC2-AF07B2451510@mimectl> <4989176A.2050005@sandboxitsolutions.com> Message-ID: <6f7f98120902032319k32cf390ew45eab27a5fb5920f@mail.gmail.com> I use a PowerDNS setup with mysql backend. It works really well for our 5 dns server setup. Things to watch out for are replication breaks in the mysql database. On Tue, Feb 3, 2009 at 9:19 PM, Israel Lopez - Lists < ilopezlists at sandboxitsolutions.com> wrote: > At the last place I worked at we had an installation of NicTool v1.2. We > pushed out DNS updates for our hosting company over 4 servers, two local and > two off-site. It was very nice to work with, but I havent used it in the > 2.x iteration. > > http://www.nictool.com/ - Give it a look-over. Supports BIND, TinyDNS, > and PowerDNS. > > -Israel > > Ross Dmochowski wrote: > >> Dear NANOG: >> >> I hope I can solicit some feedback from this venerable group. :-) >> >> Currently, my group operates 16 BIND servers across 5 datacenters, >> handling internal and external namespace duties. These servers are >> responsible for both internal and external forward and reverse >> name and IP spaces. >> >> There are also a number of Windows AD servers that hold their own >> namespaces, >> that the BIND servers slave from this info from, so names resolve between >> these domains. Windows AD forwards queries for internal zones it does not >> own >> to the appropriate namespace holder. >> So Windows DNS server interoperability is a business requirement. >> >> Some of these zones are dynamic, some are static. None of the dynamic >> zones are populated via DHCP, but by self-registration. >> >> We have heretofore used some in-house scripts for managing this, but >> obviously, the thought of keeping and managing this data in something >> other than its current form has caught on in our minds, and so therefore >> we are looking at a proposal put forth, to replace all of our BIND servers >> with a PowerDNS infrastructure. >> >> BIND has been the backbone of the Internet, and so many of us are wary of >> replacing BIND, when in essence, BIND itself is not the issue, nor is it >> broken. >> >> Has anyone done any in house comparance of PowerDNS versus BIND-DLZ? >> Googling has led to some useful info but no useful side by side >> comparances that are not obviously partisan. >> >> I favor something like ProBIND2, that keeps the data in the DB, but does >> not >> tie the serving of the data, etc to anything other than BIND. >> >> Any success/horror stories from implementing BIND management solutions is >> very welcome. >> >> If anyone has any success/horror stories about PowerDNS, BIND-DLZ, or a >> system like ProBind2 or NetDB (from Stanford) to manage BIND and its >> configurations >> in a DB, I would be very interested in hearing them. :-) >> >> Thank you. >> >> Best Regards, >> Ross S. Dmochowski >> Sr. Linux Administrator >> IGN/Gamespy/Fox Interactive Media >> ross at ign.com >> >> > > > From michele at blacknight.ie Wed Feb 4 09:10:38 2009 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Wed, 4 Feb 2009 15:10:38 +0000 Subject: Database backed DNS Management Solutions In-Reply-To: <609FCB2B-0B00-4B49-9BC2-AF07B2451510@mimectl> References: <609FCB2B-0B00-4B49-9BC2-AF07B2451510@mimectl> Message-ID: <600060A7-D9F9-4D10-A304-5F9A17BD640C@blacknight.ie> > We developed our own PHP / MySQL system that holds all the records before writing out zonefiles and updates to BIND. We've been using it for several years and it works well :) Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From steven.crandell at gmail.com Wed Feb 4 15:36:10 2009 From: steven.crandell at gmail.com (Steven Crandell) Date: Wed, 4 Feb 2009 14:36:10 -0700 Subject: Database backed DNS Management Solutions In-Reply-To: <600060A7-D9F9-4D10-A304-5F9A17BD640C@blacknight.ie> References: <609FCB2B-0B00-4B49-9BC2-AF07B2451510@mimectl> <600060A7-D9F9-4D10-A304-5F9A17BD640C@blacknight.ie> Message-ID: <6fb190210902041336ma1909dbg2d42979bb9febae3@mail.gmail.com> I'm a long time BIND user and recent convert to PowerDNS. I considered BIND-DLZ briefly but found that I wasn't excited about the DB retro-fit on a piece of software that was previously very much meant to live in the world of flat files. My initial intent was to try PowerDNS first and then give BIND-DLZ a test drive also, but I never got around to BIND-DLZ given how well PowerDNS performed. My only beef with PDNS is the inability to use master-slave replication to hosts that are not listed as type NS. This is by design but it nevertheless got in my way. I've since just set all domains to use native replication (e.g. db backend repliciation, Postgres/Slony in this instance) and absolutely could not be happier with the results. The amount of time I spend managing DNS has been reduced to almost nothing given how easily I can script my large operations. Still it pays to be wise: Use transactions!! I've also been getting slightly better query response times with PDNS than I did with BIND for what it's worth. -s On Wed, Feb 4, 2009 at 8:10 AM, Michele Neylon :: Blacknight < michele at blacknight.ie> wrote: > >> > We developed our own PHP / MySQL system that holds all the records before > writing out zonefiles and updates to BIND. We've been using it for several > years and it works well :) > > > Mr Michele Neylon > Blacknight Solutions > Hosting & Colocation, Brand Protection > http://www.blacknight.com/ > http://blog.blacknight.com/ > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > UK: 0844 484 9361 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Fax. +353 (0) 1 4811 763 > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > > From jfbeam at gmail.com Wed Feb 4 16:44:20 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 04 Feb 2009 17:44:20 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <20090204012537.GB11448@hezmatt.org> Message-ID: On Tue, 03 Feb 2009 20:29:36 -0500, Skeeve Stevens wrote: > I agree... I'd love to know where they got that from... who even wrote > it? I see you've never done business with EDS. They've been using 1/8 for over a decade. Also, over the years, I've seen a number of universities and supercomputing facilities number nodes out of 1/8 -- however, those systems are never supposed to see the internet anyway, so they could technically number them however they want. Personally, I've used 1/8 in lab setups. --Ricky From sethm at rollernet.us Wed Feb 4 16:50:39 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 04 Feb 2009 14:50:39 -0800 Subject: Database backed DNS Management Solutions In-Reply-To: <6fb190210902041336ma1909dbg2d42979bb9febae3@mail.gmail.com> References: <609FCB2B-0B00-4B49-9BC2-AF07B2451510@mimectl> <600060A7-D9F9-4D10-A304-5F9A17BD640C@blacknight.ie> <6fb190210902041336ma1909dbg2d42979bb9febae3@mail.gmail.com> Message-ID: <498A1BBF.9080707@rollernet.us> Steven Crandell wrote: > I'm a long time BIND user and recent convert to PowerDNS. > I considered BIND-DLZ briefly but found that I wasn't excited about the DB > retro-fit on a piece of software that was previously very much meant to live > in the world of flat files. > My initial intent was to try PowerDNS first and then give BIND-DLZ a test > drive also, but I never got around to BIND-DLZ given how well PowerDNS > performed. > > My only beef with PDNS is the inability to use master-slave replication to > hosts that are not listed as type NS. > This is by design but it nevertheless got in my way. > I've since just set all domains to use native replication (e.g. db backend > repliciation, Postgres/Slony in this instance) and absolutely could not be > happier with the results. > > The amount of time I spend managing DNS has been reduced to almost nothing > given how easily I can script my large operations. > Still it pays to be wise: Use transactions!! > Always, always, *always* use a transaction-aware database with PowerDNS. That said, I too am a happy user of PowerDNS using native database replication. The recent January 27 release added a lot of good stuff. ~Seth From mansaxel at besserwisser.org Wed Feb 4 17:09:22 2009 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Thu, 05 Feb 2009 00:09:22 +0100 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <20090204012537.GB11448@hezmatt.org> Message-ID: <57ABB53237A084F35298AFBE@rasmus.kthnoc.net> --On onsdag, onsdag 4 feb 2009 17.44.20 -0500 Ricky Beam wrote: > On Tue, 03 Feb 2009 20:29:36 -0500, Skeeve Stevens > wrote: >> I agree... I'd love to know where they got that from... who even wrote >> it? > > I see you've never done business with EDS. They've been using 1/8 for > over a decade. Also, over the years, I've seen a number of universities > and supercomputing facilities number nodes out of 1/8 -- however, those > systems are never supposed to see the internet anyway, so they could > technically number them however they want. Personally, I've used 1/8 in > lab setups. Last time I built a supercomputer (as in a cluster of run-of-the-mill servers) RIPE gave us a /21 -- I wanted a /20 for the expected upgrade but was told I had to reapply. The compute nodes need to read files from AFS from CERN or another university, so NAT'ing them is so not an option. -- M?ns Nilsson M A C H I N A Sign my PETITION. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From scott at doc.net.au Wed Feb 4 17:56:44 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 4 Feb 2009 15:56:44 -0800 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> Message-ID: On Mon, Feb 2, 2009 at 9:30 PM, Anthony Roberts wrote: > It has been my experience that when you give someone a huge address space > to play with (eg 10/8), they start doing things like using bits in the > address as flags for things. Suddenly you find yourself using a prefix > that should enough for a decent sized country in a half-rack. Which is, of course, a core design philosophy for IPv6. Stateless autoconfig relies on the fact that each network will be allocated 2^64 address. On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore wrote: > Except the RIRs won't give you another /48 when you have only used one > trillion IP addresses. Of course they will! A /48 is only the equivalent of 65536 "networks" (each network being a /64). Presuming that ISPs allocate /64 networks to each connected subscriber, then a /48 is only 65k subscribers, or say around a maximum of 200k IP addresses in use at any one time (presuming no NAT and an average of 3-4 IP-based devices per subscriber) IPv4-style utilization ratios do make some sense under IPv6, but not at the address level - only at the network level. Scott. From patrick at ianai.net Wed Feb 4 18:02:56 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 4 Feb 2009 19:02:56 -0500 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> Message-ID: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> On Feb 4, 2009, at 6:56 PM, Scott Howard wrote: > On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore > wrote: > >> Except the RIRs won't give you another /48 when you have only used >> one >> trillion IP addresses. > > Of course they will! A /48 is only the equivalent of 65536 > "networks" (each > network being a /64). Presuming that ISPs allocate /64 networks to > each > connected subscriber, then a /48 is only 65k subscribers, or say > around a > maximum of 200k IP addresses in use at any one time (presuming no > NAT and an > average of 3-4 IP-based devices per subscriber) > > IPv4-style utilization ratios do make some sense under IPv6, but not > at the > address level - only at the network level. First, it was (mostly) a joke. Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64? -- TTFN, patrick From sethm at rollernet.us Wed Feb 4 18:08:13 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 04 Feb 2009 16:08:13 -0800 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> Message-ID: <498A2DED.5040601@rollernet.us> Patrick W. Gilmore wrote: > On Feb 4, 2009, at 6:56 PM, Scott Howard wrote: >> On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore >> wrote: >> >>> Except the RIRs won't give you another /48 when you have only used one >>> trillion IP addresses. >> >> Of course they will! A /48 is only the equivalent of 65536 "networks" >> (each >> network being a /64). Presuming that ISPs allocate /64 networks to each >> connected subscriber, then a /48 is only 65k subscribers, or say around a >> maximum of 200k IP addresses in use at any one time (presuming no NAT >> and an >> average of 3-4 IP-based devices per subscriber) >> >> IPv4-style utilization ratios do make some sense under IPv6, but not >> at the >> address level - only at the network level. > > First, it was (mostly) a joke. > > Second, where did you get 4 users per /64? Are you planning to hand > each cable modem a /64? > That was the generally accepted subnet practice last time I had a discussion about it on the ipv6-ops list. I'm not an ISP, but I have a /48 and each subnet is a /64. Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.) ~Seth From patrick at ianai.net Wed Feb 4 18:16:36 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 4 Feb 2009 19:16:36 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A2DED.5040601@rollernet.us> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: On Feb 4, 2009, at 7:08 PM, Seth Mattinen wrote: > Patrick W. Gilmore wrote: >> >> Second, where did you get 4 users per /64? Are you planning to hand >> each cable modem a /64? > > > That was the generally accepted subnet practice last time I had a > discussion about it on the ipv6-ops list. I'm not an ISP, but I have a > /48 and each subnet is a /64. Some devices will refuse to work if you > subnet smaller than a /64. (Yes, poorly designed, etc.) I Am Not An ISP either. :) I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem. And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $@#%'ing way we will EVER use THAT many...." -- TTFN, patrick From mksmith at adhost.com Wed Feb 4 18:16:46 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 4 Feb 2009 16:16:46 -0800 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> Message-ID: <17838240D9A5544AAA5FF95F8D520316057BF331@ad-exh01.adhost.lan> > > IPv4-style utilization ratios do make some sense under IPv6, but not > > at the > > address level - only at the network level. > > First, it was (mostly) a joke. > > Second, where did you get 4 users per /64? Are you planning to hand > each cable modem a /64? > At the least. Some would say a /56 is more appropriate. So, one /64 for your desktop and one /64 for your open wireless. :-) Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available URL: From hcb at netcases.net Wed Feb 4 18:38:34 2009 From: hcb at netcases.net (Howard C. Berkowitz) Date: Wed, 4 Feb 2009 19:38:34 -0500 (EST) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: <3313.76.118.14.219.1233794314.squirrel@webmail8.pair.com> Patrick W. Gilmore wrote: > On Feb 4, 2009, at 7:08 PM, Seth Mattinen wrote: >> Patrick W. Gilmore wrote: >>> > >>> Second, where did you get 4 users per /64? Are you planning to hand >>> each cable modem a /64? >> >> >> That was the generally accepted subnet practice last time I had a >> discussion about it on the ipv6-ops list. I'm not an ISP, but I have a >> /48 and each subnet is a /64. Some devices will refuse to work if you >> subnet smaller than a /64. (Yes, poorly designed, etc.) > > I Am Not An ISP either. :) > > I guess I was thinking about v4 modems which do not get a subnet, just > an IP address. If we really are handing out a /64 to each DSL & Cable > modem, then we may very well be recreating the same problem. > > And before anyone says "there are 281474976710656 /48s!", just > remember your history. I was not there when v4 was spec'ed out, but I > bet when someone said "four-point-two BILLION addresses", someone else > said "no $@#%'ing way we will EVER use THAT many...." > Ah, but RFC 760, before 791, did assume "more than 253 networks? Nahhh..." From mmc at internode.com.au Wed Feb 4 18:38:44 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 11:08:44 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: <498A3514.1050608@internode.com.au> Patrick W. Gilmore wrote: > > And before anyone says "there are 281474976710656 /48s!", just > remember your history. I was not there when v4 was spec'ed out, but I > bet when someone said "four-point-two BILLION addresses", someone else > said "no $@#%'ing way we will EVER use THAT many...." Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. (Think of the processing overhead of all the DSL/Cable customers going up and down). This is going to be far more of an issue and drive network design than a minor blow out in the v6 routing table. As Neil Finn of Split Enz fame once wrote: History never repeats, I tell myself before I go to sleep. Followed on the same album by a song called "My Mistake". MMC (Who's trying to implement v6 native for DSL customers but finds that the world doesn't have useable solutions yet for DSL CPE, BRAS, IPv6 allocation etc and doesn't look like it will for a while). -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From nanog at arbitraryconstant.com Wed Feb 4 18:46:20 2009 From: nanog at arbitraryconstant.com (Anthony Roberts) Date: Wed, 04 Feb 2009 17:46:20 -0700 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> Message-ID: <09aaa44d7e01409c185370846e9bc801@smtp.arbitraryconstant.com> On Wed, 4 Feb 2009 15:56:44 -0800, Scott Howard wrote: > On Mon, Feb 2, 2009 at 9:30 PM, > Anthony Roberts wrote: > >> It has been my experience that when you give someone a huge address space >> to play with (eg 10/8), they start doing things like using bits in the >> address as flags for things. Suddenly you find yourself using a prefix >> that should enough for a decent sized country in a half-rack. > > Which is, of course, a core design philosophy for IPv6. Stateless > autoconfig > relies on the fact that each network will be allocated 2^64 address. I'm actually pretty happy about /64's, they take away all the hand-wringing over how big a network should be, and they make manually configured server addresses easier to remember through the use of big regions of 0s. I was thinking more about wasting prefix bits. -Anthony From randy at psg.com Wed Feb 4 18:29:57 2009 From: randy at psg.com (Randy Bush) Date: Thu, 05 Feb 2009 09:29:57 +0900 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <20090204012537.GB11448@hezmatt.org> Message-ID: > I see you've never done business with EDS. They've been using 1/8 for > over a decade. Also, over the years, I've seen a number of universities > and supercomputing facilities number nodes out of 1/8 -- however, those > systems are never supposed to see the internet anyway, so they could > technically number them however they want. Personally, I've used 1/8 in > lab setups. brilliant! i think all my competitors should do that. randy From Mark_Andrews at isc.org Wed Feb 4 18:57:18 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 05 Feb 2009 11:57:18 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: Your message of "Thu, 05 Feb 2009 11:08:44 +1030." <498A3514.1050608@internode.com.au> Message-ID: <200902050057.n150vJ2k074863@drugs.dv.isc.org> In message <498A3514.1050608 at internode.com.au>, Matthew Moyle-Croft writes: > Patrick W. Gilmore wrote: > > > > And before anyone says "there are 281474976710656 /48s!", just > > remember your history. I was not there when v4 was spec'ed out, but I > > bet when someone said "four-point-two BILLION addresses", someone else > > said "no $@#%'ing way we will EVER use THAT many...." > Let's face it - the current v6 assignment rules are to solve a 1990s set > of problems. A /64 isn't needed now that we have DHCP(v6). Setting > the idea in people's heads that a /64 IS going to be their own > statically is insane and will blow out provider's own routing tables > more than is rational. (Think of the processing overhead of all the > DSL/Cable customers going up and down). This is going to be far more of > an issue and drive network design than a minor blow out in the v6 > routing table. Assign the prefixes using PD and use aggregate routes out side of the pop. IPv6 nodes are designed to be renumbered. Use the technology. Stop thinking IPv4 and start thinking IPv6. IPv6 is not just IPv4 with bigger addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From nanog at arbitraryconstant.com Wed Feb 4 19:05:18 2009 From: nanog at arbitraryconstant.com (Anthony Roberts) Date: Wed, 04 Feb 2009 18:05:18 -0700 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A3514.1050608@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> Message-ID: <43f6470ae1fdefb1eea7ed4485189272@smtp.arbitraryconstant.com> On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft wrote: > > Let's face it - the current v6 assignment rules are to solve a 1990s set > of problems. A /64 isn't needed now that we have DHCP(v6). It's needed to prevent people from NATing in v6, as they'll still want their stuff behind a firewall, and some of them will want subnets. > Setting the idea in people's heads that a /64 IS going to be their own > statically is insane and will blow out provider's own routing tables > more than is rational. No larger than their ARP tables are now. From mmc at internode.com.au Wed Feb 4 19:11:01 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 11:41:01 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> Message-ID: <498A3CA5.6060801@internode.com.au> Anthony Roberts wrote: > On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft > wrote: > >> Let's face it - the current v6 assignment rules are to solve a 1990s set >> of problems. A /64 isn't needed now that we have DHCP(v6). >> > > It's needed to prevent people from NATing in v6, as they'll still want > their stuff behind a firewall, and some of them will want subnets. > Why do we want to prevent people using NAT? If people choose to use NAT, then I have no issue with that. This anti-NAT zealotism is tiring and misplaced. > >> Setting the idea in people's heads that a /64 IS going to be their own >> statically is insane and will blow out provider's own routing tables >> more than is rational. >> > > No larger than their ARP tables are now. > And ARP tables are propogated around networks? No, they're local to a router. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From mmc at internode.com.au Wed Feb 4 19:20:30 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 11:50:30 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <200902050057.n150vJ2k074863@drugs.dv.isc.org> References: <200902050057.n150vJ2k074863@drugs.dv.isc.org> Message-ID: <498A3EDE.60008@internode.com.au> Mark Andrews wrote: > > Assign the prefixes using PD and use aggregate routes out side of the pop. > IPv6 nodes are designed to be renumbered. Use the technology. Stop thinking > IPv4 and start thinking IPv6. IPv6 is not just IPv4 with bigger addresses. > > Currently with v4 I have one (majority) of customers where they have dynamic addresses. For those I'm happy to use PD - but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. This is my fear, is NOT being able to use PD for the "residential grade" customers. Having to provide static allocations is a problem if I have multiple POPs in a geographic region as I can't summarise and get the redundancy I want. (If I commit to a customer they have a static range then I can't easily change it on them - esp if they've done things like used the addresses statically in DNS etc as our customers are want to do). Has anyone out there actually done an implentation, across DSL of PD? If you have PLEASE let me know on list/off list/by dead letter drop in a park. Especially interested in CPE etc. Regards, Matthew > Mark > -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From nanog at arbitraryconstant.com Wed Feb 4 19:22:46 2009 From: nanog at arbitraryconstant.com (Anthony Roberts) Date: Wed, 04 Feb 2009 18:22:46 -0700 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A3CA5.6060801@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> Message-ID: <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> On Thu, 05 Feb 2009 11:41:01 +1030, Matthew Moyle-Croft wrote: > And ARP tables are propogated around networks? No, they're local to a > router. I don't think there's any need for the ISP's routers to advertise all the prefixes they delegate. They'll advertise the /48 or whatever it is, and then delegate chunks out of that. From nonobvious at gmail.com Wed Feb 4 19:24:17 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 4 Feb 2009 17:24:17 -0800 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <4988F2C4.3090100@ibctech.ca> References: <497D1764.4050709@ibctech.ca> <4988F063.1030201@ibctech.ca> <4988F2C4.3090100@ibctech.ca> Message-ID: <18a5e7cb0902041724i2e9a11fdw7897d7d85c889337@mail.gmail.com> On Tue, Feb 3, 2009 at 5:43 PM, Steve Bertrand wrote: > What I was hoping for (even though I'm testing something that I know > won't work) is that I can break something so I could push v4 traffic > over a v6-only core. > > Is there _any_ way to do this (other than NAT/tunnel etc)? If you can push v4 over it (other than through a NAT/tunnel/etc.), then it's not a v6-only core :-) The real question is whether you're going to route natively in v4, or do a v4-in-v6 tunnel of some sort, or a v4-in-Layer2-in-v6 tunnel of some sort, or do NAT, or use MPLS as a Layer 2ish core. If you're doing MPLS, you'll need to figure out if you can run _it_ with purely v6 gear supporting it, or whether you'll need to run v4 to make all of your MPLS vendors happy, but that doesn't need to be publicly routable v4 carrying the entire Internet's routing tables on it; you can leave the Internet inside a large MPLS VPN if you want. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From mmc at internode.com.au Wed Feb 4 19:28:33 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 11:58:33 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> Message-ID: <498A40C1.8060702@internode.com.au> Anthony Roberts wrote: > > > I don't think there's any need for the ISP's routers to advertise all the > prefixes they delegate. They'll advertise the /48 or whatever it is, and > then delegate chunks out of that. > My apologies for not being clear: As I posted just before in reply to MarkA - I'm hoping that for the MAJORITY of customers that I can use PD and dynamic /64s (or whatever) local to a BRAS. My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that. I'm still not convinced though that, given DHCPv6 is going to be a reality for DNS assignment etc, that stateless autoconfig is needed and thus /64 doesn't have to be the smallest we assign. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From Mark_Andrews at isc.org Wed Feb 4 19:32:33 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 05 Feb 2009 12:32:33 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: Your message of "Thu, 05 Feb 2009 11:41:01 +1030." <498A3CA5.6060801@internode.com.au> Message-ID: <200902050132.n151WXgX075542@drugs.dv.isc.org> In message <498A3CA5.6060801 at internode.com.au>, Matthew Moyle-Croft writes: > Anthony Roberts wrote: > > On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft > > wrote: > > > >> Let's face it - the current v6 assignment rules are to solve a 1990s set > >> of problems. A /64 isn't needed now that we have DHCP(v6). > >> > > > > It's needed to prevent people from NATing in v6, as they'll still want > > their stuff behind a firewall, and some of them will want subnets. > > > Why do we want to prevent people using NAT? If people choose to use > NAT, then I have no issue with that. > > This anti-NAT zealotism is tiring and misplaced. NAT's break lots of things and increase the development costs of every piece of network based software being written. If we could get a true accounting of the extra cost imposed by NAT's I would say it would be in the trillions of dollars. NAT's are a necessary evil in IPv4. If every node that currently communicates to something the other side of a NAT was to have a global address then we would have already run out of IPv4 addresses. NAT's are not a necessary evil in IPv6. Just stop being scared to renumber. Addresses are not forever and when you design for that renumbering get easier and easier. For everything else there are alternate solutions. > >> Setting the idea in people's heads that a /64 IS going to be their own > >> statically is insane and will blow out provider's own routing tables > >> more than is rational. > >> > > > > No larger than their ARP tables are now. > > > And ARP tables are propogated around networks? No, they're local to a > router. > > MMC > > -- > Matthew Moyle-Croft - Internode/Agile - Networks > Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia > Email: mmc at internode.com.au Web: http://www.on.net > Direct: +61-8-8228-2909 Mobile: +61-419-900-366 > Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From sethm at rollernet.us Wed Feb 4 19:33:12 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 04 Feb 2009 17:33:12 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A40C1.8060702@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> Message-ID: <498A41D8.3000109@rollernet.us> Matthew Moyle-Croft wrote: > > > Anthony Roberts wrote: >> >> >> I don't think there's any need for the ISP's routers to advertise all the >> prefixes they delegate. They'll advertise the /48 or whatever it is, and >> then delegate chunks out of that. >> > My apologies for not being clear: > > As I posted just before in reply to MarkA - I'm hoping that for the > MAJORITY of customers that I can use PD and dynamic /64s (or whatever) > local to a BRAS. > My FEAR is that people ("customers") are going to start assuming that v6 > means their own static allocation (quite a number are assuming this). > This means that I have a problem with routing table size etc if I have > to implement that. > Well, it is static, but like most static IP services offerd by an ISP, if you leave you can't take your addresses with you. Even with DSL from AT&T if you move locations you get a different subnet. ~Seth From sethm at rollernet.us Wed Feb 4 19:35:08 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 04 Feb 2009 17:35:08 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <200902050132.n151WXgX075542@drugs.dv.isc.org> References: <200902050132.n151WXgX075542@drugs.dv.isc.org> Message-ID: <498A424C.7080400@rollernet.us> Mark Andrews wrote: > In message <498A3CA5.6060801 at internode.com.au>, Matthew Moyle-Croft writes: >> Anthony Roberts wrote: >>> On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft >>> wrote: >>> >>>> Let's face it - the current v6 assignment rules are to solve a 1990s set >>>> of problems. A /64 isn't needed now that we have DHCP(v6). >>>> >>> It's needed to prevent people from NATing in v6, as they'll still want >>> their stuff behind a firewall, and some of them will want subnets. >>> >> Why do we want to prevent people using NAT? If people choose to use >> NAT, then I have no issue with that. >> >> This anti-NAT zealotism is tiring and misplaced. > > NAT's break lots of things and increase the development > costs of every piece of network based software being written. > > If we could get a true accounting of the extra cost imposed > by NAT's I would say it would be in the trillions of dollars. > > NAT's are a necessary evil in IPv4. If every node that > currently communicates to something the other side of a NAT > was to have a global address then we would have already run > out of IPv4 addresses. > > NAT's are not a necessary evil in IPv6. Just stop being > scared to renumber. Addresses are not forever and when you > design for that renumbering get easier and easier. > > For everything else there are alternate solutions. > Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall. A *lot* of these problems we face are conceptual rather than technological. ~Seth From james.cutler at consultant.com Wed Feb 4 19:35:15 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Wed, 4 Feb 2009 20:35:15 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <20090204012537.GB11448@hezmatt.org> Message-ID: Clarification here: 1/8 was never on the EDS backbone. Was only used locally in one site, as far as I can determine. On Feb 4, 2009, at 7:29 PM, Randy Bush wrote: >> I see you've never done business with EDS. They've been using 1/8 >> for >> over a decade. Also, over the years, I've seen a number of >> universities >> and supercomputing facilities number nodes out of 1/8 -- however, >> those >> systems are never supposed to see the internet anyway, so they could >> technically number them however they want. Personally, I've used >> 1/8 in >> lab setups. > > brilliant! i think all my competitors should do that. > > randy > James R. Cutler james.cutler at consultant.com From scott at doc.net.au Wed Feb 4 19:35:21 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 4 Feb 2009 17:35:21 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore wrote: > I guess I was thinking about v4 modems which do not get a subnet, just an > IP address. If we really are handing out a /64 to each DSL & Cable modem, > then we may very well be recreating the same problem. v4 just gets a single IP address, which is why we need NAT, and apparently NAT is evil. To some extent the /64 can be though of as "just an IP" from the ISP perspective (in the same sense that an IPv4 IP is just a /32 "network"), which has the ability for the CPE to then somehow split it out between multiple hosts - probably using autoconfig (in the same way with IPv4 it's "split up" by the port with NAT). What happens when a customer wants to run multiple networks is something I haven't seen answered yet - with NAT it's easy, but as I said, NAT is apparently evil... On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft wrote: > but my point was that people are starting to assume that v6 WILL mean > static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Scott. From nanog at daork.net Wed Feb 4 19:38:29 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 5 Feb 2009 14:38:29 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A40C1.8060702@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> Message-ID: <1FEBAAE8-D2E0-44F0-A50B-5E2AD1BD657C@daork.net> On 5/02/2009, at 2:28 PM, Matthew Moyle-Croft wrote: > Anthony Roberts wrote: >> >> >> I don't think there's any need for the ISP's routers to advertise >> all the >> prefixes they delegate. They'll advertise the /48 or whatever it >> is, and >> then delegate chunks out of that. >> > My apologies for not being clear: > > As I posted just before in reply to MarkA - I'm hoping that for the > MAJORITY of customers that I can use PD and dynamic /64s (or > whatever) local to a BRAS. > My FEAR is that people ("customers") are going to start assuming > that v6 means their own static allocation (quite a number are > assuming this). This means that I have a problem with routing > table size etc if I have to implement that. In my opinion, if they want static, they get business grade services, and get a /48. Or maybe a /56 over DSL perhaps. And they pay more for it. Otherwise they get PD like everybody else. The ability is there *now* for you to manage this expectation and say to customers that they are dynamic. Exploit it. > I'm still not convinced though that, given DHCPv6 is going to be a > reality for DNS assignment etc, that stateless autoconfig is needed > and thus /64 doesn't have to be the smallest we assign. Dynamic PD requires SLAAC, unless your customers have say 30s DHCPv6 lease times on their DHCPv6 servers. DSL reconnects, gets new IPv6 prefix, sends RA messages internally, hosts renumber and mark the existing prefix as deprecated until it expires. The alternative is waiting for hosts to do a DHCPv6 query to get a new address. That is sub-optimal. -- Nathan Ward From nanog at daork.net Wed Feb 4 19:39:35 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 5 Feb 2009 14:39:35 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A424C.7080400@rollernet.us> References: <200902050132.n151WXgX075542@drugs.dv.isc.org> <498A424C.7080400@rollernet.us> Message-ID: <8B65D2ED-A72E-41DE-A590-834A49B00093@daork.net> On 5/02/2009, at 2:35 PM, Seth Mattinen wrote: > Far too many people see NAT as synonymous with a firewall so they > think > if you take away their NAT you're taking away the security of a > firewall. > > A *lot* of these problems we face are conceptual rather than > technological. For more, refer to the 69,000 other NANOG posts on the topic. -- Nathan Ward From mmc at internode.com.au Wed Feb 4 19:39:39 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 12:09:39 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A41D8.3000109@rollernet.us> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> <498A41D8.3000109@rollernet.us> Message-ID: <498A435B.3080603@internode.com.au> Seth Mattinen wrote: > Well, it is static, but like most static IP services offerd by an ISP, > if you leave you can't take your addresses with you. Even with DSL from > AT&T if you move locations you get a different subnet. > > The issue is multiple POPs in a geographic region where customers could connect to either- if you have those and want them to work in adversity then you've got a problem as you need to allow the static addresses to propogate around. When that number is small then it's not a problem, but when you've got it large scale then you have a routing problem. This is my fear. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From Mark_Andrews at isc.org Wed Feb 4 19:40:25 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 05 Feb 2009 12:40:25 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: Your message of "Thu, 05 Feb 2009 11:58:33 +1030." <498A40C1.8060702@internode.com.au> Message-ID: <200902050140.n151eP5e075695@drugs.dv.isc.org> In message <498A40C1.8060702 at internode.com.au>, Matthew Moyle-Croft writes: > > > Anthony Roberts wrote: > > > > > > I don't think there's any need for the ISP's routers to advertise all the > > prefixes they delegate. They'll advertise the /48 or whatever it is, and > > then delegate chunks out of that. > > > My apologies for not being clear: > > As I posted just before in reply to MarkA - I'm hoping that for the > MAJORITY of customers that I can use PD and dynamic /64s (or whatever) > local to a BRAS. > > My FEAR is that people ("customers") are going to start assuming that v6 > means their own static allocation (quite a number are assuming this). > This means that I have a problem with routing table size etc if I have > to implement that. > > I'm still not convinced though that, given DHCPv6 is going to be a > reality for DNS assignment etc, that stateless autoconfig is needed and > thus /64 doesn't have to be the smallest we assign. All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly. The only difference is the mechanisms used to assign the leases and the probability that you may have to renumber when the lease falls due. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From surfer at mauigateway.com Wed Feb 4 19:41:58 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 4 Feb 2009 17:41:58 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] Message-ID: <20090204174158.1FED4B25@resin17.mta.everyone.net> ------ mmc at internode.com.au wrote: -------- From: Matthew Moyle-Croft Has anyone out there actually done an implentation, across DSL of PD? If you have PLEASE let me know on list/off list/by dead letter drop in a park. Especially interested in CPE etc. ----------------------------------------------- Please state on list. Many of would like to learn from your experiences. scott From trejrco at gmail.com Wed Feb 4 19:45:22 2009 From: trejrco at gmail.com (TJ) Date: Wed, 4 Feb 2009 20:45:22 -0500 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> Message-ID: <00f401c98733$69a606a0$3cf213e0$@com> >> On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore >> wrote: >> >>> Except the RIRs won't give you another /48 when you have only used >>> one trillion IP addresses. >> >> Of course they will! A /48 is only the equivalent of 65536 "networks" >> (each network being a /64). Presuming that ISPs allocate /64 networks >> to each connected subscriber, then a /48 is only 65k subscribers, or >> say around a maximum of 200k IP addresses in use at any one time >> (presuming no NAT and an average of 3-4 IP-based devices per >> subscriber) >> >> IPv4-style utilization ratios do make some sense under IPv6, but not >> at the address level - only at the network level. > >First, it was (mostly) a joke. > >Second, where did you get 4 users per /64? Are you planning to hand each >cable modem a /64? No, we should hand each home a /56 (or perhaps a /48, for the purists out there) - allowing for multiple segments (aka subnet, aka links, etc.). Note - the actual number of hosts is irrelevant; the 64 bits on the host side of the address are not meant to encourage 18BB hosts/segment. Oh, and utilization should be based on /56s anyway. /TJ From trejrco at gmail.com Wed Feb 4 19:48:57 2009 From: trejrco at gmail.com (TJ) Date: Wed, 4 Feb 2009 20:48:57 -0500 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <498A2DED.5040601@rollernet.us> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: <00f501c98733$e9f291c0$bdd7b540$@com> >Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.) Actually, no - not poorly designed. The spec says it must be a /64 (excluding those starting with 000 binary) so that is what devices (rightfully) expect. Ref: http://tools.ietf.org/html/rfc4291#section-2.5.1 /TJ From Mark_Andrews at isc.org Wed Feb 4 19:51:10 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 05 Feb 2009 12:51:10 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: Your message of "Wed, 04 Feb 2009 17:35:21 -0800." Message-ID: <200902050151.n151pA7o077207@drugs.dv.isc.org> In message , Scott Howard writes: > On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore wrote: > > > I guess I was thinking about v4 modems which do not get a subnet, just an > > IP address. If we really are handing out a /64 to each DSL & Cable modem, > > then we may very well be recreating the same problem. > > > v4 just gets a single IP address, which is why we need NAT, and apparently > NAT is evil. > > To some extent the /64 can be though of as "just an IP" from the ISP > perspective (in the same sense that an IPv4 IP is just a /32 "network"), > which has the ability for the CPE to then somehow split it out between > multiple hosts - probably using autoconfig (in the same way with IPv4 it's > "split up" by the port with NAT). You hand out multiple /64's. As many as the client requests up to a /56 or /48 depending apon which break point you choose. The address space is assigned to ISP's on the presumption that you will be handing out the equivalent of /56's or /48's worth of address space to each customer. > What happens when a customer wants to run multiple networks is something I > haven't seen answered yet - with NAT it's easy, but as I said, NAT is > apparently evil... > > > On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft wro > te: > > > but my point was that people are starting to assume that v6 WILL mean > > static allocations for all customers. > > > By design IPv6 should mean _less_ static allocations than IPv4 - in the > event that a client disconnects/reconnects and gets a new /64 then their > network *should* automatically handle that fact, with all clients > automagically renumbering themselves to the new /64, updating DNS, etc. > Local communications won't be impacted as they should be using the > link-local address. > > The bit that isn't clear at the moment is if (and how well) that will > actually work in practice. And that brings us back to the good old catch-22 > of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE > not supporting it because ISP don't... > > Scott. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From mmc at internode.com.au Wed Feb 4 19:52:43 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 12:22:43 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: <498A466B.70507@internode.com.au> Scott Howard wrote: > On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore wrote: > > > On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft wrote: > > >> but my point was that people are starting to assume that v6 WILL mean >> static allocations for all customers. >> > > > By design IPv6 should mean _less_ static allocations than IPv4 - in the > event that a client disconnects/reconnects and gets a new /64 then their > network *should* automatically handle that fact, with all clients > automagically renumbering themselves to the new /64, updating DNS, etc. > Local communications won't be impacted as they should be using the > link-local address. > _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). > The bit that isn't clear at the moment is if (and how well) that will > actually work in practice. And that brings us back to the good old catch-22 > of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE > not supporting it because ISP don't... > Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? MMC > Scott. > -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From nanog at daork.net Wed Feb 4 19:56:30 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 5 Feb 2009 14:56:30 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: <8AE12BE5-4E5C-42DF-8B61-5221E8507C71@daork.net> On 5/02/2009, at 2:35 PM, Scott Howard wrote: > What happens when a customer wants to run multiple networks is > something I > haven't seen answered yet - with NAT it's easy, but as I said, NAT is > apparently evil... You give them more than a /64. RFC4291 says that it should be a /48, but people seem to be keen on / 56s now. /60s are even ok. They key here is that is is divisible by 4, which leaves full hex digits for the customer to twiddle. Somewhere (free.fr?) are doing / 61, which is a bit tough for people that aren't so technical. Here in NZ, users typically purchase their own ADSL CPE, and that runs PPPoATM over ADSL, and does IPv4 NAT and so on. What is also common, is people buy a "wireless router" and plug it in to the back of their ADSL router. They now have two layers of NAT between wireless hosts and the Internet. I looked at a packet trace of outgoing packets from an ISP - 17% of outgoing packets were from behind double NAT like this (TTL was 62 or 126, as opposed to 63 or 127). For this topology to work in IPv6, multiple levels of PD are required, or users can no longer do this sort of plug-and-pray networking. Fun fun. Personally, I think we should have PD forwarding - ie. a router can forward PD requests from routers behind it up to the ISP, and the ISP can dish out another /64. It means there are more routes in that particular router at the ISP, but it means you don't have to worry about how much address space to give to each customer - if they need more they ask for it automatically. -- Nathan Ward From trejrco at gmail.com Wed Feb 4 19:56:42 2009 From: trejrco at gmail.com (TJ) Date: Wed, 4 Feb 2009 20:56:42 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A3514.1050608@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> Message-ID: <00fc01c98734$fee046d0$fca0d470$@com> >Let's face it - the current v6 assignment rules are to solve a 1990s set >of problems. Perhaps, time moves ever forward. >A /64 isn't needed now that we have DHCP(v6). Setting >the idea in people's heads that a /64 IS going to be their own statically is >insane and will blow out provider's own routing tables more than is >rational. (Think of the processing overhead of all the DSL/Cable customers >going up and down). This is going to be far more of an issue and drive >network design than a minor blow out in the v6 routing table. However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable. Also - does DHCPv6 currently have an option for prefix length? Just asking. WRT /64s (or really, /56s and /48s being assigned to clients) - note that these are NOT static assignments permanently belonging to the client. They are hopefully dynamic, hopefully via DHCPv6-PD (hopefully available/supported by then) ... similar to the single public IPv4 address most of us dynamically get @home today. AND, how does having a route for a /56 impact my routing table more than having a route for a /xx (something longer)?? It does mean the ISP needs a larger initial allocation, but still just one route ... /TJ From sethm at rollernet.us Wed Feb 4 20:00:38 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 04 Feb 2009 18:00:38 -0800 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <00f501c98733$e9f291c0$bdd7b540$@com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <00f501c98733$e9f291c0$bdd7b540$@com> Message-ID: <498A4846.8050907@rollernet.us> TJ wrote: >> Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.) > > Actually, no - not poorly designed. The spec says it must be a /64 (excluding those starting with 000 binary) so that is what devices (rightfully) expect. Ref: http://tools.ietf.org/html/rfc4291#section-2.5.1 > I was just trying to head off the flood of "poorly designed" comments last time I said such a thing on a different list. ;) I find /64 convenient because it ends on a nice boundary out of my /48 and for my purposes it's more than enough space. The only annoyance I've come across was my Cisco devices will only accept an EUI-64 address as a host address in an ACL. Not a big deal though. ~Seth From trejrco at gmail.com Wed Feb 4 20:04:27 2009 From: trejrco at gmail.com (TJ) Date: Wed, 4 Feb 2009 21:04:27 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A40C1.8060702@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> Message-ID: <010d01c98736$1436f6e0$3ca4e4a0$@com> >My FEAR is that people ("customers") are going to start assuming that v6 >means their own static allocation (quite a number are assuming this). >This means that I have a problem with routing table size etc if I have to >implement that. Then work with them to break them of this dis-illusion. >I'm still not convinced though that, given DHCPv6 is going to be a reality >for DNS assignment etc, that stateless autoconfig is needed and thus /64 >doesn't have to be the smallest we assign. Yes and no. You sound like you are of the belief that SLAAC is bad / deficient - while it may not be perfect, some are big fans of its ease of use ATLEAST in certain deployment models. From mmc at internode.com.au Wed Feb 4 20:09:56 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 12:39:56 +1030 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <00f401c98733$69a606a0$3cf213e0$@com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <00f401c98733$69a606a0$3cf213e0$@com> Message-ID: <498A4A74.6030703@internode.com.au> TJ wrote: > No, we should hand each home a /56 (or perhaps a /48, for the purists out > there) - allowing for multiple segments (aka subnet, aka links, etc.). If there are, say, 250-500 million broadband services in the world (probably more) then, if every ISP followed best practise for IPv6 address allocation, (sparse, bits for infrastructure, whatever etc) then what percentage of the space do we have left if we hand out /56 or /48s?). Taking into account the space already carved off for link local, private addressing, US Military etc. Has anyone done some analysis of what this might look like? Especially with growth etc. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From bicknell at ufp.org Wed Feb 4 20:19:07 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 4 Feb 2009 21:19:07 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A40C1.8060702@internode.com.au> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> Message-ID: <20090205021907.GA74285@ussenterprise.ufp.org> In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew Moyle-Croft wrote: > My FEAR is that people ("customers") are going to start assuming that v6 > means their own static allocation (quite a number are assuming this). > This means that I have a problem with routing table size etc if I have > to implement that. Customers don't want static addresses. They want DNS that works, with their own domain names, forward and reverse. They want renumbering events to be infrequent, and announced in advance. They want the box the cable/dsl/fios provider to actually work, that is be able to do really simple stuff without having to buy another stupid box to put behind it. None of these require static, and in fact I'd think it would be easier to get it right than it would be to do statics for most providers. But, I must be wrong, since the only solution virtually every provider offers is to "move up" to "a static IP". -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jfbeam at gmail.com Wed Feb 4 20:19:28 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 04 Feb 2009 21:19:28 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <49871828.5020908@protected-networks.net> <002201c98550$c50a1520$4f1e3f60$@com> <20090204012537.GB11448@hezmatt.org> Message-ID: On Wed, 04 Feb 2009 20:35:15 -0500, James R. Cutler wrote: > Clarification here: > > 1/8 was never on the EDS backbone. Was only used locally in one site, > as far as I can determine. They might have done that for other customers as well. (to avoid 10/8 collisions.) Personally, I'd think if they were going to NAT at the edge, they'd only set it up for the machines we were supposed to use, instead, we could see, well, a lot more than we should have. --Ricky From mmc at internode.com.au Wed Feb 4 20:22:54 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 12:52:54 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <00fc01c98734$fee046d0$fca0d470$@com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <00fc01c98734$fee046d0$fca0d470$@com> Message-ID: <498A4D7E.5050708@internode.com.au> TJ wrote: > However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable. > Also - does DHCPv6 currently have an option for prefix length? Just asking. > I'm under no allusion that a /64 is going to be optional - it's really too late which is sad. I think people have just latched onto it and now accept it and defend it without thinking about "is this still the answer?". Just because it's in an RFC doesn't mean it's still the right answer in a changing world. > WRT /64s (or really, /56s and /48s being assigned to clients) - note that > these are NOT static assignments permanently belonging to the client. They > are hopefully dynamic, hopefully via DHCPv6-PD (hopefully > available/supported by then) ... similar to the single public IPv4 address > most of us dynamically get @home today. Yep - that's what I'm hoping (as I've said and clarified). But I think the reality is that in the provider world, no matter what people here say, customer demand for an unchanging IPv6 range will increase not decrease - driving up provider routing size and complexity. -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From marquis at roble.com Wed Feb 4 21:05:22 2009 From: marquis at roble.com (Roger Marquis) Date: Wed, 4 Feb 2009 19:05:22 -0800 (PST) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: <20090205030522.13D152B21F3@mx5.roble.com> Mark Andrews wrote: > All IPv6 address assignments are leases. Whether you get > the address from a RIR, LIR or ISP. The lease may not be > renewed when it next falls due. You may get assigned a > different set of addresses at that point. You should plan > accordingly. Exactly the problem, and the reason A) IPv6 is not and will not be a viable option any time soon (soon being before the publication of an IPv6 NAT RFC), and B) why network providers (and other parties who stand to gain financially) are firmly against IPv6 NAT. > If we could get a true accounting of the extra cost imposed > by NAT's I would say it would be in the trillions of dollars. This is exactly the sort of hyperbole, like RFC4864's proposing that application-layer proxies are a viable substitute for NAT, that discredits IPv6 proponents. Those who remember the financial industry's push for SET, a failed encryption technology, will be struck by the similarities in technical vs rhetorical arguments. Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network engineers will be interested in the rational behind statements like: * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what it saves consumers, ILECs, or ISPs?) * NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It isn't much different than it is now. (say again?) * NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?) * NAT disadvantage #4: It requires more renumbering to join conflicting RFC1918 subnets than would IPv6 to change ISPs. (got stats?) * NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage) OTOH, the claimed advantages of NAT do seem to hold water somewhat better: * NAT advantage #1: it protects consumers from vendor (network provider) lock-in. * NAT advantage #2: it protects consumers from add-on fees for addresses space. (ISPs and ARIN, APNIC, ...) * NAT advantage #3: it prevents upstreams from limiting consumers' internal address space. (will anyone need more than a /48, to be asked in 2018) * NAT advantage #4: it requires new (and old) protocols to adhere to the ISO seven layer model. * NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic. IMHO, Roger Marquis From trejrco at gmail.com Wed Feb 4 21:17:29 2009 From: trejrco at gmail.com (TJ) Date: Wed, 4 Feb 2009 22:17:29 -0500 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <498A4A74.6030703@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <00f401c98733$69a606a0$3cf213e0$@com> <498A4A74.6030703@internode.com.au> Message-ID: <013301c98740$49f66130$dde32390$@com> >Has anyone done some analysis of what this might look like? Especially with growth etc. Sure, probably lots of people lots of times. Off the top of my head, using some current/common allocations sizes: Current "Global Unicast" space --> 2000::/3 An "average" RIR --> /12 an "average" ISP --> /32 an average enterprise --> /48 an average home user --> /56 So, "the current IPv6 world" (2000::/3) can support 512 standard RIR sized allocations. Each standard RIR can support 1M standard ISPs. Each standard ISP can support 64K enterprises or 16M standard home-users, or some combination thereof. So - How much do we want held in reserve? How "flexibly" (ref RFC3531) are we allocating our addresses? How many total (enterprise | home) clients do we want to support? Off the cuff, let's say we use left-most (sparse) allocation and only hit 50% efficiency (keeping the right-most bit totally in reserve!) ... If I am an ISP, and I have 300M home users (/56s) I just need a /26, and that actually gives me a lot of room for more clients (like 200M more). So - what was the problem again? Let's make it even more interesting - let's say I am an ISP, I am allocating /48s, and I need to support - say - 6B assignments for every person in the world + 2B for every organization in the world (#s chosen arbitrarily, feel free to add another bit if it makes you feel better). Bearing in mind that this means every single person and organization has 64k subnets, each of which contains "as many hosts as is appropriate", and all of these are globally routable ... I "just" need a /15 to cover this absolute worst case. Heck, let's make it /14 for good measure. So now each standard RIR can "only" support 4 of this size service provider, but we still have 512 RIR sized allocations. If the individuals got /56s instead these numbers getting even bigger ... So - what was the problem again? Oh, and this is just from the 2000::/3 range ... next up, 4000::/3 ... 6000::/3, 8000::/3, a000::/3, c000::/3. And if we feel like we burned through 2000::/3 too fast at some point in the future, maybe we revisit the rules around the time we start thinking about allocating from 4000::/3? (Or "skip one", and star the new rules with 6000::/3 ... I am not picky). Note, I am _NOT_ saying we should be careless or cavalier about address allocation, just saying we don't live in a constrained situation. And if there is a choice to be made between scalability/flexibility/summarization'ability (is that a word?) and strict efficiency ... the efficiency loses. /TJ PS - Yes, 4.3B seemed really big at one point ... but seriously, do the above numbers not _really_ sound big enough? From nanog at daork.net Wed Feb 4 21:19:54 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 5 Feb 2009 16:19:54 +1300 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <498A4A74.6030703@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <00f401c98733$69a606a0$3cf213e0$@com> <498A4A74.6030703@internode.com.au> Message-ID: <79315111-DAE4-4DC8-9EFA-DD6622862729@daork.net> On 5/02/2009, at 3:09 PM, Matthew Moyle-Croft wrote: > TJ wrote: >> No, we should hand each home a /56 (or perhaps a /48, for the >> purists out >> there) - allowing for multiple segments (aka subnet, aka links, >> etc.). > If there are, say, 250-500 million broadband services in the world > (probably more) then, if every ISP followed best practise for IPv6 > address allocation, (sparse, bits for infrastructure, whatever etc) > then what percentage of the space do we have left if we hand out /56 > or /48s?). Taking into account the space already carved off for > link local, private addressing, US Military etc. > > Has anyone done some analysis of what this might look like? > Especially with growth etc. My addressing plan works like this: ISP gets /32, 2001:db8::/32 - 2001:db8:0::/48 = ISP use -- 2001:db8:0:0::/64 = infrastructure --- 2001:db8:0:0:0:0:0::/112 = loopbacks ( 65536 ) --- 2001:db8:0:0:1:0:0::/112 through 2001:db8::ffff:ffff:ffff:0/112 = / 112 link nets between ISP routers ( 281474976710656 ) -- 2001:db8:0::/64 through 2001:db8:0:ffff::/64 = ISP networks, ie. servers, etc. - 2001:db8:1::/64 through 2001:db8:ffff:ffff::/64 = customer networks. Assuming the above, we have 65535 /48s available to customers, or 16,711,680 /56s. The "ISP use" /48 burns 256 /56s, or potential customers. So, like burning a /24 for the entire ISP operation. So, if you have more than 65K business customers, get more than a /32. If you have more than 16M residential or small business customers, get more than /32. The above plan puts the addresses you type lots (loopbacks, link nets) on the shortest addresses you have - you can use the zero compression :: thing. These are also the addresses that cause the most trouble if fat fingered, so shorter addresses leave less room for error. In addition, the entire first /64 (loopbacks, link nets) should never really receive packets from outside the network. Drop in an ACL. Modification to the above plan is to use /64s for link nets between ISP routers, if you are worried about compatibility issues. You now have a trade off between 65k ISP server networks, and 65k link nets. Let's say 32k for each. -- Nathan Ward From mmc at internode.com.au Wed Feb 4 21:34:34 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 05 Feb 2009 14:04:34 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090205021907.GA74285@ussenterprise.ufp.org> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> <20090205021907.GA74285@ussenterprise.ufp.org> Message-ID: <498A5E4A.8020301@internode.com.au> Leo Bicknell wrote: > In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew Moyle-Croft wrote: > >> My FEAR is that people ("customers") are going to start assuming that v6 >> means their own static allocation (quite a number are assuming this). >> This means that I have a problem with routing table size etc if I have >> to implement that. >> > > Customers don't want static addresses. > Customers want many different things. Customers don't think of their networks at home or in their offices as part of an ISP network. They think of it as an island that they control and run and which they buy connectivity to the internet to. They want flexibility and not the "evil ISP" telling THEM what to do or making them spend money on their IT consultants to change things when an ISP wants to renumber. > They want DNS that works, with their own domain names, forward and > reverse. > Yep, but many want to run it themselves, independantly of an ISP. > They want renumbering events to be infrequent, and announced in > advance. > Where infrequent = never. > They want the box the cable/dsl/fios provider to actually work, > that is be able to do really simple stuff without having to buy > another stupid box to put behind it. > Well, we let them chose here in AU ... > None of these require static, and in fact I'd think it would be > easier to get it right than it would be to do statics for most > providers. But, I must be wrong, since the only solution virtually > every provider offers is to "move up" to "a static IP". > I think some customers would like us to spend money running DNS for them for free, but most who care want to do it independently of us. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From trejrco at gmail.com Wed Feb 4 21:41:07 2009 From: trejrco at gmail.com (TJ) Date: Wed, 4 Feb 2009 22:41:07 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090205030522.13D152B21F3@mx5.roble.com> References: <20090205030522.13D152B21F3@mx5.roble.com> Message-ID: <013a01c98743$952e7c20$bf8b7460$@com> >> All IPv6 address assignments are leases. Whether you get >> the address from a RIR, LIR or ISP. The lease may not be >> renewed when it next falls due. You may get assigned a >> different set of addresses at that point. You should plan >> accordingly. > >Exactly the problem, and the reason A) IPv6 is not and will not be a viable >option any time soon (soon being before the publication of an IPv6 NAT RFC), >and B) why network providers (and other parties who stand to gain >financially) are firmly against IPv6 NAT. A) I think you have a different definition of viable than I do. I have v6 today, running just fine. Not as a home user, yet - but that is coming in the foreseeable future and has nothing to do with the presence of NAT66, or lack thereof. B) I am not a service provider, and I still tend to dis-favor NAT. Not as vehemently as some, but I for the most part, fail to see the need. > >> If we could get a true accounting of the extra cost imposed by NAT's >> I would say it would be in the trillions of dollars. > >This is exactly the sort of hyperbole, like RFC4864's proposing that >application-layer proxies are a viable substitute for NAT, that discredits >IPv6 proponents. Those who remember the financial industry's push for SET, >a failed encryption technology, will be struck by the similarities in >technical vs rhetorical arguments. While I generally try to avoid the NAT vs NONAT religious debate ... I'll throw in a few comments. > >Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network >engineers will be interested in the rational behind statements like: And I suspect lots of new-to-IPv6 network engineers could benefit from more IPv6 exposure :). > > * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what > it saves consumers, ILECs, or ISPs?) Developed a peer-to-peer application lately? I haven't, but I know some of the issues others have had to go through to work in spite of NAT. > > * NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It > isn't much different than it is now. (say again?) Sorry, your befuddlement has passed on to me - I am not sure what you are saying here. The best I can pull from that would be something about PI vs PA space, and I'd comment that both are now available. > * NAT disadvantage #3: RFC1918 was created because people were afraid of > running out of addresses. (in 1992?) Is that a question? > * NAT disadvantage #4: It requires more renumbering to join conflicting > RFC1918 subnets than would IPv6 to change ISPs. (got stats?) Actually, I think those are different points. NAT-space collisions are a REAL problem, and renumbering due to changing ISPs is also a REAL problem. > * NAT disadvantage #5: it provides no real security. (even if it were true > this could not, logically, be a disadvantage) It is a disadvantage if people believe it is a security thing when it isn't. >OTOH, the claimed advantages of NAT do seem to hold water somewhat better: > > * NAT advantage #1: it protects consumers from vendor (network provider) > lock-in. OK, use PI space. > * NAT advantage #2: it protects consumers from add-on fees for addresses > space. (ISPs and ARIN, APNIC, ...) IPv6 addresses (network allocations, actually) are pretty inexpensive ... > * NAT advantage #3: it prevents upstreams from limiting consumers' > internal address space. (will anyone need more than a /48, to be asked in > 2018) Yes, /48s have already been outgrown ... so you call up your ISP and justify more, they give it to you. No fuss, no muss. > * NAT advantage #4: it requires new (and old) protocols to adhere to the > ISO seven layer model. Actually, it does more than that. You are thinking of "traditional" network apps, client-server stuff. Think end to end / peer to peer (and I don't mean illegal file sharing) ... > * NAT advantage #5: it does not require replacement security measures to > protect against netscans, portscans, broadcasts (particularly microsoft > netbios), and other malicious inbound traffic. Depends on the NAT mode (1:1 or PAT; cone or restricted), and a stateful firewall provides more/real protection ... again, I am not a radical anti-NAT person, I just don't like the pro-NAT hyperbole any more than you favor the opposite :). IMHO /TJ From Mark_Andrews at isc.org Wed Feb 4 21:45:38 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 05 Feb 2009 14:45:38 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Wed, 04 Feb 2009 19:05:22 -0800." <20090205030522.13D152B21F3@mx5.roble.com> Message-ID: <200902050345.n153jcff081338@drugs.dv.isc.org> In message <20090205030522.13D152B21F3 at mx5.roble.com>, Roger Marquis writes: > Mark Andrews wrote: > > All IPv6 address assignments are leases. Whether you get > > the address from a RIR, LIR or ISP. The lease may not be > > renewed when it next falls due. You may get assigned a > > different set of addresses at that point. You should plan > > accordingly. > > Exactly the problem, and the reason A) IPv6 is not and will not be a viable > option any time soon (soon being before the publication of an IPv6 NAT > RFC), and B) why network providers (and other parties who stand to gain > financially) are firmly against IPv6 NAT. > > > If we could get a true accounting of the extra cost imposed > > by NAT's I would say it would be in the trillions of dollars. > > This is exactly the sort of hyperbole, like RFC4864's proposing that > application-layer proxies are a viable substitute for NAT, that discredits > IPv6 proponents. Those who remember the financial industry's push for SET, > a failed encryption technology, will be struck by the similarities in > technical vs rhetorical arguments. > > Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network > engineers will be interested in the rational behind statements like: > > * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what > it saves consumers, ILECs, or ISPs?) > * NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It > isn't much different than it is now. (say again?) > > * NAT disadvantage #3: RFC1918 was created because people were afraid of > running out of addresses. (in 1992?) > > * NAT disadvantage #4: It requires more renumbering to join conflicting > RFC1918 subnets than would IPv6 to change ISPs. (got stats?) > > * NAT disadvantage #5: it provides no real security. (even if it were true > this could not, logically, be a disadvantage) > > OTOH, the claimed advantages of NAT do seem to hold water somewhat better: > > * NAT advantage #1: it protects consumers from vendor (network provider) > lock-in. Nope. > * NAT advantage #2: it protects consumers from add-on fees for addresses > space. (ISPs and ARIN, APNIC, ...) Only until the consumers get wind of any rip-off pricing. RIR's are charging ISP's about the same for a IPv6 /48 as they do the a IPv4 address. > * NAT advantage #3: it prevents upstreams from limiting consumers' > internal address space. (will anyone need more than a /48, to be asked in > 2018) We already know some will need more than a /48. /48 was only ever described as meeting the requirements of *most* business and consumers. > * NAT advantage #4: it requires new (and old) protocols to adhere to the > ISO seven layer model. Given were are running IP that is fiticious. > * NAT advantage #5: it does not require replacement security measures to > protect against netscans, portscans, broadcasts (particularly microsoft > netbios), and other malicious inbound traffic. What replacement? You just buy a IPv6 router with a firewall. It will be about the same cost as a IPv4 router with a NAT. > IMHO, > Roger Marquis > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From cmadams at hiwaay.net Wed Feb 4 21:58:53 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 4 Feb 2009 21:58:53 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090205030522.13D152B21F3@mx5.roble.com> References: <20090205030522.13D152B21F3@mx5.roble.com> Message-ID: <20090205035853.GA736971@hiwaay.net> Once upon a time, Roger Marquis said: > * NAT advantage #5: it does not require replacement security measures to > protect against netscans, portscans, broadcasts (particularly microsoft > netbios), and other malicious inbound traffic. Since NAT == stateful firewall with packet mangling, it would be much easier to drop the packet mangling and just use a stateful firewall. You are just reinforcing the incorrect belief that "NAT == security, no-NAT == no-security". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From babydr at baby-dragons.com Wed Feb 4 22:14:44 2009 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Wed, 4 Feb 2009 19:14:44 -0900 (AKST) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: <498A466B.70507@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A466B.70507@internode.com.au> Message-ID: Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: > Scott Howard wrote: >> On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore >> wrote: >> >> On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >> wrote: >> >> >>> but my point was that people are starting to assume that v6 WILL mean >>> static allocations for all customers. >>> >> >> >> By design IPv6 should mean _less_ static allocations than IPv4 - in the >> event that a client disconnects/reconnects and gets a new /64 then their >> network *should* automatically handle that fact, with all clients >> automagically renumbering themselves to the new /64, updating DNS, etc. >> Local communications won't be impacted as they should be using the >> link-local address. >> > _should_ > > As I asked before - I'm really keen to actually do this stuff - but all I get > is people who haven't done it telling me theory and not how it works in > practise in a real ISP of some scale. > Telling customers "well, you might get renumbered randomly" isn't going to > work, no matter what the theory about it all is. They do crazy and > unexpected things and bleat about it even if you told them not to. At worse > they stop paying you and leave! > > My hope is that PD will be used for the majority and statics will be small in > number. My FEAR is that customers have already been conditioned that v6 will > mean statics for everyone because v6 has so many! (This has already been the > assumption many have made from the customer side). >> The bit that isn't clear at the moment is if (and how well) that will >> actually work in practice. And that brings us back to the good old >> catch-22 >> of ISPs not supporting IPv6 because consumer CPE doesn't support it, and >> CPE >> not supporting it because ISP don't... >> > Tell me about it. > As I asked before - has ANYONE done this before? ie. fully dualstacked to > customers? Or is it still theory? Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ From mmc at internode.com.au Wed Feb 4 22:29:43 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 5 Feb 2009 14:59:43 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A466B.70507@internode.com.au> Message-ID: <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> Hi James, I don't think anyone really has done it large scale properly. I've had basically nothing from anyone. Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!). There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience. Scary huh? I'm meant to have 250,000 customers running it by Christmas! MMC On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote: > Hello Matthew , See way below ... > > On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: >> Scott Howard wrote: >>> On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore >> >wrote: >>> >>> On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >> >wrote: >>> >>>> but my point was that people are starting to assume that v6 WILL >>>> mean >>>> static allocations for all customers. >>> By design IPv6 should mean _less_ static allocations than IPv4 - >>> in the >>> event that a client disconnects/reconnects and gets a new /64 then >>> their >>> network *should* automatically handle that fact, with all clients >>> automagically renumbering themselves to the new /64, updating DNS, >>> etc. >>> Local communications won't be impacted as they should be using the >>> link-local address. >> _should_ >> >> As I asked before - I'm really keen to actually do this stuff - but >> all I get is people who haven't done it telling me theory and not >> how it works in practise in a real ISP of some scale. Telling >> customers "well, you might get renumbered randomly" isn't going to >> work, no matter what the theory about it all is. They do crazy and >> unexpected things and bleat about it even if you told them not to. >> At worse they stop paying you and leave! >> >> My hope is that PD will be used for the majority and statics will >> be small in number. My FEAR is that customers have already been >> conditioned that v6 will mean statics for everyone because v6 has >> so many! (This has already been the assumption many have made from >> the customer side). >>> The bit that isn't clear at the moment is if (and how well) that >>> will >>> actually work in practice. And that brings us back to the good >>> old catch-22 >>> of ISPs not supporting IPv6 because consumer CPE doesn't support >>> it, and CPE >>> not supporting it because ISP don't... >> Tell me about it. As I asked before - has ANYONE done this >> before? ie. fully dualstacked to customers? Or is it still >> theory? > > Has Anyone responded to you on/off list with even a close > approximation of showing they have accomplished what you've > requested ? > I am beginning to be worried that no one [has|is willing to > divulge] that they have accomplished this . One would think that > someone would at least pipe up just for the bragging factor . > > Twyl , JimL > -- > +------------------------------------------------------------------+ > | James W. Laferriere | System Techniques | Give me VMS | > | Network&System Engineer | 2133 McCullam Ave | Give me Linux | > | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | > +------------------------------------------------------------------+ -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From mmc at internode.com.au Wed Feb 4 22:38:53 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 5 Feb 2009 15:08:53 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A466B.70507@internode.com.au> <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> Message-ID: <7F028B67-022E-4665-97EF-A187D1942B44@internode.com.au> Hmm, Apologies for that - wasn't meant to goto the list. Was a bit "frank". MMC On 05/02/2009, at 2:59 PM, Matthew Moyle-Croft wrote: > Hi James, > > I don't think anyone really has done it large scale properly. > > I've had basically nothing from anyone. > > Given my knowledge of where most large BRAS/Cable vendors are upto - > I don't think anyone could have. (Cisco won't have high end v6 > pppoe support until late this year!). > > There's a lot of people who clearly don't work for ISPs yammering on > about the Zen of v6, but no one with real experience. > > Scary huh? I'm meant to have 250,000 customers running it by > Christmas! > > MMC > > On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote: > >> Hello Matthew , See way below ... >> >> On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: >>> Scott Howard wrote: >>>> On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore >>> >wrote: >>>> >>>> On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >>> >wrote: >>>> >>>>> but my point was that people are starting to assume that v6 WILL >>>>> mean >>>>> static allocations for all customers. >>>> By design IPv6 should mean _less_ static allocations than IPv4 - >>>> in the >>>> event that a client disconnects/reconnects and gets a new /64 >>>> then their >>>> network *should* automatically handle that fact, with all clients >>>> automagically renumbering themselves to the new /64, updating >>>> DNS, etc. >>>> Local communications won't be impacted as they should be using the >>>> link-local address. >>> _should_ >>> >>> As I asked before - I'm really keen to actually do this stuff - >>> but all I get is people who haven't done it telling me theory and >>> not how it works in practise in a real ISP of some scale. Telling >>> customers "well, you might get renumbered randomly" isn't going to >>> work, no matter what the theory about it all is. They do crazy >>> and unexpected things and bleat about it even if you told them not >>> to. At worse they stop paying you and leave! >>> >>> My hope is that PD will be used for the majority and statics will >>> be small in number. My FEAR is that customers have already been >>> conditioned that v6 will mean statics for everyone because v6 has >>> so many! (This has already been the assumption many have made from >>> the customer side). >>>> The bit that isn't clear at the moment is if (and how well) that >>>> will >>>> actually work in practice. And that brings us back to the good >>>> old catch-22 >>>> of ISPs not supporting IPv6 because consumer CPE doesn't support >>>> it, and CPE >>>> not supporting it because ISP don't... >>> Tell me about it. As I asked before - has ANYONE done this >>> before? ie. fully dualstacked to customers? Or is it still >>> theory? >> >> Has Anyone responded to you on/off list with even a close >> approximation of showing they have accomplished what you've >> requested ? >> I am beginning to be worried that no one [has|is willing to >> divulge] that they have accomplished this . One would think that >> someone would at least pipe up just for the bragging factor . >> >> Twyl , JimL >> -- >> +------------------------------------------------------------------+ >> | James W. Laferriere | System Techniques | Give me VMS | >> | Network&System Engineer | 2133 McCullam Ave | Give me Linux | >> | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | >> +------------------------------------------------------------------+ > > -- > Matthew Moyle-Croft Internode/Agile Peering and Core Networks > Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia > Email: mmc at internode.com.au Web: http://www.on.net > Direct: +61-8-8228-2909 Mobile: +61-419-900-366 > Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 > -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From marquis at roble.com Wed Feb 4 22:39:08 2009 From: marquis at roble.com (Roger Marquis) Date: Wed, 4 Feb 2009 20:39:08 -0800 (PST) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: <20090205043908.1BAA82B21F4@mx5.roble.com> Seth Mattinen wrote: > Far too many people see NAT as synonymous with a firewall so they think > if you take away their NAT you're taking away the security of a firewall. NAT provides some security, often enough to make a firewall unnecessary. It all depends on what's inside the edge device. But really, I've never heard anyone seriously equate a simple NAT device with a firewall. People do, and justifiably, equate NAT with the freedom to number, subnet, and route their internal networks however they choose. To argue against that freedom is anti-consumer. Continue to ignore consumer demand and the marketplace will continue to respond accordingly. Give consumers a choice (of NAT or not) and they will come (to IPv6). It's just about as simple as that. Well, that and a few unresolved issues with CAMs, routing tables, and such. Roger Marquis From nanog at daork.net Wed Feb 4 22:40:18 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 5 Feb 2009 17:40:18 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A466B.70507@internode.com.au> <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> Message-ID: I am told that juniper have just released their E series code to do hitless failover and ipv6cp at the same time. If you are not running hitless it has been working for some time. Apologies if this message is brief, it is sent from my cellphone. On 5/02/2009, at 17:29, Matthew Moyle-Croft wrote: > Hi James, > > I don't think anyone really has done it large scale properly. > > I've had basically nothing from anyone. > > Given my knowledge of where most large BRAS/Cable vendors are upto - > I don't think anyone could have. (Cisco won't have high end v6 > pppoe support until late this year!). > > There's a lot of people who clearly don't work for ISPs yammering on > about the Zen of v6, but no one with real experience. > > Scary huh? I'm meant to have 250,000 customers running it by > Christmas! > > MMC > > On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote: > >> Hello Matthew , See way below ... >> >> On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: >>> Scott Howard wrote: >>>> On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore >>> >wrote: >>>> >>>> On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >>> >wrote: >>>> >>>>> but my point was that people are starting to assume that v6 WILL >>>>> mean >>>>> static allocations for all customers. >>>> By design IPv6 should mean _less_ static allocations than IPv4 - >>>> in the >>>> event that a client disconnects/reconnects and gets a new /64 >>>> then their >>>> network *should* automatically handle that fact, with all clients >>>> automagically renumbering themselves to the new /64, updating >>>> DNS, etc. >>>> Local communications won't be impacted as they should be using the >>>> link-local address. >>> _should_ >>> >>> As I asked before - I'm really keen to actually do this stuff - >>> but all I get is people who haven't done it telling me theory and >>> not how it works in practise in a real ISP of some scale. Telling >>> customers "well, you might get renumbered randomly" isn't going to >>> work, no matter what the theory about it all is. They do crazy >>> and unexpected things and bleat about it even if you told them not >>> to. At worse they stop paying you and leave! >>> >>> My hope is that PD will be used for the majority and statics will >>> be small in number. My FEAR is that customers have already been >>> conditioned that v6 will mean statics for everyone because v6 has >>> so many! (This has already been the assumption many have made from >>> the customer side). >>>> The bit that isn't clear at the moment is if (and how well) that >>>> will >>>> actually work in practice. And that brings us back to the good >>>> old catch-22 >>>> of ISPs not supporting IPv6 because consumer CPE doesn't support >>>> it, and CPE >>>> not supporting it because ISP don't... >>> Tell me about it. As I asked before - has ANYONE done this >>> before? ie. fully dualstacked to customers? Or is it still >>> theory? >> >> Has Anyone responded to you on/off list with even a close >> approximation of showing they have accomplished what you've >> requested ? >> I am beginning to be worried that no one [has|is willing to >> divulge] that they have accomplished this . One would think that >> someone would at least pipe up just for the bragging factor . >> >> Twyl , JimL >> -- >> +------------------------------------------------------------------+ >> | James W. Laferriere | System Techniques | Give me VMS | >> | Network&System Engineer | 2133 McCullam Ave | Give me Linux | >> | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | >> +------------------------------------------------------------------+ > > -- > Matthew Moyle-Croft Internode/Agile Peering and Core Networks > Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia > Email: mmc at internode.com.au Web: http://www.on.net > Direct: +61-8-8228-2909 Mobile: +61-419-900-366 > Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 > > > !DSPAM:22,498a6b69305768916813158! > > From rs at seastrom.com Wed Feb 4 22:45:50 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 04 Feb 2009 23:45:50 -0500 Subject: Seeking FIOS tech support with two (or more) brain cells Message-ID: <863aetcwzl.fsf@seastrom.com> Hi folks, Does anyone know any kind of super-secret back door number for Verizon FIOS tech support for people-with-a-clue? I can hear the drool hitting the keyboard on the other end of the line and the confusion in the voice of the support rep when I try to get help with turning up a "business" (ha!) FIOS circuit with five static addresses on it. Things have sure gone downhill since they decided that a MOCA handoff was a good idea; I turned one of these up for another friend a year ago and it was 100% plug and chug... Before you flame me, yes, I tried the database on puck.nether.net to see if I could pull something off via that route, but no joy. -r From nanog at daork.net Wed Feb 4 22:53:08 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 5 Feb 2009 17:53:08 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space References: Message-ID: <45444E2F-41D0-4536-AB85-A7FDD67D03C3@daork.net> Apologies if this message is brief, it is sent from my cellphone. Begin forwarded message: > From: Nathan Ward > > On 5/02/2009, at 16:58, Chris Adams wrote: >> Since NAT == stateful firewall with packet mangling, it would be much >> easier to drop the packet mangling and just use a stateful firewall. >> You are just reinforcing the incorrect belief that "NAT == security, >> no-NAT == no-security". > > Not entirely. There was a lengthy and heated debate on this list > about 6 months ago, where the point was raised that many people like > to use NAT because it provides some level of anonymity in thier > network. Obviously this only applies for networks with enough people > that that has an effect. > > IPv6 has privacy addresses to address this concern. From martin at theicelandguy.com Wed Feb 4 23:14:02 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Thu, 5 Feb 2009 00:14:02 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <200902050345.n153jcff081338@drugs.dv.isc.org> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> Message-ID: On Wed, Feb 4, 2009 at 10:45 PM, Mark Andrews wrote: > > In message <20090205030522.13D152B21F3 at mx5.roble.com>, Roger Marquis > writes: > > Mark Andrews wrote: > > > All IPv6 address assignments are leases. Whether you get > > > the address from a RIR, LIR or ISP. The lease may not be > > > renewed when it next falls due. You may get assigned a > > > different set of addresses at that point. You should plan > > > accordingly. > > > > Exactly the problem, and the reason A) IPv6 is not and will not be a > viable > > option any time soon (soon being before the publication of an IPv6 NAT > > RFC), and B) why network providers (and other parties who stand to gain > > financially) are firmly against IPv6 NAT. > What about costs? If you're a realist, you know that v6 migration is a cost problem. Ask cable or DSL providers across the world what percentage of their user base CPE is v6 compatable and the answer will likely be shocking. In this economy, unless the seondary market is egregiously expensive, don't expect to see a mass migration. There's also the problem of no known commericial grade NAT device (SLA worthy) that makes this easier. Thoughts appreciated. Best, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From mansaxel at besserwisser.org Wed Feb 4 23:23:33 2009 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Thu, 05 Feb 2009 06:23:33 +0100 Subject: Private use of non-RFC1918 IP space (IPv6-MW) In-Reply-To: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> Message-ID: <31404758D480DE01D194F79C@rasmus.kthnoc.net> --On onsdag, onsdag 4 feb 2009 19.02.56 -0500 "Patrick W. Gilmore" wrote: > Second, where did you get 4 users per /64? Are you planning to hand each > cable modem a /64? Telia got their /20 based on calculations where they give every customer a /48. Every apartment in every highrise gets 2^16 networks. I think that /56 or /52 is a more appropriate allocation per broadband subscriber. -- M?ns Nilsson M A C H I N A ... he dominates the DECADENT SUBWAY SCENE. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jabley at hopcount.ca Thu Feb 5 00:37:00 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 4 Feb 2009 22:37:00 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: <25D9C2DB-2F93-4280-9FCE-77897E65E1F6@hopcount.ca> On 4-Feb-2009, at 16:16, Patrick W. Gilmore wrote: > I guess I was thinking about v4 modems which do not get a subnet, > just an IP address. If we really are handing out a /64 to each DSL > & Cable modem, then we may very well be recreating the same problem. All the advice I have heard about address assignment to broadband subscribers is to give each subscriber a /56, in addition to the link address (which is effectively a /128). The last time I looked, the v6 allocation of every RIR apart from ARIN recommended a /48 instead of a /56. I have been specifically advised against assigning a /64 per subscriber on the grounds that it is short-sighted, since v6 residential gateways, when they come in large numbers, will expect to be able to assign addresses to more than one subnet in the customer network. > And before anyone says "there are 281474976710656 /48s!", just > remember your history. The pertinent numbers given the thinking above are 2^24 == 16,777,216 customer /56 assignments , or 2^16 == 65536 customer /48 assignments per /32 allocation from an RIR. (If a /32 is all you have, then you will want to reserve some of that space for your own infrastructure, and the numbers above will be slightly higher than reality.) I see people predicting that giving everybody a /56 is insane and will blow out routing tables. I don't quite understand that; at the regional ISP with which I am most familiar 40,000 or so internal/ customer routes in BGP, and I have not noticed anything fall over. This is 2008: we are not dealing with routers maxed out with 256MB of RAM. And this is without any attempt to aggregate per LNS, or per POP. (This regional ISP is close to being able to provide responses to IPV6CP requests for all customers to establish an interface id, ND/RA to assign a link address, and DHCPv6 PD on request, for all customers; it's working in the lab, but hasn't yet been rolled out on the production access routers, which are all Juniper E-series devices. No, there's no direct revenue in it today; yes, the vast majority of customers are probably using XP or a residential gateway that will never talk v6.) If you need to worry about the impact on your internal routing tables of internal customer growth, then it seems you should be more worried about the impact on your routing tables of growth in the global v4 table (which is surely more rapid, and arguably can be expected to accelerate as v4 exhaustion leads to imaginative inter-organisation address assignment for fee). > I was not there when v4 was spec'ed out, but I bet when someone said > "four-point-two BILLION addresses", someone else said "no $@#%'ing > way we will EVER use THAT many...." I suspect that for many regional ISPs a single allocation sufficient to number 16 million customers is probably good enough. In Canada, for example, that's half the total population, and probably larger than the total number of residences. No doubt there are a countable and significant number of super-ISPs in larger markets (or spanning multiple markets) that have requirements that out-strip that of a single /32, but I feel comfortable predicting that they are the minority in the grand scheme of things (and in any case, they can always request a larger allocation). Joe From morrowc.lists at gmail.com Thu Feb 5 00:40:06 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 Feb 2009 01:40:06 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <200902050345.n153jcff081338@drugs.dv.isc.org> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> Message-ID: <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> On Wed, Feb 4, 2009 at 10:45 PM, Mark Andrews wrote: > > We already know some will need more than a /48. /48 was > only ever described as meeting the requirements of *most* > business and consumers. > so.. what businesses need is not actually 'more than one /48' but real, useful, doable multihoming. A /48 is fine if you have only one site, it's been used to solve 2 of 3 problems: 1) my addresses don't have to change (if I only have one site) 2) I can multihome with a single address on my devices/hosts (cause the original v6 plan for that was just dumb) It doesn't solve the problem of an enterprise with more than one location/network-interconnect... we can go around this rose bush again and again and again, but honestly, deployment of v6 happens for real when there is a significant business reason to deploy it, and when the real concerns of enterprises today are actually addressed. -Chris From jabley at hopcount.ca Thu Feb 5 00:40:18 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 4 Feb 2009 22:40:18 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090205030522.13D152B21F3@mx5.roble.com> References: <20090205030522.13D152B21F3@mx5.roble.com> Message-ID: <7D00B14A-4299-43CA-AFF0-0305621D6730@hopcount.ca> On 4-Feb-2009, at 19:05, Roger Marquis wrote: > Mark Andrews wrote: >> All IPv6 address assignments are leases. Whether you get >> the address from a RIR, LIR or ISP. The lease may not be >> renewed when it next falls due. You may get assigned a >> different set of addresses at that point. You should plan >> accordingly. > > Exactly the problem, In the regional ISP I alluded to in my previous message, /56es are assigned to residential DSL customers and are static (they are handed out to the LNS from RADIUS). The link address (IPV6CP + ND/RA) depends on the particular LNS your PPP session lands on, however. > and the reason A) IPv6 is not and will not be a viable > option any time soon (soon being before the publication of an IPv6 NAT > RFC), and B) why network providers (and other parties who stand to > gain > financially) are firmly against IPv6 NAT. In this case there is no religion for or against NAT inherent in the v6 access service being provided. Customers can do what they want with the addresses provided to them. Joe From swmike at swm.pp.se Thu Feb 5 00:59:55 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 5 Feb 2009 07:59:55 +0100 (CET) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <25D9C2DB-2F93-4280-9FCE-77897E65E1F6@hopcount.ca> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <25D9C2DB-2F93-4280-9FCE-77897E65E1F6@hopcount.ca> Message-ID: On Wed, 4 Feb 2009, Joe Abley wrote: > I see people predicting that giving everybody a /56 is insane and will > blow out routing tables. I don't quite understand that; at the regional > ISP with which I am most familiar 40,000 or so internal/customer routes > in BGP, and I have not noticed anything fall over. This is 2008: we are > not dealing with routers maxed out with 256MB of RAM. And this is > without any attempt to aggregate per LNS, or per POP. What you do is that you do /40-44 per router or so and announce this to the rest of the network, then internally from that you assign /48 to /56 per customer out of that block. IPv6 enables us to lower address use and get less routes in the core network (both within the ISP and globally). -- Mikael Abrahamsson email: swmike at swm.pp.se From jabley at hopcount.ca Thu Feb 5 01:34:57 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 4 Feb 2009 23:34:57 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <25D9C2DB-2F93-4280-9FCE-77897E65E1F6@hopcount.ca> Message-ID: <73A60D47-2E45-4843-A9F2-5639FAE6EF80@hopcount.ca> On 4-Feb-2009, at 22:59, Mikael Abrahamsson wrote: > On Wed, 4 Feb 2009, Joe Abley wrote: > >> I see people predicting that giving everybody a /56 is insane and >> will blow out routing tables. I don't quite understand that; at the >> regional ISP with which I am most familiar 40,000 or so internal/ >> customer routes in BGP, and I have not noticed anything fall over. >> This is 2008: we are not dealing with routers maxed out with 256MB >> of RAM. And this is without any attempt to aggregate per LNS, or >> per POP. > > What you do is that you do /40-44 per router or so and announce this > to the rest of the network, then internally from that you assign /48 > to /56 per customer out of that block. > > IPv6 enables us to lower address use and get less routes in the core > network (both within the ISP and globally). That has the down-side today that you require customers to support DHCPv6 PD in order to get their /56, though. For some providers that might be simple to organise (e.g. business- focussed ISPs whose customers use a reliably-small set of CPE). For residential customers, however, I think it's far more likely to be problematic, and hence the idea of retaining the option for static configuration seems prudent, at least at this early stage in the game. Static configuration means you need the assignment to be consistent regardless of which LNS the customer lands on. I appreciate that this approach may well be a luxury only available to relatively small ISPs, and that the approach will quite possibly need to change in the future. But it seems like a reasonable way to go for now. Joe From owen at delong.com Thu Feb 5 02:34:57 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Feb 2009 00:34:57 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090205021907.GA74285@ussenterprise.ufp.org> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> <20090205021907.GA74285@ussenterprise.ufp.org> Message-ID: <77171172-A1D2-4A85-867D-37C45C3E65D8@delong.com> On Feb 4, 2009, at 6:19 PM, Leo Bicknell wrote: > In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, > Matthew Moyle-Croft wrote: >> My FEAR is that people ("customers") are going to start assuming >> that v6 >> means their own static allocation (quite a number are assuming this). >> This means that I have a problem with routing table size etc if I >> have >> to implement that. > > Customers don't want static addresses. > I completely disagree. > They want DNS that works, with their own domain names, forward and > reverse. > That's also necessary, but, it's not the full solution. > They want renumbering events to be infrequent, and announced in > advance. > You need to define infrequent. Renumbering more than once a decade would be problematic and costly for me. There are lots of places where my static address is known in configurations that I do not necessarily control and getting those places all updated in sync. with some providers arbitrary change is, well, problematic. Sure, most customers aren't quite in that situation, but, more and more having to have your specific IP added to some firewall somewhere (or more than one) is a valid concern. With IPv6, this challenge will increase, not decrease. As such, I don't see non-static addresses meeting everyone's needs. > They want the box the cable/dsl/fios provider to actually work, > that is be able to do really simple stuff without having to buy > another stupid box to put behind it. > There is that, yes. > None of these require static, and in fact I'd think it would be > easier to get it right than it would be to do statics for most > providers. But, I must be wrong, since the only solution virtually > every provider offers is to "move up" to "a static IP". > Actually, statics aren't any harder than dynamics if you do your providing right. In IPv4, statics are complicated by the fact that there is a shortage of addresses and so providers try to recycle. However, in always on broadband services, statics really don't take any more effort if the provider does decent planning, and, providers seem to be able to get away with charging huge premiums for them. I doubt providers could charge huge premiums for just making the basic stuff work, and, they seem to get paid anyway without doing so. (*note, Comcast is not getting paid by me pending them actually getting some things right, but, I seem to be the exception, not the rule). Owen From mohacsi at niif.hu Thu Feb 5 02:47:48 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 5 Feb 2009 09:47:48 +0100 (CET) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090205030522.13D152B21F3@mx5.roble.com> References: <20090205030522.13D152B21F3@mx5.roble.com> Message-ID: On Wed, 4 Feb 2009, Roger Marquis wrote: > Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network > engineers will be interested in the rational behind statements like: > > * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what > it saves consumers, ILECs, or ISPs?) Yes it cost more money in OPEX. Try to detect malicious host behind a NAT among thousand of hosts. > > * NAT disadvantage #3: RFC1918 was created because people were afraid of > running out of addresses. (in 1992?) Yes. One of my colleague, who participated in development of RFC 1918 confirmed it. > > * NAT disadvantage #4: It requires more renumbering to join conflicting > RFC1918 subnets than would IPv6 to change ISPs. (got stats?) This statement is true: Currently you encounter more private address usage than IPv6 usage. > > * NAT disadvantage #5: it provides no real security. (even if it were true > this could not, logically, be a disadvantage) It is true. Lots of administrator behind the NAT thinks, that because of the NAT they can run a poor, careless software update process. Majority of the malware infection is coming from application insecurity. This cannot be prevented by NAT! > > OTOH, the claimed advantages of NAT do seem to hold water somewhat better: > > * NAT advantage #1: it protects consumers from vendor (network provider) > lock-in. Use PI address and multi homing. > > * NAT advantage #2: it protects consumers from add-on fees for addresses > space. (ISPs and ARIN, APNIC, ...) No free lunch. Or use IPv6. > > * NAT advantage #3: it prevents upstreams from limiting consumers' > internal address space. (will anyone need more than a /48, to be asked in > 2018) You can gen more /48, or use ULA. > > * NAT advantage #4: it requires new (and old) protocols to adhere to the > ISO seven layer model. This statement is a bullshit. > > * NAT advantage #5: it does not require replacement security measures to > protect against netscans, portscans, broadcasts (particularly microsoft > netbios), and other malicious inbound traffic. Same, if your implement proper firewall filtering. Best Regards, Janos Mohacsi From brandon at bogons.net Thu Feb 5 03:31:28 2009 From: brandon at bogons.net (Brandon Butterworth) Date: Thu, 5 Feb 2009 09:31:28 +0000 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) Message-ID: <20090205093128.GG13387@virtual.bogons.net> Scott Howard wrote: > > And that brings us back to the good old catch-22 > > of ISPs not supporting IPv6 because consumer CPE doesn't support it, > > and CPE not supporting it because ISP don't... No, it's because neither need to do it. If they did the apparent catch-22 would be fixed Matthew Moyle-Croft wrote: > As I asked before - has ANYONE done this before? ie. fully > dualstacked to customers? Or is it still theory? We have ADSL users with v4 and v6, they mostly use low end Ciscos, 837 and such (cheap on ebay so for the tech user base it's not too hard) Cheap retail CPE adding v6 by default would help. James W. Laferriere wrote: > Hello Matthew , See way below ... It's not so far if you don't quote the entire message > I am beginning to be worried that no one [has|is willing to divulge] > that they have accomplished this . One would think that someone would > at least pipe up just for the bragging factor . The thread seemed long and noisy enough already without everyone doing a me too. We did it, to see if we could and because we have like minded users wanting access. I know there are others. brandon From trejrco at gmail.com Thu Feb 5 06:30:56 2009 From: trejrco at gmail.com (TJ) Date: Thu, 5 Feb 2009 07:30:56 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A466B.70507@internode.com.au> <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> Message-ID: <016d01c9878d$98ccb1e0$ca6615a0$@com> >Given my knowledge of where most large BRAS/Cable vendors are upto - I don't >think anyone could have. (Cisco won't have high end v6 pppoe support until >late this year!). Indeed, that is a big part of the problem in the home-user space. >There's a lot of people who clearly don't work for ISPs yammering on about >the Zen of v6, but no one with real experience. To be fair, some of those yammering work with/for enterprises/agencies/etc. that have done this; home users are not the only ones on the Internet ... From trejrco at gmail.com Thu Feb 5 06:41:01 2009 From: trejrco at gmail.com (TJ) Date: Thu, 5 Feb 2009 07:41:01 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> Message-ID: <018801c9878f$0256dd10$07049730$@com> >It doesn't solve the problem of an enterprise with more than one >location/network-interconnect... we can go around this rose bush again and >again and again, but honestly, deployment of v6 happens for real when there >is a significant business reason to deploy it, and when the real concerns of >enterprises today are actually addressed. Indeed, and the IETF's answer for multi-homing (SHIM6) is a non-starter for the majority of those interested in doing so. Enter PI space, now available from (most of) your local RIR(s). Yes, also enter DFZ growth ... From tme at multicasttech.com Thu Feb 5 06:47:51 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 5 Feb 2009 07:47:51 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <018801c9878f$0256dd10$07049730$@com> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> <018801c9878f$0256dd10$07049730$@com> Message-ID: On Feb 5, 2009, at 7:41 AM, TJ wrote: >> It doesn't solve the problem of an enterprise with more than one >> location/network-interconnect... we can go around this rose bush >> again and >> again and again, but honestly, deployment of v6 happens for real >> when there >> is a significant business reason to deploy it, and when the real >> concerns > of >> enterprises today are actually addressed. > > Indeed, and the IETF's answer for multi-homing (SHIM6) is a non- > starter for > the majority of those interested in doing so. > Enter PI space, now available from (most of) your local RIR(s). > Yes, also enter DFZ growth ... > > That is an answer, not the answer. You might be interested in the discussion around LISP (routing, not language). http://www.ietf.org/mail-archive/web/lisp/current/msg00070.html https://www.ietf.org/mailman/listinfo/lisp Regards Marshall From jbates at brightok.net Thu Feb 5 08:28:29 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 05 Feb 2009 08:28:29 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A3EDE.60008@internode.com.au> References: <200902050057.n150vJ2k074863@drugs.dv.isc.org> <498A3EDE.60008@internode.com.au> Message-ID: <498AF78D.1060303@brightok.net> Matthew Moyle-Croft wrote: > Currently with v4 I have one (majority) of customers where they have > dynamic addresses. For those I'm happy to use PD - but my point was > that people are starting to assume that v6 WILL mean static allocations > for all customers. This is my fear, is NOT being able to use PD for the > "residential grade" customers. Having to provide static allocations is > a problem if I have multiple POPs in a geographic region as I can't > summarise and get the redundancy I want. Summary of IPv6 is easy enough, and you'll probably assign at least two /48 networks to a pop, one for infrastructure and one for PD. I'm sure there will be more. > (If I commit to a customer they have a static range then I can't easily > change it on them - esp if they've done things like used the addresses > statically in DNS etc as our customers are want to do). There is a difference between static assignments to an interface for technical reasons and giving a customer a "static". Even if the customer technically has a static address, you are still allowed to change it so long as you are not giving him a static address. It's just a long term dynamic prefix. Renumbering IPv6 is a cake walk compared to IPv4, as it is somewhat more friendly to existing connections than IPv4 (if using stateless autoconfig). > Has anyone out there actually done an implentation, across DSL of PD? > If you have PLEASE let me know on list/off list/by dead letter drop in a > park. Especially interested in CPE etc. Cable is much further along on CPE than most home routers. Outside of the Apple Airport, I think there's only a handful of CPE home routers with v6 capabilities. Here's someone's experience with a real home v6 implementation from ISP side to home router. http://geekmerc.livejournal.com/699.html Jack From morrowc.lists at gmail.com Thu Feb 5 08:34:16 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 Feb 2009 09:34:16 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <018801c9878f$0256dd10$07049730$@com> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> <018801c9878f$0256dd10$07049730$@com> Message-ID: <75cb24520902050634w53666517k20aae8ba09ffed94@mail.gmail.com> On Thu, Feb 5, 2009 at 7:41 AM, TJ wrote: >>It doesn't solve the problem of an enterprise with more than one >>location/network-interconnect... we can go around this rose bush again and >>again and again, but honestly, deployment of v6 happens for real when there >>is a significant business reason to deploy it, and when the real concerns > of >>enterprises today are actually addressed. > > Indeed, and the IETF's answer for multi-homing (SHIM6) is a non-starter for to be fair, there are 3 options for multihoming today in v6 (three sanctioned by the IETF, not ordered in any order, not including discussion about goodness/badness/oh-god-no-ness of these) 1) multiple addresses on each device, one per provider 2) shim-6 3) HIP (still in development, as I recall) These don't address how the network is used today, nor customer requirements for enterprises nor operational concerns about running a network. > the majority of those interested in doing so. > Enter PI space, now available from (most of) your local RIR(s). sure, you can get PI /48's or up to something >= /40's... but, you are expected to not deaggregate these, and I suspect there will be issues when you attempt to do so with reachability. > Yes, also enter DFZ growth ... hurrah! :( -Chris From jbates at brightok.net Thu Feb 5 09:13:09 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 05 Feb 2009 09:13:09 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A4D7E.5050708@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <00fc01c98734$fee046d0$fca0d470$@com> <498A4D7E.5050708@internode.com.au> Message-ID: <498B0205.6080702@brightok.net> Matthew Moyle-Croft wrote: > I'm under no allusion that a /64 is going to be optional - it's really > too late which is sad. I think people have just latched onto it and now > accept it and defend it without thinking about "is this still the > answer?". Just because it's in an RFC doesn't mean it's still the > right answer in a changing world. My understanding is that there were long debates over if IPv6 would be 64 bits or 128 bit. 64 bits of networks should hopefully get us out of my lifetime. IPv4 wasn't always classless, though, so the rules may change, but not before we absolutely need it. > Yep - that's what I'm hoping (as I've said and clarified). But I think > the reality is that in the provider world, no matter what people here > say, customer demand for an unchanging IPv6 range will increase not > decrease - driving up provider routing size and complexity. We're assigning /60's via PD with network rotation, and will assign /56 or /48 if it's justified as a static assignment (though possibly handed out via PD). The latter needing SWIPs according to ARIN. A lot of people are trying to get their heads around IPv6, and the customers are really have problems with it. This isn't anything new. Tools and implementations will be built and improved to support the dynamic nature of IPv6 and make things easier for customers so that they don't have to worry about renumbers. Proper CPE routers should be able to receive PD, assign their interfaces, and even issue PD to other routers in the network. Jack From iljitsch at muada.com Thu Feb 5 09:25:44 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Feb 2009 16:25:44 +0100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> Message-ID: <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> On 5 feb 2009, at 1:16, Patrick W. Gilmore wrote: > I guess I was thinking about v4 modems which do not get a subnet, > just an IP address. If we really are handing out a /64 to each DSL > & Cable modem, then we may very well be recreating the same problem. IPv4 thinking. A single /64 isn't enough for a home user, because their gateway is a router and needs a different prefix at both sides. Users may also want to subnet their own network. So they need at least something like a /60. From iljitsch at muada.com Thu Feb 5 09:30:11 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Feb 2009 16:30:11 +0100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A3EDE.60008@internode.com.au> References: <200902050057.n150vJ2k074863@drugs.dv.isc.org> <498A3EDE.60008@internode.com.au> Message-ID: <8E6369B2-CD9B-4BB0-B7E2-D96927BA4925@muada.com> On 5 feb 2009, at 2:20, Matthew Moyle-Croft wrote: > Has anyone out there actually done an implentation, across DSL of > PD? If you have PLEASE let me know on list/off list/by dead letter > drop in a park. Especially interested in CPE etc. I've tested this years ago and it works just fine. Of course the Cisco that could do PD and the Cisco that could do v6 over ADSL were two different boxes and even one of them costs 5 - 10 x what a regular user is prepared to spend on their ADSL modem while the cheap boxes don't do v6 yet and there's tons of details to be worked out before you can buy a random cable/DSL modem and connect it to a random ISP and expect it two work. The protocols are there, we just need to agree on how to use them. From iljitsch at muada.com Thu Feb 5 09:41:49 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Feb 2009 16:41:49 +0100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A466B.70507@internode.com.au> <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> Message-ID: On 5 feb 2009, at 5:29, Matthew Moyle-Croft wrote: > I'm meant to have 250,000 customers running it by Christmas! So how do you plan on doing that? We know that IPv6 runs really well over regular ethernet or over tunnels. It doesn't work so well over the weird crap that broadband ISPs use which superficially looks like ethernet or PPP but isn't (and IPv6 over PPP is very problematic). So basically your choices are giving them real ethernet, a tunnel, creating a world of hurt for yourself by pretending the broadband crap is real ethernet or getting a vendor to sell you CPEs that take care of the difference. From marquis at roble.com Thu Feb 5 10:24:16 2009 From: marquis at roble.com (Roger Marquis) Date: Thu, 5 Feb 2009 08:24:16 -0800 (PST) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205030522.13D152B21F3@mx5.roble.com> Message-ID: <20090205162416.358EB2B21B4@mx5.roble.com> >> * NAT disadvantage #3: RFC1918 was created because people were afraid of >> running out of addresses. (in 1992?) > > Yes. One of my colleague, who participated in development of RFC 1918 > confirmed it. Your colleague was wrong. I was one of several engineers who handed out "private" addresses back before RFC1918 even though we could get "public" assignments. We did it for SMBs, large law firms, even departments of companies that were otherwise publically addressed. Nobody expressed concern for the size of the address pool (this was 1993 after all, only a year or two after uunet and psi made it possible to connect). You can confirm this by looking for references to address exhaustion in periodicals and usenet archives. It was simply not an issue until 95 or 96 at the earliest. The reason we used non-routable addresses was security and privacy. These subnets had no intention of ever communicating with "the Internet" directly. Web browsers changed that equation but the original business case for security and privacy has not changed. That business case is also why several of those otherwise legally addressed companies and departments switched to rfc1918, also before anyone gave a thought to address exhaustion. >> * NAT disadvantage #5: it provides no real security. (even if it were true >> this could not, logically, be a disadvantage) > > It is true. Lots of administrator behind the NAT thinks, that because of the > NAT they can run a poor, careless software update process. Majority of the > malware infection is coming from application insecurity. This cannot be > prevented by NAT! Can you site a reference? Can you substantiate "lots"? I didn't think so. This is yet another case the rhetoric gets a little over the top, leading those of us who were doing this before NAT to suspect a non-technical agenda. Roger Marquis From jbates at brightok.net Thu Feb 5 10:42:08 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 05 Feb 2009 10:42:08 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A466B.70507@internode.com.au> <231ECA80-9AEA-42C8-9801-CFEBA488EB36@internode.com.au> Message-ID: <498B16E0.4020501@brightok.net> Iljitsch van Beijnum wrote: > So how do you plan on doing that? > It works fine to my house. > We know that IPv6 runs really well over regular ethernet or over > tunnels. It doesn't work so well over the weird crap that broadband ISPs > use which superficially looks like ethernet or PPP but isn't (and IPv6 > over PPP is very problematic). > Not sure on PPP, but I'd suspect there's an issue still of support on the CPE side. Cisco's implementation of PPPoE/A and IPv6 seems to be easy enough. Unfortunately, I hate PPP, and the rules between v4 and v6 for RBE have changed. Latest Cisco philosophy I read is a /64 per sub-interface, stateless dhcp, and PD. The /64 assignments, while a bit messy (as if the config wasn't already messy) isn't a big deal. I haven't seen very many home routers handling PD, so I can expect that only customers without routers will actually use v6. Perhaps a few airports might do PD. Don't have one to test. While not perfect, I don't see much of an issue with the layout, although I hope Cisco adds TA to DHCPv6 soon, as there's no telling what home routers will decide to do. I have three large issues I haven't resolved yet. I have suboptimal paths for v6 compared to v4, and given the economy and the expense of upgrading core infrastructures, I do wonder if some of these companies will even survive the transition. Another issue is my own ignorance, but I still need to play with DNS in relation to IPv6, both using DDNS as well as using various support for generating templated PTR/A records on the fly. Finally, the by IP theory of SII and my CALEA gear definitely won't work well with the current IPv6 layout and privacy extension able to change the IP every so often. I'm still surprised that I haven't seen support for dynamically allocating (perhaps through radius) a /64 to a sub-interface based on it's receipt of a router solicitation. The dynamic nature of prefixes is still preferred if one values some amount of privacy on the Internet. I dislike people tracking customers by prefix. How long does it take for someone to pinpoint that a prefix won't change and start cataloging more information based on prefix that wasn't previously available via cookies? The only large caveat I've seen with Cisco is that for a 7200 VXR using RBE, 12.3T is about as far as you can go with tolerable bugs. Juniper didn't seem able to provide me with a decent plan comparable to Cisco's bridging edge. Perhaps I'm just running obsolete edge gear and haven't met the vendors everyone else liked better. Jack From Valdis.Kletnieks at vt.edu Thu Feb 5 10:42:21 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Feb 2009 11:42:21 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: Your message of "Thu, 05 Feb 2009 12:22:43 +1030." <498A466B.70507@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A466B.70507@internode.com.au> Message-ID: <17256.1233852141@turing-police.cc.vt.edu> On Thu, 05 Feb 2009 12:22:43 +1030, Matthew Moyle-Croft said: > Telling customers "well, you might get renumbered randomly" isn't going > to work, no matter what the theory about it all is. They do crazy and > unexpected things and bleat about it even if you told them not to. At > worse they stop paying you and leave! Dunno how things are Down Under, but around here, the "at worst" is *not* that they stop paying you - Joe Sixpack is a very low-margin commodity who can literally blow your year's profit with a *single* service call. "At worst" they refuse to leave and continue bleating. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Feb 5 11:19:59 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Feb 2009 12:19:59 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Thu, 05 Feb 2009 08:24:16 PST." <20090205162416.358EB2B21B4@mx5.roble.com> References: <20090205030522.13D152B21F3@mx5.roble.com> <20090205162416.358EB2B21B4@mx5.roble.com> Message-ID: <19444.1233854399@turing-police.cc.vt.edu> On Thu, 05 Feb 2009 08:24:16 PST, Roger Marquis said: > Can you site a reference? Can you substantiate "lots"? I didn't think so. > This is yet another case the rhetoric gets a little over the top, leading > those of us who were doing this before NAT to suspect a non-technical > agenda. Some estimates say that Conficker has nailed over 9 to 16 million systems by now. Every single one was because somebody didn't apply a patch that came out back in October. I'm sure at least some of these were because of either: a) "I'm Joe Sixpack, and I'm safe because I'm behind my cablemodem" b) "I'm Joe McSE (want fries with that?), and I'm safe because of the corporate firewall". (Note that due to its design, Conficker *can't* spread through a properly configured firewall - almost by definition, *every single* firewalled network that got hit was because somebody forgot the difference between "firewall" and "security perimeter". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From owen at delong.com Thu Feb 5 12:38:08 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Feb 2009 10:38:08 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090205162416.358EB2B21B4@mx5.roble.com> References: <20090205030522.13D152B21F3@mx5.roble.com> <20090205162416.358EB2B21B4@mx5.roble.com> Message-ID: <30E594A4-0441-4966-8DEC-BB1E32A83E90@delong.com> On Feb 5, 2009, at 8:24 AM, Roger Marquis wrote: >>> * NAT disadvantage #3: RFC1918 was created because people were >>> afraid of >>> running out of addresses. (in 1992?) >> >> Yes. One of my colleague, who participated in development of RFC >> 1918 confirmed it. > > Your colleague was wrong. I was one of several engineers who handed > out > "private" addresses back before RFC1918 even though we could get > "public" You are wrong.... Quoting from RFC 1597 (a precursor which was obsoleted by RFC 1918): 2. Motivation With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. The current practice is to assign globally unique addresses to all hosts that use TCP/IP. There is a growing concern that the finite IP address space might become exhausted. Therefore, the guidelines for assigning IP address space have been tightened in recent years [1]. These rules are often more conservative than enterprises would like, in order to implement and operate their networks. Note the specific reference in the second paragraph to address space exhaustion. Owen From jabley at hopcount.ca Thu Feb 5 13:06:16 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 5 Feb 2009 11:06:16 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <75cb24520902050634w53666517k20aae8ba09ffed94@mail.gmail.com> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> <018801c9878f$0256dd10$07049730$@com> <75cb24520902050634w53666517k20aae8ba09ffed94@mail.gmail.com> Message-ID: <04044622-0790-45EF-A93D-EED1D17B10D3@hopcount.ca> On 5-Feb-2009, at 06:34, Christopher Morrow wrote: > to be fair, there are 3 options for multihoming today in v6 (three > sanctioned by the IETF, not ordered in any order, not including > discussion about goodness/badness/oh-god-no-ness of these) > 1) multiple addresses on each device, one per provider > 2) shim-6 > 3) HIP (still in development, as I recall) 4) Obtain PA space and do what you're doing with v4. 5) Obtain PI space and do what you're doing with v4. (4) is problematic because filtering long prefixes in v6 seems to be more energetic than it is in v4. (5) is problematic if you don't qualify for PI space. (For completeness.) Joe From jbates at brightok.net Thu Feb 5 13:13:35 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 05 Feb 2009 13:13:35 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <04044622-0790-45EF-A93D-EED1D17B10D3@hopcount.ca> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> <018801c9878f$0256dd10$07049730$@com> <75cb24520902050634w53666517k20aae8ba09ffed94@mail.gmail.com> <04044622-0790-45EF-A93D-EED1D17B10D3@hopcount.ca> Message-ID: <498B3A5F.8080904@brightok.net> Joe Abley wrote: > 4) Obtain PA space and do what you're doing with v4. > > 5) Obtain PI space and do what you're doing with v4. > > (4) is problematic because filtering long prefixes in v6 seems to be > more energetic than it is in v4. (5) is problematic if you don't qualify > for PI space. > As more people are pushed to IPv6, I see the longer prefixes being allowed more. The problem with the other options, while wonderful, is that they require end node support. There is no guarantee the end nodes will support shim6. This means to have proper redundancy, we'll still have to use the routing protocols. If I'm wrong, please correct me. This is a good concern. Jack From iljitsch at muada.com Thu Feb 5 13:59:43 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Feb 2009 20:59:43 +0100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <04044622-0790-45EF-A93D-EED1D17B10D3@hopcount.ca> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> <018801c9878f$0256dd10$07049730$@com> <75cb24520902050634w53666517k20aae8ba09ffed94@mail.gmail.com> <04044622-0790-45EF-A93D-EED1D17B10D3@hopcount.ca> Message-ID: <4A9C848E-1E7F-4E38-B3AB-CB200DAF52D1@muada.com> On 5 feb 2009, at 20:06, Joe Abley wrote: > 4) Obtain PA space and do what you're doing with v4. > 5) Obtain PI space and do what you're doing with v4. > (4) is problematic because filtering long prefixes in v6 seems to be > more energetic than it is in v4. (5) is problematic if you don't > qualify for PI space. Better hope the RRG work (LISP, maybe) works out, then. I'm sure some people will relax their filters but I'm also convinced that a lot of people won't, at least not until a consensus on a good prefix length filtering strategy emerges. The RIR policies are such that if you allow /48s you're dead in the water if someone tries to inject a large number of those on purpose or it happens by accident in a particular unfortunate way. The reason I think people won't accept long prefixes is because of the above, or because (like me) they feel IPv6 PI was a mistake, or, the main contributor to routing table bloat, laziness. And the reason they won't care is that if an IPv6 destination returns !N applications that try both IPv6 and IPv4 fall back on IPv4 without a noticeable delay so outgoing sessions aren't affected. (Incoming sessions have to time out though, no ICMPs back to the originator for those.) From brandon at rd.bbc.co.uk Thu Feb 5 14:05:13 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 5 Feb 2009 20:05:13 GMT Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space Message-ID: <200902052005.UAA21321@sunf10.rd.bbc.co.uk> > 4) Obtain PA space and do what you're doing with v4. > (4) is problematic because filtering long prefixes in v6 seems to be > more energetic than it is in v4. (5) is problematic if you don't > qualify for PI space. Oi, nooo Lets not recreate the v4 issues by suggesting it's just problematic, it should not happen. If you're going to add a prefix at least do it properly get PI, keep PA as PA only. No PI too hard excuses. If there were global stricter filtering at allocations then the hijacking problem would be one less excuse for people to justify crazy deaggregation brandon From jmaimon at ttec.com Thu Feb 5 14:18:04 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 05 Feb 2009 15:18:04 -0500 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <55945.192.101.252.156.1233589709.squirrel@kingfisherops.com> <89D27DE3375BB6428DDCC2927489826A01F8004D@nexus.nexicomgroup.net> <20090202.180357.71143925.sthaug@nethelp.no> Message-ID: <498B497C.5060102@ttec.com> Randy Bush wrote: > i am surprised that no one has mentioned that it is not unusual for > folk, even isps, to use space assigned to the us military but never > routed on the public internet. i was exceedingly amused when first > i did a traceroute from bologna. > > randy > > Consider it mentioned, first hand experience for 11/8 rollouts. From kratzers at pa.net Thu Feb 5 14:38:44 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 5 Feb 2009 15:38:44 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW) In-Reply-To: <20090205093128.GG13387@virtual.bogons.net> References: <20090205093128.GG13387@virtual.bogons.net> Message-ID: <200902051538.46264.kratzers@pa.net> On Thursday 05 February 2009 04:31:28 Brandon Butterworth wrote: > > I am beginning to be worried that no one [has|is willing to divulge] > > that they have accomplished this . One would think that someone would > > at least pipe up just for the bragging factor . > > The thread seemed long and noisy enough already without everyone > doing a me too. > > We did it, to see if we could and because we have like > minded users wanting access. I know there are others. > > brandon Reading between the lines, nobody just wants to know THAT you've got it working. We want to know HOW you got it working. What protocols and policies were implemented on what hardware for what kind of user base? Stephen Kratzer Network Engineer CTI Networks, Inc. From jfbeam at gmail.com Thu Feb 5 15:44:58 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 05 Feb 2009 16:44:58 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> Message-ID: On Thu, 05 Feb 2009 10:25:44 -0500, Iljitsch van Beijnum wrote: > On 5 feb 2009, at 1:16, Patrick W. Gilmore wrote: >> I guess I was thinking about v4 modems which do not get a subnet, just >> an IP address. If we really are handing out a /64 to each DSL & Cable >> modem, then we may very well be recreating the same problem. > > IPv4 thinking. > > A single /64 isn't enough for a home user, because their gateway is a > router and needs a different prefix at both sides. Users may also want > to subnet their own network. So they need at least something like a /60. This is not a "maybe", Mr. Gilmore. It's repeating the same mistakes of IPv4. Mr. van B, your comments would be laughable if they weren't so absurdly horrific. I've lived quite productively behind a single IPv4 address for nearly 15 years. I've run 1000 user networks that only used one IPv4 address for all of them. I have 2 private /24's using a single public IPv4 address right now -- as they have been for 6+ years. Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point? Did we suddenly jump 20 years into the past? This is the exact same bull**** as the /8 allocations in the early days of IPv4. The idea of the "connected home" is still nowhere near *that* connected; no matter how many toys you have in your bathroom, it doesn't need a /96 of it's own. (which is an entire IPv4 of it's own.) Why do people avoid and resist IPv6... because it was designed with blind ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 networks.) Dooming us to repeating ALL those mistakes again. Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use. (yes, I've called for the IPng WG member's execution, reanimation, and re-execution, several times.) --Ricky From schnizlein at isoc.org Thu Feb 5 16:00:12 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Thu, 5 Feb 2009 17:00:12 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <00fc01c98734$fee046d0$fca0d470$@com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <00fc01c98734$fee046d0$fca0d470$@com> Message-ID: <52C3E468-D050-481A-AD36-92192B3FD31B@isoc.org> On 2009Feb4, at 8:56 PM, TJ wrote: > > However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not > capable. Maybe upgrades, service packs and updates will make them capable of using DHCPv6 for useful functions such as finding the address of an available name server by the time IPv6-only networks are in operation. > Also - does DHCPv6 currently have an option for prefix length? Just > asking. I did not see this answered in the long thread. The answer is No, prefix length comes in the Router Advertisement. John From josmon at rigozsaurus.com Thu Feb 5 16:06:14 2009 From: josmon at rigozsaurus.com (John Osmon) Date: Thu, 5 Feb 2009 15:06:14 -0700 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> Message-ID: <20090205220614.GA18219@jeeves.rigozsaurus.com> On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote: > [...] I've lived quite productively behind a single IPv4 address for > nearly 15 years. I've run 1000 user networks that only used one IPv4 > address for all of them. I have 2 private /24's using a single public > IPv4 address right now -- as they have been for 6+ years. Yet, in the new > order, you're telling me I need 18 billion, billion addresses to cover 2 > laptops, a Wii, 3 tivos, a router, and an access point? Thank you. Your ability to live with proxied/NATed Internet access has helped stave off the problems we're seeing now. The flip side shows up when Nintendo creates a cool new protocol for the Wii that requires Internet access. You Wii won't be able to participate until you teach your proxy/NAT box about the new protocol. I might not need a /96 for my razor, but I *do* want to have address space that allows more than one thing in my house to participate fully in use of the Internet. I have a group of gear at my house that can live in a NATted environment. Those things get RFC-1918 space, and live happily. I also have a /28 for laptops, VOIP gear, etc. -- I *like* those things to have Internet access rather than proxy-access. I have v6 space as well. I'm awaiting the day that I can get it from any common provider. From jabley at hopcount.ca Thu Feb 5 16:18:15 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 5 Feb 2009 14:18:15 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> Message-ID: <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> On 5-Feb-2009, at 13:44, Ricky Beam wrote: > This is the exact same bull**** as the /8 allocations in the early > days of IPv4. There are only 256 /8s in IPv4. There are 72,057,594,037,927,936 /56s in IPv6. If you object to where you think this is going, then perhaps it's more palatable to consider the 4,294,967,296 /32s in IPv6. [Feel free to adjust the ratios by orders of magnitude to accommodate the details that I am blandly ignoring above. It's doesn't change the message.] So in fact it's not *exactly* the same. Note that I am not denying the faint aroma of defecation in the air, nor the ghost of address assignment policies past. Also, your excitement is strangely invigorating. > [...] > > Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent > pending), you don't need DHCP. *face plant* The IPv4 mistake you've > NOT learned from here is "rarp". DCHP does far more than tell a > host was address it should use. (yes, I've called for the IPng WG > member's execution, reanimation, and re-execution, several times.) You might like to review the DHCPv6 specification and try some of its implementations. There are surely simpler approaches for host configuration than the current mess, and it's surely true that the design process reached some odd conclusions on occasion, but the fact remains that the tools and protocols needed to get the job done in this regard do actually exist. It's certainly an option today to build and deploy rather than to bicker and complain. Joe From iljitsch at muada.com Thu Feb 5 16:42:27 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Feb 2009 23:42:27 +0100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> Message-ID: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> On 5 feb 2009, at 22:44, Ricky Beam wrote: >> A single /64 isn't enough for a home user, because their gateway is >> a router and needs a different prefix at both sides. Users may also >> want to subnet their own network. So they need at least something >> like a /60. > Mr. van B, your comments would be laughable if they weren't so > absurdly horrific. That doesn't change the fact that users would be quite constrained by only having a /64 for their internal network. > I've lived quite productively behind a single IPv4 address for > nearly 15 years. So you were already doing NAT in 1994? Then you were ahead of the curve. > I've run 1000 user networks that only used one IPv4 address for all > of them. But how is that relevant for the discussion at hand? Is your point that if 1000 users can share an IPv4 address, 1000 users should share an IPv6 address? How would that make sense? Sharing addresses comes with significant downsides. (Like having to port map services running on hosts on the inside.) Sharing one address with 1000 active users comes with even more downsides. (There are applications that need more than 64 ports so the port number space becomes a limitation.) IPv6 was specifically designed to provide an enormous amount of address space, so accepting the limitation of using one address for a large number of users means foregoing a prime feature of IPv6--for no reason that I can see. > Yet, in the new order, you're telling me I need 18 billion, billion > addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an > access point? The logic is like this. 1. You need more than one. 2. You don't want to change the number often (or at all) 3. What is a number that is so large that it will always be enough? Answer: the size of a MAC address. 4. How large are MAC addresses? Answer: we have technologies that have 64-bit MAC addresses. So we use 64 bits to number subnets. Now of course that seems wasteful, but those 128-bit addresses are carried in all packets anyway, and at least with 64-bit subnet sizes you get some use out of them because you know subnets are always large enough and you get to generate an address from a prefix through a function that gives you the same address without requiring anyone to remember that address, which is also useful. Now if you want to argue that IPv6 should have had 48, 53 or 64 bit addresses, that's fine. But I have to warn you that that ship sailed almost 15 years ago. (My take: they should have been variable length.) > This is the exact same bull**** as the /8 allocations in the early > days of IPv4. Oh no. A /8 is only 16777216 addresses. A /48 for an end-user organization is 1208925819614629174706176 addresses. Or, more relavant: a /8 is almost 0.5% of the IPv4 address space. A / 48 is 0.000000000003% of the currently defined global unicast IPv6 address space. > The idea of the "connected home" is still nowhere near *that* > connected; It took us 15 years to get this far with IPv6. There is no IPv7 on the horizon currently, so even if we start that tomorrow we'll have to get by with IPv6 (and IPv4...) until about 2024. I'm pretty sure we'll be *that* connected by that time. > no matter how many toys you have in your bathroom, it doesn't need > a /96 of it's own. (which is an entire IPv4 of it's own.) Like I explained, we count "0, 1, many" where the IPv6 definition of "many" happens to be 2^64. This is obviously not the single answer that is right in all cases. But the point is that there are reasons why it was a bad idea to make it less than that and no reasons that reasonably required it to be less. > Why do people avoid and resist IPv6... because it was designed with > blind ignorance of the history of IPv4's mistakes (and how we *all* > run our IPv4 networks.) Dooming us to repeating ALL those mistakes > again. IPv6 changes too much but it doesn't fix enough. It would be good if it didn't change much but fixed a lot, but unfortunately, that wasn't to be. > Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent > pending), you don't need DHCP. *face plant* The IPv4 mistake you've > NOT learned from here is "rarp". DCHP does far more than tell a > host was address it should use. An IPv4 DHCP server gives me five things: an address, a prefix length, a default gateway, DNS addresses and a domain. A DHCPv6 server _can_ give me an address but I don't need it because I can generate it myself (with a little help from my friends the routers), it can't give me a prefix length or default gateway, so I still need router advertisements for those (may as well hardcode that /64 now because there is no reasonable way to get something else to work) and I don't need the domain because it's always muada.com anyway. So the only thing missing is the DNS addresses, but RFC 5006 specifies how to add this information to router advertisements. So I have no need for DHCPv6*. If someone else has, good for them and good luck with that. As long as I don't have to run a DHCPv6 server just to suck up all the broadcasts from DHCPv6 clients that are looking for DHCPv6 servers in my network. Please pick up after your dog. * except for prefix delegation to routers. From marquis at roble.com Thu Feb 5 16:44:22 2009 From: marquis at roble.com (Roger Marquis) Date: Thu, 5 Feb 2009 14:44:22 -0800 (PST) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: <20090205224422.A2CD02B21F0@mx5.roble.com> Owen DeLong wrote: > You are wrong.... > Quoting from RFC 1597 (a precursor which was obsoleted by RFC 1918): Ok, I was wrong. RFC1597 is dated 1994 and I thought the earliest references were 1995/96. The point I was trying to make is that RFC1918 and precursors were not motivated solely by address space limits. They were also motivated by the increasingly common practice of numbering internal networks with unassigned public address space. Random assignments of IP blocks had begun years before RFC1597 and were occurring in increasing numbers. "Those who forget history are doomed to repeat it" or so the saying goes. Force consumers internal networks to be publicly routable and you will see history repeat itself. Roger Marquis From jbates at brightok.net Thu Feb 5 16:58:47 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 05 Feb 2009 16:58:47 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090205224422.A2CD02B21F0@mx5.roble.com> References: <20090205224422.A2CD02B21F0@mx5.roble.com> Message-ID: <498B6F27.80700@brightok.net> Roger Marquis wrote: > references were 1995/96. The point I was trying to make is that RFC1918 > and precursors were not motivated solely by address space limits. They > were also motivated by the increasingly common practice of numbering > internal networks with unassigned public address space. Random assignments > of IP blocks had begun years before RFC1597 and were occurring in > increasing numbers. It is a good thing then, that IPv6 has RFC4193 addressing, then. Which I believe most organization will like a LOT better due to the decreased chance of conflict during private network interconnects. Of course, there are several aspects to using local addressing without NAT. There is nothing to say you can't use a proxy server. You can have local addressing and global addressing on the same systems if you so choose. Then again, who's taking bets on the fact that vendors will not use NAT anyways. Jack From jmaimon at ttec.com Thu Feb 5 17:00:48 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 05 Feb 2009 18:00:48 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> Message-ID: <498B6FA0.6050607@ttec.com> Joe Abley wrote: > > Note that I am not denying the faint aroma of defecation in the air, nor > the ghost of address assignment policies past. Maybe because by sheer coincidence 2**32 /32 is exactly the same as ipv4 2**32 /32? Maybe because by sheer coincidence 2**48 /48 is exactly the same as ipv4 2**(32 network bits + 16 tcp/udp port bits = 48)? Maybe because 2**32 /32's is less than the current world population? One thing is for certain. This assignment policy is NOT enough for every particle of sand on earth, which is what I thought we were getting. From james.cutler at consultant.com Thu Feb 5 17:05:43 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Thu, 5 Feb 2009 18:05:43 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> Message-ID: <49C38A17-90FE-4C9F-9333-82DD1D51BDCC@consultant.com> On Feb 5, 2009, at 5:42 PM, Iljitsch van Beijnum wrote: > ...An IPv4 DHCP server gives me five things: ...DNS addresses and a > domain... ============== Actually, lots more than five. E.g., NTP servers, preferred WINS servers (sorry, AD servers) and many other interesting (to some) items. And, the DNS domain my laptop joins depends on the network where it is connected in accordance with business policies in effect. Thus, DHCPv6 is of great interest for portable systems. I have previously noted that many clever technicians are well versed in what we do not need - without considering all the business management requirements that end user systems must meet. They are all correct, but not right. James R. Cutler james.cutler at consultant.com From jfbeam at gmail.com Thu Feb 5 17:15:02 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 05 Feb 2009 18:15:02 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> Message-ID: On Thu, 05 Feb 2009 17:18:15 -0500, Joe Abley wrote: > On 5-Feb-2009, at 13:44, Ricky Beam wrote: >> This is the exact same bull**** as the /8 allocations in the early days >> of IPv4. ... > So in fact it's not *exactly* the same. Just because the address space is mind-alteringly larger does not mean the same flawed thought process isn't being used. In the mid-80's, /8's were handed out like candy because there were "lots of address space" and "we'll never use it all." Well, that didn't last very long. I've listened to IPv6 advocates singing that same song for a decade. They are doomed to repeat the same mistake. (sure, it'll take longer than with IPv4.) > You might like to review the DHCPv6 specification and try some of its > implementations. IPv6 was designed to "not need DHCP." DHCPv6 has come about since people need more than just an address from "autoconfiguration". I can recall many posts over the years from the IPng WG telling people they didn't need DHCP. --Ricky From paul at telcodata.us Thu Feb 5 17:14:47 2009 From: paul at telcodata.us (Paul Timmins) Date: Thu, 05 Feb 2009 18:14:47 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <52C3E468-D050-481A-AD36-92192B3FD31B@isoc.org> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <00fc01c98734$fee046d0$fca0d470$@com> <52C3E468-D050-481A-AD36-92192B3FD31B@isoc.org> Message-ID: <498B72E7.5090506@telcodata.us> John Schnizlein wrote: > > On 2009Feb4, at 8:56 PM, TJ wrote: >> >> However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not >> capable. > > Maybe upgrades, service packs and updates will make them capable of > using DHCPv6 for useful functions such as finding the address of an > available name server by the time IPv6-only networks are in operation. And if not, hardcode em. It's not like your usual nameserver will be behind a nat anyway, and generally, a DNS server is a DNS server.* -Paul * Yes, there are times when your DNS server might be serving active directory DNS that's not otherwise publicly viewable, but it'll still be using globally available addressing, and you can restrict queries by IP address and range, allowing global use of the same nameserver, while only exposing the AD stuff to your internal network. From jbates at brightok.net Thu Feb 5 17:12:19 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 05 Feb 2009 17:12:19 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <49C38A17-90FE-4C9F-9333-82DD1D51BDCC@consultant.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <49C38A17-90FE-4C9F-9333-82DD1D51BDCC@consultant.com> Message-ID: <498B7253.1020008@brightok.net> James R. Cutler wrote: > Actually, lots more than five. E.g., NTP servers, preferred WINS > servers (sorry, AD servers) and many other interesting (to some) items. > And, the DNS domain my laptop joins depends on the network where it is > connected in accordance with business policies in effect. Thus, DHCPv6 > is of great interest for portable systems. > Operationally, this has been met from my experience. In fact, all of these items are handled with stateless DHCPv6 in coordination with SLAAC. Stateful DHCPv6 seems to be limited with some vendors, but unless they plan to do proxy-nd, I'm not sure they'll gain much except for end system compatibility. Jack From Mark_Andrews at isc.org Thu Feb 5 17:32:56 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 06 Feb 2009 10:32:56 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: Your message of "Thu, 05 Feb 2009 16:44:58 CDT." Message-ID: <200902052332.n15NWufn098293@drugs.dv.isc.org> In message , "Ricky Beam" writes: > On Thu, 05 Feb 2009 10:25:44 -0500, Iljitsch van Beijnum > wrote: > > On 5 feb 2009, at 1:16, Patrick W. Gilmore wrote: > >> I guess I was thinking about v4 modems which do not get a subnet, just > >> an IP address. If we really are handing out a /64 to each DSL & Cable > >> modem, then we may very well be recreating the same problem. > > > > IPv4 thinking. > > > > A single /64 isn't enough for a home user, because their gateway is a > > router and needs a different prefix at both sides. Users may also want > > to subnet their own network. So they need at least something like a /60. > > This is not a "maybe", Mr. Gilmore. It's repeating the same mistakes of > IPv4. > > Mr. van B, your comments would be laughable if they weren't so absurdly > horrific. I've lived quite productively behind a single IPv4 address for > nearly 15 years. I've run 1000 user networks that only used one IPv4 > address for all of them. Good for you. You don't need what NAT breaks. The rest of us are sick and tired of a artificially crippled network that NAT brings and all the additional costs associated with trying to talk with someone behind a NAT. > I have 2 private /24's using a single public > IPv4 address right now -- as they have been for 6+ years. Yet, in the new > order, you're telling me I need 18 billion, billion addresses to cover 2 > laptops, a Wii, 3 tivos, a router, and an access point? Did we suddenly > jump 20 years into the past? This is the exact same bull**** as the /8 > allocations in the early days of IPv4. The idea of the "connected home" > is still nowhere near *that* connected; no matter how many toys you have > in your bathroom, it doesn't need a /96 of it's own. (which is an entire > IPv4 of it's own.) No it doesn't need that many address. No one has ever said that it does. Does it really matter that 64 bits are set aside for the local part of the IPv6 address as long as there is enough address space for everyone to get the networks they need? By your own admission it does need multiple networks however. The address allocation policies are design to give everyone the networks that they need. > Why do people avoid and resist IPv6... because it was designed with blind > ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 > networks.) Dooming us to repeating ALL those mistakes again. Exhibit A: > With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need > DHCP. *face plant* So all of us running IPv6 networks using stateless autoconf are using something that does not work? BTW stateless autoconf and DHCP are complementry technologies. > The IPv4 mistake you've NOT learned from here is > "rarp". DCHP does far more than tell a host was address it should use. > (yes, I've called for the IPng WG member's execution, reanimation, and > re-execution, several times.) > > --Ricky > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From David_Hankins at isc.org Thu Feb 5 17:55:16 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 5 Feb 2009 15:55:16 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> Message-ID: <20090205235516.GD8174@isc.org> On Thu, Feb 05, 2009 at 11:42:27PM +0100, Iljitsch van Beijnum wrote: > On 5 feb 2009, at 22:44, Ricky Beam wrote: >> I've lived quite productively behind a single IPv4 address for nearly 15 >> years. > > So you were already doing NAT in 1994? Then you were ahead of the curve. Ahh, the 90s. No need for NAT yet. http://en.wikipedia.org/wiki/SOCKS The world was smaller then. Or maybe there was just less in it? >> This is the exact same bull**** as the /8 allocations in the early days of >> IPv4. The man is correct: This is class-based allocations all over again. On purpose. After watching class-based allocations crash and burn. One who believes history repeats itself will think that this will only end in pain. If anything, only the timescales change. One who believes themselves to be above the mistakes of the past will of course think this plan is totally without precedent for flaw. Never between these two beliefs shall we meet. I think Ricky and Iljitsch are discovering this. >> Why do people avoid and resist IPv6... because it was designed with blind >> ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 >> networks.) Dooming us to repeating ALL those mistakes again. > >> Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you >> don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from >> here is "rarp". DCHP does far more than tell a host was address it should >> use. Actually it goes further back than rarp; IPv6 RA is actually more closely related to IPv4 ICMP Router Advertisements (itself a very RIP-like way to give only default routes), extended to also carry RIP-like local-prefix routes. Let's just say it's a slightly restricted (feature-limited?) RIP. So, start with that and add RARP- like features with (more complicated) client-based algorithms, and you've got the picture. But yeah, in that the static->RARP->BOOTP->DHCP progression was a dialogue between operators and IETF, IPv6 has basically thrown that dialogue out with the bathwater, and we're having it all over again. Fun! -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From David_Hankins at isc.org Thu Feb 5 18:01:15 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 5 Feb 2009 16:01:15 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498B7253.1020008@brightok.net> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <49C38A17-90FE-4C9F-9333-82DD1D51BDCC@consultant.com> <498B7253.1020008@brightok.net> Message-ID: <20090206000115.GE8174@isc.org> On Thu, Feb 05, 2009 at 05:12:19PM -0600, Jack Bates wrote: > Operationally, this has been met from my experience. In fact, all of these > items are handled with stateless DHCPv6 in coordination with SLAAC. > Stateful DHCPv6 seems to be limited with some vendors, but unless they plan > to do proxy-nd, I'm not sure they'll gain much except for end system > compatibility. SLAAC fails in the end because you cannot predict what address the client will choose. So it fails in scenarios where enforcing network policy is important. The point of the excercise is that DHCPv4 and DHCPv6 are both supersets of network management needs. RA is a vast subset. Herein lies the rub; you have to implement both anyway because a client can not predict what network(s) it is going to be used in. Nobody wins. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From haegar at sdinet.de Thu Feb 5 18:11:13 2009 From: haegar at sdinet.de (Sven-Haegar Koch) Date: Fri, 6 Feb 2009 01:11:13 +0100 (CET) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090205220614.GA18219@jeeves.rigozsaurus.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <20090205220614.GA18219@jeeves.rigozsaurus.com> Message-ID: On Thu, 5 Feb 2009, John Osmon wrote: > On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote: > > [...] I've lived quite productively behind a single IPv4 address for > > nearly 15 years. I've run 1000 user networks that only used one IPv4 > > address for all of them. I have 2 private /24's using a single public > > IPv4 address right now -- as they have been for 6+ years. Yet, in the new > > order, you're telling me I need 18 billion, billion addresses to cover 2 > > laptops, a Wii, 3 tivos, a router, and an access point? > > Thank you. Your ability to live with proxied/NATed Internet access has > helped stave off the problems we're seeing now. > > The flip side shows up when Nintendo creates a cool new protocol for the Wii > that requires Internet access. You Wii won't be able to participate > until you teach your proxy/NAT box about the new protocol. What's the difference to firewalling without NAT? (Noone should connect their (home) network without at least inbound filtering) There I have to wait for the firewall box to support connection tracking for the new (broken) protocol. If the end-users really get public addresses for their WII and game-PCs, do you really think they won't just open the box totally in their firewall/router and catch/create even more problems? c'ya sven -- The lights are fading out, once more... From David_Hankins at isc.org Thu Feb 5 18:14:21 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 5 Feb 2009 16:14:21 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> Message-ID: <20090206001420.GF8174@isc.org> On Thu, Feb 05, 2009 at 06:15:02PM -0500, Ricky Beam wrote: >> You might like to review the DHCPv6 specification and try some of its >> implementations. Joe is being a little overzealous. Unfortunately, there are very few DHCPv6 clients in the wild today. I think this has grown slightly since the last time I've had good information on it; Windows Vista, DOCSIS 3.0, Solaris and other platform specific unixes (unsure of all the right names and versions). Most free unixes have to be manhandled to install a client. The truth is it is actually not very likely that you can build an IPv6 network today using DHCPv6, unless you have large populations of those systems. Most IPv6 deployments today use SLAAC to get an address, and rely upon DHCPv4 to deliver configuration state (even IETF meetings do this). Still, it isn't bad to have a DHCPv6 server running to hand out some IPv6 addresses for configuration state now and again, so Joe is not entirely wrong. > I can recall many posts over the years from the IPng WG telling people they > didn't need DHCP. There is no need to recall! Subscribe to any IETF mailing list, and be assured you will still hear the same thing. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jfbeam at gmail.com Thu Feb 5 18:15:04 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 05 Feb 2009 19:15:04 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> Message-ID: On Thu, 05 Feb 2009 17:42:27 -0500, Iljitsch van Beijnum wrote: >> I've lived quite productively behind a single IPv4 address for nearly >> 15 years. > > So you were already doing NAT in 1994? Then you were ahead of the curve. "NAT" didn't exist in '94. But, Yes. And, Yes. I had several computers networked behind one with a dialup (PPP) connection. And, as you'd expect, it was messy. >> I've run 1000 user networks that only used one IPv4 address for all of >> them. > > But how is that relevant for the discussion at hand? Is your point that > if 1000 users can share an IPv4 address, 1000 users should share an IPv6 > address? The point is... even large enterprises don't *need* 18 billion, billion addresses to get anything done. I see IPv6 address space being carved out in huge chunks for reasons that equate to little more than because the total space is "inexhaustable". This is the exact same type of mis-management that plagues us from IPv4's early allocations. > Now of course that seems wasteful, ... > and you get to generate an address from a prefix through a function that > gives you the same address without requiring anyone to remember that > address, which is also useful. Well, it is extremely wasteful. If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address. We do that already with IPv4. Why do we need to waste so much space with such a sparse address plan? We don't. But since IPv6 is H.U.G.E., "might as well." And face reality, many people have enough trouble remembering IPv4 addresses -- even when it's simplified to a /24 prefix plus 3 digit number. They will have an even harder time remembering a 48bit or 64bit MAC. Do you remember the MAC addresses of ANY of the NICs on your lan(s)? >> This is the exact same bull**** as the /8 allocations in the early days >> of IPv4. > > Oh no. ... Yes. It. Is. We have this incomprehensibly huge address space that we cannot possibly, EVER, use up, so let's divide it on ridiculously huge boundries. >> The idea of the "connected home" is still nowhere near *that* connected; > > It took us 15 years to get this far with IPv6. There is no IPv7 on the > horizon currently, so even if we start that tomorrow we'll have to get > by with IPv6 (and IPv4...) until about 2024. I'm pretty sure we'll be > *that* connected by that time. I'm not. I'll be very surprised if IPv6 has been universally adopted by then. I'm not sure we'll be completely out of IPv4 space by then. > IPv6 changes too much but it doesn't fix enough. It's not even that. Had they simply not ignored, and out-right dismissed as "wrong", the way networks were being run, then we wouldn't have the mess we have today. I pick on autoconfig because it's the simplest bit of stupid on their part... we have Stateless Autoconfiguration, *jedi hand wave*, you don't need DHCP. It was bull the instant they said it. You don't use DHCP. Well, good for you. There are hunreds of thousands of people who do. We appreciate you telling us we don't need the technology we need. (It's the "I don't use it so nobody else needs to, either" attitude that has given us a whole bunch of things to re-invent for IPv6.) --Ricky From robert at ufl.edu Thu Feb 5 18:19:37 2009 From: robert at ufl.edu (Robert D. Scott) Date: Thu, 5 Feb 2009 19:19:37 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <20090205220614.GA18219@jeeves.rigozsaurus.com> Message-ID: <016f01c987f0$98865110$c992f330$@edu> Wii should not even consider developing " a cool new protocol for the Wii" that is not NAT compliant via V4 or V6. And if they do, we should elect a NANOG regular to go "POSTAL" and handle the problem. The solution to many of these networking conundrums should rest with the application people, and NOT the network people. While I am ranting, my other pet peeve are proprietary protocols that the developer cannot take another couple of hours to provide a decoder for. If you develop the protocol any of the developers at the Wireshark group would help with the decode plugin. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Sven-Haegar Koch [mailto:haegar at sdinet.de] Sent: Thursday, February 05, 2009 7:11 PM To: John Osmon Cc: NANOG list Subject: Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] On Thu, 5 Feb 2009, John Osmon wrote: > On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote: > > [...] I've lived quite productively behind a single IPv4 address for > > nearly 15 years. I've run 1000 user networks that only used one IPv4 > > address for all of them. I have 2 private /24's using a single public > > IPv4 address right now -- as they have been for 6+ years. Yet, in the new > > order, you're telling me I need 18 billion, billion addresses to cover 2 > > laptops, a Wii, 3 tivos, a router, and an access point? > > Thank you. Your ability to live with proxied/NATed Internet access has > helped stave off the problems we're seeing now. > > The flip side shows up when Nintendo creates a cool new protocol for the Wii > that requires Internet access. You Wii won't be able to participate > until you teach your proxy/NAT box about the new protocol. What's the difference to firewalling without NAT? (Noone should connect their (home) network without at least inbound filtering) There I have to wait for the firewall box to support connection tracking for the new (broken) protocol. If the end-users really get public addresses for their WII and game-PCs, do you really think they won't just open the box totally in their firewall/router and catch/create even more problems? c'ya sven -- The lights are fading out, once more... From owen at delong.com Thu Feb 5 18:21:12 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Feb 2009 16:21:12 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <04044622-0790-45EF-A93D-EED1D17B10D3@hopcount.ca> References: <20090205030522.13D152B21F3@mx5.roble.com> <200902050345.n153jcff081338@drugs.dv.isc.org> <75cb24520902042240n2be826cdx83ada59b7872e0e8@mail.gmail.com> <018801c9878f$0256dd10$07049730$@com> <75cb24520902050634w53666517k20aae8ba09ffed94@mail.gmail.com> <04044622-0790-45EF-A93D-EED1D17B10D3@hopcount.ca> Message-ID: On Feb 5, 2009, at 11:06 AM, Joe Abley wrote: > > On 5-Feb-2009, at 06:34, Christopher Morrow wrote: > >> to be fair, there are 3 options for multihoming today in v6 (three >> sanctioned by the IETF, not ordered in any order, not including >> discussion about goodness/badness/oh-god-no-ness of these) >> 1) multiple addresses on each device, one per provider >> 2) shim-6 >> 3) HIP (still in development, as I recall) > > 4) Obtain PA space and do what you're doing with v4. > > 5) Obtain PI space and do what you're doing with v4. > > (4) is problematic because filtering long prefixes in v6 seems to be > more energetic than it is in v4. (5) is problematic if you don't > qualify for PI space. > Note, however, that the bar for (5) is VERY low if you are multi-homed. I would not be opposed to lowering it even further, but, there does not at this time seem to be community consensus to do so. Owen From jabley at hopcount.ca Thu Feb 5 18:30:12 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 5 Feb 2009 16:30:12 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090206001420.GF8174@isc.org> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> <20090206001420.GF8174@isc.org> Message-ID: On 5-Feb-2009, at 16:14, David W. Hankins wrote: > The truth is it is actually not very likely that you can build an > IPv6 network today using DHCPv6, unless you have large populations > of those systems. The particular example I've been working with is with a JUNOSe server and an IOS client which, as a solution for business DSL service, seems deployable. > [...] Joe is not entirely wrong. Hooray! :-) Joe From Mark_Andrews at isc.org Thu Feb 5 18:36:25 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 06 Feb 2009 11:36:25 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: Your message of "Fri, 06 Feb 2009 01:11:13 BST." Message-ID: <200902060036.n160aPb5099288@drugs.dv.isc.org> In message , Sven-Haegar Ko ch writes: > If the end-users really get public addresses for their WII and game-PCs, > do you really think they won't just open the box totally in their > firewall/router and catch/create even more problems? You mean they don't already list as the DMZ address. :-) WII's should be able to be directly connected to the network without any firewall. If they can't be then they are broken. > c'ya > sven -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From josmon at rigozsaurus.com Thu Feb 5 18:48:48 2009 From: josmon at rigozsaurus.com (John Osmon) Date: Thu, 5 Feb 2009 17:48:48 -0700 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <20090205220614.GA18219@jeeves.rigozsaurus.com> Message-ID: <20090206004848.GE4740@jeeves.rigozsaurus.com> This is falling outside of the IPv6/RFC-1918 discussion, so I'll only answer questions with questions... If there's need for a real discussion, I'll let someone change the subject, and continue on... On Fri, Feb 06, 2009 at 01:11:13AM +0100, Sven-Haegar Koch wrote: [...] > > The flip side shows up when Nintendo creates a cool new protocol for the Wii > > that requires Internet access. You Wii won't be able to participate > > until you teach your proxy/NAT box about the new protocol. > > What's the difference to firewalling without NAT? (Noone should connect > their (home) network without at least inbound filtering) There I have to > wait for the firewall box to support connection tracking for the new > (broken) protocol. Why do I need an "Internet breaker" (firewall) to do connection tracking? Doesn't the host computer's software stack do that when an inbound packet arrives? Why do I need a separate box to do that work with I trust my host? > If the end-users really get public addresses for their WII and game-PCs, > do you really think they won't just open the box totally in their > firewall/router and catch/create even more problems? That's an issue of trusting the host... Note: All questions are hypothetical. No packets were harmed in the production of this hyperbolic response... From josmon at rigozsaurus.com Thu Feb 5 18:54:48 2009 From: josmon at rigozsaurus.com (John Osmon) Date: Thu, 5 Feb 2009 17:54:48 -0700 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <200902060036.n160aPb5099288@drugs.dv.isc.org> References: <200902060036.n160aPb5099288@drugs.dv.isc.org> Message-ID: <20090206005448.GF4740@jeeves.rigozsaurus.com> On Fri, Feb 06, 2009 at 11:36:25AM +1100, Mark Andrews wrote: [...] > WII's should be able to be directly connected to the network > without any firewall. If they can't be then they are broken. Amen brother Mark! Can I get a hallelujah from the chorus? (Meanwhile, I'll continue to leave my Wii outside of the trusted MAC address pool in DHCP -- so it'll get an RFC-1918 address, rather the a holy "true" IP.) From steve at ibctech.ca Wed Feb 4 02:52:25 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 4 Feb 2009 03:52:25 -0500 (EST) Subject: [Update] Re: New ISP to market, BCP 38, and new tactics Message-ID: <1317.64.39.177.10.1233737545.squirrel@webmail.ibctech.ca> > On 4/02/2009, at 2:43 PM, Steve Bertrand wrote: > >> Nathan Ward wrote: >>> On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: >>> >>>> - Currently, (as I write), I'm migrating my entire core from IPv4 to >>>> IPv6. I've got the space, and I love to learn, so I'm just lab-ing >>>> it up >>>> now to see how things will flow with all iBGP v4 routes being >>>> advertised/routed over v6. >>> >>> >>> Don't advertise v4 prefixes in v6 sessions, keep them separate. This entire discussion went off topic, in regards to bcp and filtering. Off-list, I had someone point out: http://tools.ietf.org/html/draft-kumari-blackhole-urpf-02 ...which is EXACTLY in line with what my end goal was originally, and by reading it, I feel as if I was getting there free-hand. This document helps standardize things a bit, and I will follow it to a certain degree, whether or not it is considered under the standards track, or IANA considers approving the request for the BGP Extended Communities Attribute. What really spooks me after the last week of research, is how easy it would be for a client under my control (or hosts under control of an attacker) to stage/originate an inconspicuous attack (to anywhere), using standard IDS insertion/evasion tactics (even via a tunnel) from hosts within a network bordering my AS. Just by manually viewing logs of ingress traffic, there are just too many holes. We're too small to mitigate a bandwidth-saturating attack inbound, but I can guarantee that I will ensure to the best of my ability that our network won't be part of any form of attack on yours. Thank you everyone, for all of the off, and on-list feedback. Steve From imb at protected-networks.net Thu Feb 5 19:23:50 2009 From: imb at protected-networks.net (Michael Butler) Date: Thu, 05 Feb 2009 20:23:50 -0500 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <1317.64.39.177.10.1233737545.squirrel@webmail.ibctech.ca> References: <1317.64.39.177.10.1233737545.squirrel@webmail.ibctech.ca> Message-ID: <498B9126.3020308@protected-networks.net> Steve Bertrand wrote: > This entire discussion went off topic, in regards to bcp and filtering. > > Off-list, I had someone point out: > > http://tools.ietf.org/html/draft-kumari-blackhole-urpf-02 > > ...which is EXACTLY in line with what my end goal was originally, and by > reading it, I feel as if I was getting there free-hand. This document > helps standardize things a bit, .. This technique, and a whole lot more, may also be found in book form: Router Security Strategies: Securing IP Network Traffic Planes by Gregg Schudel and David J. Smith Cisco Press, December 2007 ISBN 978-1-58705-336-8 (paper-back) Don't expect to get through it in one sitting; it's ~600+ pages ;-) Michael From gherbert at retro.com Thu Feb 5 19:40:26 2009 From: gherbert at retro.com (George William Herbert) Date: Thu, 05 Feb 2009 17:40:26 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090205021907.GA74285@ussenterprise.ufp.org> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> <20090205021907.GA74285@ussenterprise.ufp.org> Message-ID: <200902060140.n161eRCr009271@kw.retro.com> Leo writes: >Customers don't want static addresses. > >They want DNS that works, with their own domain names, forward and >reverse. > >They want renumbering events to be infrequent, and announced in >advance. > >They want the box the cable/dsl/fios provider to actually work, >that is be able to do really simple stuff without having to buy >another stupid box to put behind it. > >None of these require static, and in fact I'd think it would be >easier to get it right than it would be to do statics for most >providers. But, I must be wrong, since the only solution virtually >every provider offers is to "move up" to "a static IP". I'm one of the geeky fringe here, obviously, but it's hard for my nameservers at home to not be static IPed be it IPv4 or v6. There are plenty of possible solutions, but they all involve more effort by the ISP or DNS provider... I and they can put in that effort, but just provisioning me statics is a lot easier, and that's what everyone has done so far. Nothing about the IPv6 transition on the transport end changes the provisioning effort / logistics / technical support difficulty issues associated with this. If you believe that geek houses are enough of an outlier to not worry about, consider the million or so internet connected small businesses who do their own DNS... Perhaps there are better ways to do all of this from the start. But IPv6 is not helping any of the ways we have evolved to deal with it. Perhaps it's time for some actual network operators and equipment vendors to go talk on the side about IPv7 and making our lives easier rather than harder. I urge everyone who is involved in the back-room "bring tar and feathers to next IETF meeting" discussions to do this instead. I really don't care how many bits are wasted on what - I want DNS, routing, endpoint mobility, multihoming, NAT, et al to work. If that means bigger packets or wasted address space so be it. We have pipe bandwidth and Moore's Law growth to work with here. Having to patch the net together for the next decade with baling wire and string because a bunch of non-operators got to set IPv6 up to be a more perfect way forward is not scaling. And 20 years between protocol design and rollout is absurd and insulting. -george william herbert gherbert at retro.com From David_Hankins at isc.org Thu Feb 5 20:32:26 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 5 Feb 2009 18:32:26 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> <20090206001420.GF8174@isc.org> Message-ID: <20090206023226.GB5164@isc.org> On Thu, Feb 05, 2009 at 04:30:12PM -0800, Joe Abley wrote: > The particular example I've been working with is with a JUNOSe server and > an IOS client which, as a solution for business DSL service, seems > deployable. Yes! Sorry, I just try to emit a little more skepticism about pervasive client support for DHCPv6 in jubliant encouragements of DHCPv6 operational experiments and deployment. >> [...] Joe is not entirely wrong. > > Hooray! :-) I am seriously considering admitting I know you. :) -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jbates at brightok.net Thu Feb 5 20:48:24 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 05 Feb 2009 20:48:24 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <200902060140.n161eRCr009271@kw.retro.com> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <6b822fc7bca8dece2adcd10fdf678c6b@smtp.arbitraryconstant.com> <498A3CA5.6060801@internode.com.au> <5b608e4e6a9e5bd66db18689248d4075@smtp.arbitraryconstant.com> <498A40C1.8060702@internode.com.au> <20090205021907.GA74285@ussenterprise.ufp.org> <200902060140.n161eRCr009271@kw.retro.com> Message-ID: <498BA4F8.3040606@brightok.net> George William Herbert wrote: > Perhaps there are better ways to do all of this from the start. > But IPv6 is not helping any of the ways we have evolved to deal > with it. > IPv6 does just fine with dynamic addressing and with static addressing. I'm not sure what your problem is. An ISP can still assign static addressing, and in fact, most ISP layouts will be *more* static than they were with IPv4. However, it will depend on their implementations and what they want. As was explained to me, there were many BIG providers definitely putting their $0.02 in concerning IPv6. That's actually where full blown IPv6 comes in, btw. Something to do with DOCSIS from what I understand; though that's way out of the scope of my telco self. I play with copper. Jack From trejrco at gmail.com Thu Feb 5 20:52:45 2009 From: trejrco at gmail.com (TJ) Date: Thu, 5 Feb 2009 21:52:45 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090206000115.GE8174@isc.org> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <49C38A17-90FE-4C9F-9333-82DD1D51BDCC@consultant.com> <498B7253.1020008@brightok.net> <20090206000115.GE8174@isc.org> Message-ID: <00ca01c98805$fe530f00$faf92d00$@com> >So it fails in scenarios where enforcing network policy is important. If the policy is address specific, perhaps. If the policy is segment specific, no prob. /TJ PS - for emphasis, I am not arguing strictly for or against either SLAAC or DHCPv6. Both can work, and IMHO should be allowed to do so where desirable. From simon at darkmere.gen.nz Thu Feb 5 20:59:54 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Fri, 6 Feb 2009 15:59:54 +1300 (NZDT) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> Message-ID: On Thu, 5 Feb 2009, Ricky Beam wrote: > telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 > tivos, a router, and an access point? You have more computing power in your house than the Fortune 500 did 40 years ago to manage their entire billing, payroll etc. They had thousands of people and paid millions of dollars per year just to make sure that scarce resource was not wasted. You use it for watching TV shows and browsing the web a few hours per day. As others have pointed out giving every person on the planet a /56 and every business a /48 is only going to take up 0.01% of the total IP space. Allocating 0.01% of space to an "experiment in abundance" which will probably turn out to be enough space than will ever be needed this century seems a good risk to me. Sure we could have allocated just 0.00001% of space to the experiment instead but then plug-and-play might not work out of the box or people would have to apply and pay for larger network spaces or I'd only get one network in my house ( and never get my SIP phone to work cause of NAT ). You may find this article interesting ( especially the first page ): "The sysadmin?s mantra: Manage time, think ?abundance? and softly does it" http://www.computerworld.com.au/article/272429/sysadmin_mantra_manage_time_think_abundance_softly_does_it -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From randy at psg.com Fri Feb 6 00:00:59 2009 From: randy at psg.com (Randy Bush) Date: Fri, 06 Feb 2009 14:00:59 +0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <016f01c987f0$98865110$c992f330$@edu> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <20090205220614.GA18219@jeeves.rigozsaurus.com> <016f01c987f0$98865110$c992f330$@edu> Message-ID: > Wii should not even consider developing " a cool new protocol for the Wii" > that is not NAT compliant via V4 or V6. what is "nat compliant?" randy From matthew at eeph.com Fri Feb 6 00:43:38 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Thu, 05 Feb 2009 22:43:38 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <20090205220614.GA18219@jeeves.rigozsaurus.com> <016f01c987f0$98865110$c992f330$@edu> Message-ID: <498BDC1A.8040403@eeph.com> Randy Bush wrote: >> Wii should not even consider developing " a cool new protocol for the Wii" >> that is not NAT compliant via V4 or V6. > > what is "nat compliant?" > Quite unfortunately, that has come to mean something. Specifically, TCP or UDP (and no other IP protocol numbers) and application protocols that don't depend on their locally-derived host addresses as having any meaning to anyone else. Or, in other words, "whatever the NAT maker thought was enough in order to sell boxes", which mostly means "you can look up addresses in the DNS and open http and https connections to them, and if you're lucky some of your gaming and video streaming will work too". Matthew Kaufman From matthew at eeph.com Fri Feb 6 00:50:20 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Thu, 05 Feb 2009 22:50:20 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <200902060036.n160aPb5099288@drugs.dv.isc.org> References: <200902060036.n160aPb5099288@drugs.dv.isc.org> Message-ID: <498BDDAC.7060405@eeph.com> Mark Andrews wrote: > WII's should be able to be directly connected to the network > without any firewall. If they can't be then they are broken. As I'm sure you know, you can tell the difference between an Internet evangelist and someone who mans the support lines by how they feel about "X should be able to be directly connected to the network without any firewall". "...then they are broken" applied to 4.3 BSD-running VAXen and Sun 3's in 1988, and neither the frequency of attacks launched nor the number of exploitable bugs in network stacks or network-packet-ingesting application programs has gone down since then. Matthew Kaufman From vixie at isc.org Fri Feb 6 01:20:01 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 06 Feb 2009 07:20:01 +0000 Subject: v6 & DSL / Cable modems In-Reply-To: (Ricky Beam's message of "Thu\, 05 Feb 2009 18\:15\:02 -0500") References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> Message-ID: "Ricky Beam" writes: > ... In the mid-80's, /8's were handed out like candy because there were > "lots of address space" and "we'll never use it all." ... ahem. allow me to introduce myself. i was alive and actively using the internet in the mid-80's, and when we got our /8 it was justified very differently than what you said. we had field offices in 100 countries and we had 130,000 employees and our internal network spanned five continents. (we thought long and hard about netmasks before we started rolling it out.) it was not true in Digital Equipment Corporation's (DEC's) case that a /8 was "handed out like candy" or that the justification was anything like "lots of address space" or "we'll never use it all". > IPv6 was designed to "not need DHCP." DHCPv6 has come about since people > need more than just an address from "autoconfiguration". IPv6 promised a lot of things, like no-forklift insertion of IPv6 into the existing IPv4 network, and "some hosts, such as printers, might need never be upgraded". a lot of those promises were trash, just stuff that folks had to say to get through whatever they were getting through. as much as i'd like a time machine to go back and whisper "yo, dude, that's *so* not gonna happen" in some ears, what matters to us now is not what IPv6 was promised to be or even what it could have been but instead: what it could now become. > I can recall many posts over the years from the IPng WG telling people > they didn't need DHCP. some people drink their own cool-aid. advice: get better at ignoring them. i dislike the compromises and mistakes other people will make when faced with NAT, and i don't want to live in a world dominated by products and services containing those compromises or those mistakes. i want end-to-end so i can stop budgeting half a day for each VoIP phone i send home with an employee. i don't want to remap addresses mid-path because i just know that the best programmers are the lazy ones and they WILL encode endpoint IP addrs in their sessions no matter what we tell them or how much it hurts us all. IPv6 coulda been and shoulda been lots of better things than we're getting, but due to circumstances beyond our present control, it's what we've got to work with, and it could still avoid a lot of problems whose alternative costs could be higher (NAT, double NAT, triple NAT, IPv4 markets, IPv4 black markets, IPv4 route piracy, explosive deaggregation, to name some). the most fundamental re-think required to wrap a brain around IPv6 compared to IPv4 is that we will never run out of addresses again unless someone (ignorantly) assigns a /125 to a LAN and needs more than 7 hosts thereon, or something similar. that part of IPv4's dark past will not follow us to IPv6 and we can stop thinking all related or derivative thoughts, for IPv6. but, and this matters so please pay attention, IPv6 does nothing to solve the routing table problem that IPv4 has had since 1995 or so, and IPv6 can amplify this part of IPv4's dark past and make it much worse since there can be so many more attached devices. the fundamental implication is, forget about address space, it's paperwork now, it's off the table as a negotiating item or any kind of constraint. but the size of the routing table is still a bogeyman, and IPv6 arms that bogeyman with nukes. -- Paul Vixie From Mark_Andrews at isc.org Fri Feb 6 02:00:44 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 06 Feb 2009 19:00:44 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: Your message of "Thu, 05 Feb 2009 22:50:20 -0800." <498BDDAC.7060405@eeph.com> Message-ID: <200902060800.n1680inS015933@drugs.dv.isc.org> In message <498BDDAC.7060405 at eeph.com>, Matthew Kaufman writes: > Mark Andrews wrote: > > WII's should be able to be directly connected to the network > > without any firewall. If they can't be then they are broken. > > As I'm sure you know, you can tell the difference between an Internet > evangelist and someone who mans the support lines by how they feel about > "X should be able to be directly connected to the network without any > firewall". > > "...then they are broken" applied to 4.3 BSD-running VAXen and Sun 3's > in 1988, and neither the frequency of attacks launched nor the number of > exploitable bugs in network stacks or network-packet-ingesting > application programs has gone down since then. > > Matthew Kaufman I still believe that despite having to deal with all these issues at the time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From bjorn at mork.no Fri Feb 6 03:00:02 2009 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 06 Feb 2009 10:00:02 +0100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090205235516.GD8174@isc.org> (David W. Hankins's message of "Thu, 5 Feb 2009 15:55:16 -0800") References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> Message-ID: <877i44ey99.fsf@nemi.mork.no> "David W. Hankins" writes: > On Thu, Feb 05, 2009 at 11:42:27PM +0100, Iljitsch van Beijnum wrote: >> On 5 feb 2009, at 22:44, Ricky Beam wrote: >>> I've lived quite productively behind a single IPv4 address for nearly 15 >>> years. >> >> So you were already doing NAT in 1994? Then you were ahead of the curve. > > Ahh, the 90s. No need for NAT yet. > > http://en.wikipedia.org/wiki/SOCKS Does anyone remember http://en.wikipedia.org/wiki/The_Internet_Adapter ? People used to share the Internet connected *hosts*. Address sharing was implicit. Bj?rn From paul at jakma.org Fri Feb 6 04:26:30 2009 From: paul at jakma.org (Paul Jakma) Date: Fri, 6 Feb 2009 10:26:30 +0000 (GMT) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498A3514.1050608@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> Message-ID: On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: > DHCP(v6). Setting the idea in people's heads that a /64 IS going > to be their own statically is insane and will blow out provider's > own routing tables more than is rational. Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be "for a long time" with IPv6). So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64. Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for "hierarchical routing of bits past 64 is highly rare"). Think of IPv6 as a 64bit network address + host address. At least for now. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson From mmc at internode.com.au Fri Feb 6 04:42:54 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 6 Feb 2009 21:12:54 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> Message-ID: <0F8E47C2-B4B7-459A-862D-A59FFD7E556F@internode.com.au> My comment was regarding customers believing that they were going to, by default, get a statically allocated range, whatever the length. If most customers get dynamically assigned (via PD or other means) then the issue is not a major one. MMC On 06/02/2009, at 8:56 PM, Paul Jakma wrote: > On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: > >> DHCP(v6). Setting the idea in people's heads that a /64 IS going >> to be their own statically is insane and will blow out provider's >> own routing tables more than is rational. > > Routing table size will be a function of the number of customers - > *not* the prefix length assigned to them (for so long as address > space is sufficiently sparsely allocated that there's a 1:1 mapping > from customer to prefix - which should be "for a long time" with > IPv6). > > So (within that longer term constraint) it doesn't matter if you're > allocating your customer a /48, /56 or /64. > > Indeed, what you're suggesting - smaller-than-64 allocations - > *would* increase routing table sizes. With your proposal those > indexes would increase greatly in depth (and possibly other space > increases due to not being able to optimise for "hierarchical > routing of bits past 64 is highly rare"). > > Think of IPv6 as a 64bit network address + host address. At least > for now. > > regards, > -- > Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A > Fortune: > If you don't have a nasty obituary you probably didn't matter. > -- Freeman Dyson -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From cidr-report at potaroo.net Fri Feb 6 05:00:05 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Feb 2009 22:00:05 +1100 (EST) Subject: BGP Update Report Message-ID: <200902061100.n16B05H6082189@wattle.apnic.net> BGP Update Report Interval: 05-Jan-09 -to- 05-Feb-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7643 132303 2.7% 225.0 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 2 - AS9583 96240 1.9% 64.9 -- SIFY-AS-IN Sify Limited 3 - AS6629 49704 1.0% 753.1 -- NOAA-AS - NOAA 4 - AS35805 41741 0.8% 111.9 -- UTG-AS United Telecom AS 5 - AS4323 31198 0.6% 7.3 -- TWTC - tw telecom holdings, inc. 6 - AS6389 30402 0.6% 6.9 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 7 - AS20115 27730 0.6% 13.1 -- CHARTER-NET-HKY-NC - Charter Communications 8 - AS209 26943 0.5% 9.4 -- ASN-QWEST - Qwest Communications Corporation 9 - AS6458 25467 0.5% 52.2 -- Telgua 10 - AS21433 24763 0.5% 189.0 -- ACCENTUREFSSC Accenture London Delivery Centre 11 - AS14420 24676 0.5% 99.5 -- ANDINATEL S.A. 12 - AS5050 23840 0.5% 404.1 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - AS17488 22706 0.5% 14.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 14 - AS8151 22431 0.5% 15.0 -- Uninet S.A. de C.V. 15 - AS30306 22122 0.4% 4424.4 -- AfOL-Sz-AS 16 - AS1785 21793 0.4% 11.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 17 - AS30890 21423 0.4% 47.7 -- EVOLVA Evolva Telecom 18 - AS33783 18849 0.4% 119.3 -- EEPAD 19 - AS8452 18817 0.4% 15.0 -- TEDATA TEDATA 20 - AS12500 18185 0.4% 4546.2 -- RCS-AS RCS Autonomus System TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30287 6672 0.1% 6672.0 -- ALON-USA - ALON USA, LP 2 - AS12500 18185 0.4% 4546.2 -- RCS-AS RCS Autonomus System 3 - AS30306 22122 0.4% 4424.4 -- AfOL-Sz-AS 4 - AS48129 3071 0.1% 3071.0 -- IRBIS-TELECOMMUNICATIONS-AS IRBIS Telecommunications Ltd. 5 - AS23917 2837 0.1% 2837.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 6 - AS32753 2567 0.1% 2567.0 -- GLOBEOP-FINANCIAL-SERVICES-NYC1 - GlobeOp Financial Services 7 - AS28194 7026 0.1% 2342.0 -- 8 - AS30969 16656 0.3% 2082.0 -- TAN-NET TransAfrica Networks 9 - AS19017 1962 0.0% 1962.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 10 - AS41382 1932 0.0% 1932.0 -- TELEPORT-AS Teleport LLC Network AS 11 - AS30095 3183 0.1% 1591.5 -- AS-30095 - Group M Worldwide, Inc. 12 - AS29427 3168 0.1% 1584.0 -- AZM-AS Mercury Telecom 13 - AS45122 1580 0.0% 1580.0 -- JASPACE-AS-ID-AP PT. JASPACE NET 14 - AS10806 6111 0.1% 1527.8 -- AFP-NET - AGENCE FRANCE PRESSE 15 - AS32398 12631 0.2% 1403.4 -- REALNET-ASN-1 16 - AS5033 13607 0.3% 1360.7 -- ISW - Internet Specialties West Inc. 17 - AS29224 2652 0.1% 1326.0 -- HELLMANN Hellmann Worldwide Logistics GmbH & Co KG 18 - AS25970 7569 0.1% 1261.5 -- IAC - IAC Services LLC 19 - AS44265 13266 0.3% 1206.0 -- SMOLTELECOM-NET Smoltelecom Ltd AS peering 20 - AS24228 7649 0.1% 1092.7 -- BARNETWORK-AP BarNetwork Pty Limited TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 23597 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 144.36.245.0/24 21213 0.4% AS21433 -- ACCENTUREFSSC Accenture London Delivery Centre 3 - 210.214.151.0/24 18829 0.3% AS9583 -- SIFY-AS-IN Sify Limited 4 - 124.7.201.0/24 17774 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 192.35.129.0/24 16573 0.3% AS6629 -- NOAA-AS - NOAA 6 - 192.102.88.0/24 16419 0.3% AS6629 -- NOAA-AS - NOAA 7 - 198.77.177.0/24 16327 0.3% AS6629 -- NOAA-AS - NOAA 8 - 64.162.116.0/24 13558 0.2% AS5033 -- ISW - Internet Specialties West Inc. 9 - 41.204.2.0/24 12464 0.2% AS32398 -- REALNET-ASN-1 10 - 221.135.80.0/24 10902 0.2% AS9583 -- SIFY-AS-IN Sify Limited 12 - 212.85.223.0/24 10869 0.2% AS30306 -- AfOL-Sz-AS 13 - 212.85.220.0/24 10866 0.2% AS30306 -- AfOL-Sz-AS 14 - 192.12.120.0/24 10337 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 196.27.104.0/21 8100 0.1% AS30969 -- TAN-NET TransAfrica Networks 16 - 196.27.108.0/22 8036 0.1% AS30969 -- TAN-NET TransAfrica Networks 17 - 190.152.103.0/24 7801 0.1% AS27757 -- ANDINATEL S.A. 18 - 202.83.176.0/21 7577 0.1% AS24228 -- BARNETWORK-AP BarNetwork Pty Limited 19 - 202.92.235.0/24 6864 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 20 - 65.214.174.0/24 6672 0.1% AS30287 -- ALON-USA - ALON USA, LP Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 6 05:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Feb 2009 22:00:03 +1100 (EST) Subject: The Cidr Report Message-ID: <200902061100.n16B03S8082184@wattle.apnic.net> This report has been generated at Fri Feb 6 21:14:00 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 30-01-09 286408 178279 31-01-09 286620 178119 01-02-09 286594 178154 02-02-09 286601 178111 03-02-09 286348 177909 04-02-09 285957 178007 05-02-09 286084 177780 06-02-09 285832 177674 AS Summary 30576 Number of ASes in routing system 12994 Number of ASes announcing only one prefix 4375 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89825024 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 06Feb09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 285699 177676 108023 37.8% All ASes AS6389 4375 356 4019 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4221 1751 2470 58.5% TWTC - tw telecom holdings, inc. AS209 2830 1267 1563 55.2% ASN-QWEST - Qwest Communications Corporation AS4766 1766 506 1260 71.3% KIXS-AS-KR Korea Telecom AS17488 1521 362 1159 76.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1201 233 968 80.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1007 61 946 93.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1485 608 877 59.1% Uninet S.A. de C.V. AS8452 1036 267 769 74.2% TEDATA TEDATA AS11492 1224 485 739 60.4% CABLEONE - CABLE ONE, INC. AS1785 1828 1112 716 39.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 946 239 707 74.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS3356 1140 490 650 57.0% LEVEL3 Level 3 Communications AS18101 751 144 607 80.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS18566 1061 466 595 56.1% COVAD - Covad Communications Co. AS6478 1223 662 561 45.9% ATT-INTERNET3 - AT&T WorldNet Services AS7545 734 188 546 74.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS2706 545 25 520 95.4% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS22047 619 116 503 81.3% VTR BANDA ANCHA S.A. AS17908 603 109 494 81.9% TCISL Tata Communications AS855 604 147 457 75.7% CANET-ASN-4 - Bell Aliant AS4808 610 156 454 74.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1446 1002 444 30.7% ATT-INTERNET4 - AT&T WorldNet Services AS4134 904 478 426 47.1% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 664 240 424 63.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4668 701 284 417 59.5% LGNET-AS-KR LG CNS AS9443 504 92 412 81.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 962 551 411 42.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17676 527 116 411 78.0% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS10796 592 211 381 64.4% SCRR-10796 - Road Runner HoldCo LLC Total 37630 12724 24906 66.2% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.12.96.0/19 AS15834 MENANET-AS MenaNet network Autonomous System 62.12.107.0/24 AS15834 MENANET-AS MenaNet network Autonomous System 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 81.4.0.0/18 AS15834 MENANET-AS MenaNet network Autonomous System 91.212.31.0/24 AS35225 HRVATSKE-CESTE Hrvatske ceste 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 155.254.0.0/16 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 163.142.0.0/16 AS2500 JPNIC-ASBLOCK-AP JPNIC 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 194.0.68.0/22 AS41704 OGS-AS ZAO "Orenburgskaya Gorodskaya Set", Orenburg, Russia 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.67.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.69.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.71.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.74.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.75.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.77.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.78.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 212.100.64.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.65.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.66.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.68.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.69.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.71.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.72.0/24 AS29835 NSS-CA - New Skies Satellites, Inc. 212.100.73.0/24 AS29835 NSS-CA - New Skies Satellites, Inc. 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.128.0/20 AS15834 MENANET-AS MenaNet network Autonomous System 217.29.134.0/24 AS15834 MENANET-AS MenaNet network Autonomous System 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jloiacon at csc.com Fri Feb 6 07:35:00 2009 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 6 Feb 2009 08:35:00 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: Message-ID: Paul Vixie wrote on 02/06/2009 02:20:01 AM: > the fundamental implication is, forget about address space, it's paperwork > now, it's off the table as a negotiating item or any kind of constraint. > but the size of the routing table is still a bogeyman, and IPv6 arms that > bogeyman with nukes. Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big. Joe From jbates at brightok.net Fri Feb 6 07:38:25 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 06 Feb 2009 07:38:25 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <0F8E47C2-B4B7-459A-862D-A59FFD7E556F@internode.com.au> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <0F8E47C2-B4B7-459A-862D-A59FFD7E556F@internode.com.au> Message-ID: <498C3D51.1030303@brightok.net> Matthew Moyle-Croft wrote: > My comment was regarding customers believing that they were going to, by > default, get a statically allocated range, whatever the length. > > If most customers get dynamically assigned (via PD or other means) then > the issue is not a major one. > Dynamic or static; how does this alter the state of the routing table? A network assigned is a network assigned. In addition, IPv6 has some decent support for mobile IP, which my limited understanding of says they enjoy routing tables the rest of us never get to see. IPv6 is designed to be renumbered. Not all implementations support this extremely well, but it is there. I believe the mobile technologies support renumber on the fly better than traditional aggregation networks who have no expectation of mobility. Jack > > On 06/02/2009, at 8:56 PM, Paul Jakma wrote: > >> On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: >> >>> DHCP(v6). Setting the idea in people's heads that a /64 IS going to >>> be their own statically is insane and will blow out provider's own >>> routing tables more than is rational. >> >> Routing table size will be a function of the number of customers - >> *not* the prefix length assigned to them (for so long as address space >> is sufficiently sparsely allocated that there's a 1:1 mapping from >> customer to prefix - which should be "for a long time" with IPv6). >> >> So (within that longer term constraint) it doesn't matter if you're >> allocating your customer a /48, /56 or /64. >> >> Indeed, what you're suggesting - smaller-than-64 allocations - *would* >> increase routing table sizes. With your proposal those indexes would >> increase greatly in depth (and possibly other space increases due to >> not being able to optimise for "hierarchical routing of bits past 64 >> is highly rare"). >> >> Think of IPv6 as a 64bit network address + host address. At least for >> now. >> >> regards, >> -- >> Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A >> Fortune: >> If you don't have a nasty obituary you probably didn't matter. >> -- Freeman Dyson > From jbates at brightok.net Fri Feb 6 07:51:04 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 06 Feb 2009 07:51:04 -0600 Subject: v6 & DSL / Cable modems In-Reply-To: References: Message-ID: <498C4048.2010902@brightok.net> Joe Loiacono wrote: > > Indeed it does. And don't forget that the most basic data object in the > routing table, the address itself, is 4 times as big. Let's also not forget, that many organizations went from multiple allocations to a single allocation. If we all filter anything longer than /32, we'll rearrange the flow of traffic that many over the years have altered through longer prefixes. Even I suspect I may occasionally have to let a /40 out now and then to alter it's traffic from the rest of the aggregate. Traffic comes to you as it wants to come to you. The only pseudo remedy that currently exists is to move some prefixes over to a different path. If you only have a /32, that'll be a bit hard. This, more than anything, is what will effect this list and the people on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to /48 and treat them as the new /24? I know for myself, traffic manipulation can't begin until /40 (unless I split them further apart). Jack From dot at dotat.at Fri Feb 6 07:52:22 2009 From: dot at dotat.at (Tony Finch) Date: Fri, 6 Feb 2009 13:52:22 +0000 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498B72E7.5090506@telcodata.us> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <00fc01c98734$fee046d0$fca0d470$@com> <52C3E468-D050-481A-AD36-92192B3FD31B@isoc.org> <498B72E7.5090506@telcodata.us> Message-ID: On Thu, 5 Feb 2009, Paul Timmins wrote: > John Schnizlein wrote: > > > > Maybe upgrades, service packs and updates will make them capable of using > > DHCPv6 for useful functions such as finding the address of an available name > > server by the time IPv6-only networks are in operation. > > And if not, hardcode em. It's not like your usual nameserver will be behind a > nat anyway, and generally, a DNS server is a DNS server. Er, no, open recursive resolvers are a very bad idea. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From kratzers at pa.net Fri Feb 6 08:20:50 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Fri, 6 Feb 2009 09:20:50 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: <498C4048.2010902@brightok.net> References: <498C4048.2010902@brightok.net> Message-ID: <200902060920.51759.kratzers@pa.net> On Friday 06 February 2009 08:51:04 Jack Bates wrote: > Joe Loiacono wrote: > > Indeed it does. And don't forget that the most basic data object in the > > routing table, the address itself, is 4 times as big. > > Let's also not forget, that many organizations went from multiple > allocations to a single allocation. If we all filter anything longer > than /32, we'll rearrange the flow of traffic that many over the years > have altered through longer prefixes. Even I suspect I may occasionally > have to let a /40 out now and then to alter it's traffic from the rest > of the aggregate. Traffic comes to you as it wants to come to you. The > only pseudo remedy that currently exists is to move some prefixes over > to a different path. If you only have a /32, that'll be a bit hard. > > This, more than anything, is what will effect this list and the people > on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare > we go to /48 and treat them as the new /24? I know for myself, traffic > manipulation can't begin until /40 (unless I split them further apart). > > > > Jack I think we'll see this more and more. Our newest tier-1 IPv4 transit provider was the first to tell us that they don't allow deaggregation. If we were allocated /19s, we advertise /19s... Not to start another debate, but this will certainly highlight the deficiencies of the hop-by-hop, policy-based routing paradigm that all but ignores the load-balancing needs of 95% (fictitious number) of networks operating in a world which can't load-balance itself. From kratzers at pa.net Fri Feb 6 08:20:50 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Fri, 6 Feb 2009 09:20:50 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: <498C4048.2010902@brightok.net> References: <498C4048.2010902@brightok.net> Message-ID: <200902060920.51759.kratzers@pa.net> On Friday 06 February 2009 08:51:04 Jack Bates wrote: > Joe Loiacono wrote: > > Indeed it does. And don't forget that the most basic data object in the > > routing table, the address itself, is 4 times as big. > > Let's also not forget, that many organizations went from multiple > allocations to a single allocation. If we all filter anything longer > than /32, we'll rearrange the flow of traffic that many over the years > have altered through longer prefixes. Even I suspect I may occasionally > have to let a /40 out now and then to alter it's traffic from the rest > of the aggregate. Traffic comes to you as it wants to come to you. The > only pseudo remedy that currently exists is to move some prefixes over > to a different path. If you only have a /32, that'll be a bit hard. > > This, more than anything, is what will effect this list and the people > on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare > we go to /48 and treat them as the new /24? I know for myself, traffic > manipulation can't begin until /40 (unless I split them further apart). > > > > Jack I think we'll see this more and more. Our newest tier-1 IPv4 transit provider was the first to tell us that they don't allow deaggregation. If we were allocated /19s, we advertise /19s... Not to start another debate, but this will certainly highlight the deficiencies of the hop-by-hop, policy-based routing paradigm that all but ignores the load-balancing needs of 95% (fictitious number) of networks operating in a world which can't load-balance itself. From tdurack at gmail.com Fri Feb 6 08:28:02 2009 From: tdurack at gmail.com (Tim Durack) Date: Fri, 6 Feb 2009 09:28:02 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: <498C4048.2010902@brightok.net> References: <498C4048.2010902@brightok.net> Message-ID: <9e246b4d0902060628q6301f2b7r5a61eb87434995b7@mail.gmail.com> On Fri, Feb 6, 2009 at 8:51 AM, Jack Bates wrote: > Joe Loiacono wrote: > >> >> Indeed it does. And don't forget that the most basic data object in the >> routing table, the address itself, is 4 times as big. >> > > Let's also not forget, that many organizations went from multiple > allocations to a single allocation. If we all filter anything longer than > /32, we'll rearrange the flow of traffic that many over the years have > altered through longer prefixes. Even I suspect I may occasionally have to > let a /40 out now and then to alter it's traffic from the rest of the > aggregate. Traffic comes to you as it wants to come to you. The only pseudo > remedy that currently exists is to move some prefixes over to a different > path. If you only have a /32, that'll be a bit hard. > > This, more than anything, is what will effect this list and the people on > it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to > /48 and treat them as the new /24? I know for myself, traffic manipulation > can't begin until /40 (unless I split them further apart). > > Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't. Tim:> From iljitsch at muada.com Fri Feb 6 08:39:01 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 6 Feb 2009 15:39:01 +0100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> Message-ID: On 6 feb 2009, at 1:15, Ricky Beam wrote: > I see IPv6 address space being carved out in huge chunks for reasons > that equate to little more than because the total space is > "inexhaustable". This is the exact same type of mis-management that > plagues us from IPv4's early allocations. Think of it this way: if addresses are going to be wasted, I'll be happy to take my share an un-waste as required. For instance, there have been suggestions to move the /64 subnet boundary to /80 because 64-bit MAC addresses never took off. I'll take my /64s now and then move the boundary to /80 later so I can multiply the number of subnets that I have by 65536. This is a whole lot more pleasant that slicing and dicing that single IPv4 address in ever tinier parts as I get more stuff that runs IP in my house. (And there is a real risk that I won't even have that single IPv4 address anymore in the future but have to share one with my neighbors.) IPv6 is a whole new way of doing things. It doesn't make sense to apply IPv4 sensitivities here, just like in the middle of the ocean, water management is a different game than in the desert. You could make a fair case that 48 bits would have been sufficient for IPv6 (6/4th of 32 bits after all) and then we'd have to manage that space pretty much the same as today's IPv4 space. But it's almost three times that. >> you get to generate an address from a prefix through a function >> that gives you the same address without requiring anyone to >> remember that address, which is also useful. > Well, it is extremely wasteful. Not really. The waste started and ended with the decison to make IPv6 addresses 128 bits. Now that you have to carry those 128 bits in all your packets, there is no additional penalty for actually using them. > If you want the machine to always have the same address, either > enter it manually or set your DHCP server to always give it the same > address. Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With IPv6 it's easier, but you're still limiting the uptime of your system to that of the DHCPv6 server. Router advertisements is much more robust. > And face reality, many people have enough trouble remembering IPv4 > addresses -- even when it's simplified to a /24 prefix plus 3 digit > number. They will have an even harder time remembering a 48bit or > 64bit MAC. Do you remember the MAC addresses of ANY of the NICs on > your lan(s)? Isn't remembering stuff what we have computers for? > It's not even that. Had they simply not ignored, and out-right > dismissed as "wrong", the way networks were being run, then we > wouldn't have the mess we have today. I pick on autoconfig because > it's the simplest bit of stupid on their part... we have Stateless > Autoconfiguration, *jedi hand wave*, you don't need DHCP. It was > bull the instant they said it. I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it. From iljitsch at muada.com Fri Feb 6 08:48:53 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 6 Feb 2009 15:48:53 +0100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090205235516.GD8174@isc.org> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> Message-ID: <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> On 6 feb 2009, at 0:55, David W. Hankins wrote: >>> Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent >>> pending), you >>> don't need DHCP. *face plant* The IPv4 mistake you've NOT learned >>> from >>> here is "rarp". DCHP does far more than tell a host was address >>> it should >>> use. > Actually it goes further back than rarp; IPv6 RA is actually more > closely related to IPv4 ICMP Router Advertisements It makes more sense to look at it like this. In the 1990s we had: - IPv4: manual configuration - IPv4: DHCP - IPX: router advertised network prefix + MAC address - AppleTalk: router advertised network prefix + random number IPv6 gives us all of these. > Let's just say it's a slightly restricted (feature-limited?) RIP. RIP is a routing protocol, not an address configuration protocol. > But yeah, in that the static->RARP->BOOTP->DHCP progression was a > dialogue between operators and IETF, IPv6 has basically thrown that > dialogue out with the bathwater, and we're having it all over again. The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems. Also, whenever you want to put something new in DHCP you must update the client and server SOFTWARE. Because on the clients, address configuration is a very fundamental thing, this is something buried deep inside the system where it's hard to make changes by anyone other than the OS vendor. What we need is a simple, fast, efficient way to distribute the basic information that a host needs to start sending and receiving packets and a pointer to a place where additional location dependent configuration information can be found. That would be: address+prefix, gateway and (arguably) DNS and then something like a URL for a server that has the config info. The system and applications can then load information from the config server over HTTP in XML format or some such. From jloiacon at csc.com Fri Feb 6 09:02:42 2009 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 6 Feb 2009 10:02:42 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: <9e246b4d0902060628q6301f2b7r5a61eb87434995b7@mail.gmail.com> Message-ID: Tim Durack wrote on 02/06/2009 09:28:02 AM: > > Given that ARIN at least is assigning end-user /48s out of 2620::/23 > it would be useful to accept these announcements. If not end-user PI > is dead in the water. Some providers might like that. End-users > probably won't. That range alone is 25 bits of routing, equivalent to routing all the way down to /25s in the IPv4 world. But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous. And then times 4 for 128 bits. But, I'm not a routing engine guy, so I'm probably missing something ... Joe From tdurack at gmail.com Fri Feb 6 09:07:28 2009 From: tdurack at gmail.com (Tim Durack) Date: Fri, 6 Feb 2009 10:07:28 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: References: <9e246b4d0902060628q6301f2b7r5a61eb87434995b7@mail.gmail.com> Message-ID: <9e246b4d0902060707g43fe6242j86f96885e8e08c63@mail.gmail.com> On Fri, Feb 6, 2009 at 10:02 AM, Joe Loiacono wrote: > > Tim Durack wrote on 02/06/2009 09:28:02 AM: > > > > > Given that ARIN at least is assigning end-user /48s out of 2620::/23 > > it would be useful to accept these announcements. If not end-user PI > > is dead in the water. Some providers might like that. End-users > > probably won't. > > That range alone is 25 bits of routing, equivalent to routing all the way > down to /25s in the IPv4 world. But I don't see how you could route some > /48s without having software to route all /48s and that is hugemongous. And > then times 4 for 128 bits. But, I'm not a routing engine guy, so I'm > probably missing something ... > > Joe I doubt most current hardware can handle an IPv4 world full of /24s, yet they are accepted by most. Tim:> From matthew at eeph.com Fri Feb 6 09:08:06 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Fri, 06 Feb 2009 07:08:06 -0800 Subject: v6 & DSL / Cable modems In-Reply-To: References: Message-ID: <498C5256.3070504@eeph.com> Joe Loiacono wrote: > Indeed it does. And don't forget that the most basic data object in the > routing table, the address itself, is 4 times as big. "2 times as big", if you believe that routers that need to care about table size won't do anything about what's past the /64 boundary. It still costs money. Especially since you'll also need to be carrying the v4 table for approximately forever, and it'll be deaggregating faster and faster at least for a while. Matthew Kaufman From jbates at brightok.net Fri Feb 6 09:09:03 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 06 Feb 2009 09:09:03 -0600 Subject: v6 & DSL / Cable modems In-Reply-To: <9e246b4d0902060628q6301f2b7r5a61eb87434995b7@mail.gmail.com> References: <498C4048.2010902@brightok.net> <9e246b4d0902060628q6301f2b7r5a61eb87434995b7@mail.gmail.com> Message-ID: <498C528F.3040305@brightok.net> Tim Durack wrote: > > Given that ARIN at least is assigning end-user /48s out of 2620::/23 it > would be useful to accept these announcements. If not end-user PI is > dead in the water. Some providers might like that. End-users probably won't. The ideal solution, I believe, is to support filters of max networks advertised from origin AS. This would allow for some deaggregation with some amount of protection, even if peers are not filtering their downstreams. Not sure I've seen this level of sophistication out of IOS, though. Jack From iljitsch at muada.com Fri Feb 6 09:14:33 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 6 Feb 2009 16:14:33 +0100 Subject: v6 & DSL / Cable modems In-Reply-To: References: Message-ID: <06FD7789-D737-4FBB-B9D9-79BD2D3E7E13@muada.com> On 6 feb 2009, at 16:02, Joe Loiacono wrote: >> Given that ARIN at least is assigning end-user /48s out of 2620::/23 >> it would be useful to accept these announcements. If not end-user PI >> is dead in the water. Some providers might like that. End-users >> probably won't. > That range alone is 25 bits of routing, equivalent to routing all > the way > down to /25s in the IPv4 world. But I don't see how you could route > some > /48s without having software to route all /48s and that is > hugemongous. > And then times 4 for 128 bits. But, I'm not a routing engine guy, so > I'm > probably missing something ... The problem is that ARIN reserves a /44 for every /48 they give out. So that means the most you'll see out of that /23 is 2M prefixes (I don't think there are many routers out there that can handle a v6 table this large) but since you need to accept /48s, this could be deaggregated into 32M prefixes. The RIRs need to stop this reservation stuff, it makes prefix length filtering impossible. From matthew at eeph.com Fri Feb 6 09:17:55 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Fri, 06 Feb 2009 07:17:55 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> Message-ID: <498C54A3.4090507@eeph.com> This is straying from operational to protocol design and implementation, but as someone who has done a fair bit of both design and implementation... Iljitsch van Beijnum wrote: > The problem is that DHCP seemed like a good idea at the time but it > doesn't make any sense today. We know that parsing complex binary data > formats is asking for security problems... Excuse me? This sounds like you've been hanging out with the SIP people for too long. The complexity of having a computer parse something like XML, or much worse, RFC822-style headers with complex rules about optional and mandatory options, a la SIP is *far* beyond what is required to parse things like DNS replies or even ASN.1. And *much* harder to generate strong proofs of correctness for. Just because it is easier to read without a decoder library installed in your sniffer doesn't mean it is "more secure" to parse and process. (Simple examples: binary tag/length/value formats allow immediate checking of the length to see if it is within bounds and to allocate the appropriate data structure size beforehand. With XML there's no way to know how long or deep a structure is until you've parsed the whole thing, just like with RFC822-style headers there's no way to know how long a line will be or whether or not there will be continuation lines for that tag until you've reached the next header. Which is more difficult to check for proper defense against buffer overrun attacks?) Matthew Kaufman From jamie at photon.com Fri Feb 6 09:22:07 2009 From: jamie at photon.com (Jamie Bowden) Date: Fri, 6 Feb 2009 10:22:07 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)] In-Reply-To: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> References: <49555.1233631443@turing-police.cc.vt.edu><76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net><498A2DED.5040601@rollernet.us><9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> Message-ID: <70EC72941042AA48ABE651C40408D9C9C11E3C@hal.photon.com> Five things? Really? My DHCP server hands out the following things to its clients: Default Route DNS Servers Log host Domain Name (or, our case, the sub-domain for the office) NIS Domain NIS Servers NTP Server WINS Servers SMTP Server POP Server NNTP Server Domain suffix search orders. All these useful and handy things that my Windows, Unix (Irix and Solaris), Linux, and FreeBSD clients all need some portion of, in one place where I configure and control it. Static reservations are handled here as well and it ties into the DNS servers to dynamically update forward and reverse as needed (which is rare since even non static allocations don't tend to change). Having to deal with configuration and control of this in multiple places is only going to make the sysadmins of the world hate you. I don't work in an ISP anymore, and I haven't had to deal with BGP/OSPF in almost a decade now other than for some minor internal routing, but you know what? I still have a network with several hundred hosts on it that have to be managed, and DHCP makes life easy for a large chunk of it. We're just one little piece of a larger pie. Our Corporate Overlords are eighty thousand users on seven continents with far more than a 1:1 end user to host ratio. Jamie -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] Sent: Thursday, February 05, 2009 5:42 PM To: Ricky Beam Cc: NANOG list Subject: Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)] On 5 feb 2009, at 22:44, Ricky Beam wrote: >> A single /64 isn't enough for a home user, because their gateway is >> a router and needs a different prefix at both sides. Users may also >> want to subnet their own network. So they need at least something >> like a /60. > Mr. van B, your comments would be laughable if they weren't so > absurdly horrific. That doesn't change the fact that users would be quite constrained by only having a /64 for their internal network. > I've lived quite productively behind a single IPv4 address for > nearly 15 years. So you were already doing NAT in 1994? Then you were ahead of the curve. > I've run 1000 user networks that only used one IPv4 address for all > of them. But how is that relevant for the discussion at hand? Is your point that if 1000 users can share an IPv4 address, 1000 users should share an IPv6 address? How would that make sense? Sharing addresses comes with significant downsides. (Like having to port map services running on hosts on the inside.) Sharing one address with 1000 active users comes with even more downsides. (There are applications that need more than 64 ports so the port number space becomes a limitation.) IPv6 was specifically designed to provide an enormous amount of address space, so accepting the limitation of using one address for a large number of users means foregoing a prime feature of IPv6--for no reason that I can see. > Yet, in the new order, you're telling me I need 18 billion, billion > addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an > access point? The logic is like this. 1. You need more than one. 2. You don't want to change the number often (or at all) 3. What is a number that is so large that it will always be enough? Answer: the size of a MAC address. 4. How large are MAC addresses? Answer: we have technologies that have 64-bit MAC addresses. So we use 64 bits to number subnets. Now of course that seems wasteful, but those 128-bit addresses are carried in all packets anyway, and at least with 64-bit subnet sizes you get some use out of them because you know subnets are always large enough and you get to generate an address from a prefix through a function that gives you the same address without requiring anyone to remember that address, which is also useful. Now if you want to argue that IPv6 should have had 48, 53 or 64 bit addresses, that's fine. But I have to warn you that that ship sailed almost 15 years ago. (My take: they should have been variable length.) > This is the exact same bull**** as the /8 allocations in the early > days of IPv4. Oh no. A /8 is only 16777216 addresses. A /48 for an end-user organization is 1208925819614629174706176 addresses. Or, more relavant: a /8 is almost 0.5% of the IPv4 address space. A / 48 is 0.000000000003% of the currently defined global unicast IPv6 address space. > The idea of the "connected home" is still nowhere near *that* > connected; It took us 15 years to get this far with IPv6. There is no IPv7 on the horizon currently, so even if we start that tomorrow we'll have to get by with IPv6 (and IPv4...) until about 2024. I'm pretty sure we'll be *that* connected by that time. > no matter how many toys you have in your bathroom, it doesn't need > a /96 of it's own. (which is an entire IPv4 of it's own.) Like I explained, we count "0, 1, many" where the IPv6 definition of "many" happens to be 2^64. This is obviously not the single answer that is right in all cases. But the point is that there are reasons why it was a bad idea to make it less than that and no reasons that reasonably required it to be less. > Why do people avoid and resist IPv6... because it was designed with > blind ignorance of the history of IPv4's mistakes (and how we *all* > run our IPv4 networks.) Dooming us to repeating ALL those mistakes > again. IPv6 changes too much but it doesn't fix enough. It would be good if it didn't change much but fixed a lot, but unfortunately, that wasn't to be. > Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent > pending), you don't need DHCP. *face plant* The IPv4 mistake you've > NOT learned from here is "rarp". DCHP does far more than tell a > host was address it should use. An IPv4 DHCP server gives me five things: an address, a prefix length, a default gateway, DNS addresses and a domain. A DHCPv6 server _can_ give me an address but I don't need it because I can generate it myself (with a little help from my friends the routers), it can't give me a prefix length or default gateway, so I still need router advertisements for those (may as well hardcode that /64 now because there is no reasonable way to get something else to work) and I don't need the domain because it's always muada.com anyway. So the only thing missing is the DNS addresses, but RFC 5006 specifies how to add this information to router advertisements. So I have no need for DHCPv6*. If someone else has, good for them and good luck with that. As long as I don't have to run a DHCPv6 server just to suck up all the broadcasts from DHCPv6 clients that are looking for DHCPv6 servers in my network. Please pick up after your dog. * except for prefix delegation to routers. From morrowc.lists at gmail.com Fri Feb 6 09:54:41 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Feb 2009 10:54:41 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)] In-Reply-To: <70EC72941042AA48ABE651C40408D9C9C11E3C@hal.photon.com> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <70EC72941042AA48ABE651C40408D9C9C11E3C@hal.photon.com> Message-ID: <75cb24520902060754o726e578bt3557bfc87ad90f62@mail.gmail.com> On Fri, Feb 6, 2009 at 10:22 AM, Jamie Bowden wrote: > Five things? Really? My DHCP server hands out the following things to > its clients: as I've said a few times now, reason #775 that autoconf is a broken and non-useful 'gadget' for network operators. There is a system today that does lots of client-conf (including the simple default-route + dns-server) called DHCP, there MUST be a similarly featured system in the 'new world order' of ipv6. This really is non-negotiable, why are people still holding out hope that autoconf is 'enough' when users and operators have so clearly said otherwise? -Chris From beckman at angryox.com Fri Feb 6 10:01:12 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 6 Feb 2009 11:01:12 -0500 Subject: L3: Google from DC via the Netherlands? Message-ID: Seems strange. Had a partial outage on Verizon network this morning around 9:50am EST, then when it came back around 10:05am, google routed via the Netherlands. My guess is that there's some sort of routing problem making my fastest or least cost route go to the Netherlands, but I wanted to find out if there was an ongoing issue, or if the Netherlands simply now serves the US East Coast for google. Isn't there anything closer? Or is this just indicative of an ongoing L3 outage? I'm guessing it's cheaper/faster to get to Google somewhere in the US, but maybe someone on NANOG knows better than I do. HOST: octal.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. tomato.angryox.com 0.0% 20 0.6 0.6 0.5 0.7 0.0 2. 10.1.41.15 0.0% 20 2.1 4.2 1.9 42.8 9.1 3. p4-2.lcr-02.washdc.verizon-g 0.0% 20 1.5 1.5 1.3 2.3 0.2 4. 130.81.29.218 0.0% 20 2.0 7.3 2.0 45.0 11.9 5. 0.so-1-2-0.xl4.iad8.alter.ne 0.0% 20 2.4 2.4 2.3 3.3 0.2 6. 0.ge-3-3-0.br2.iad8.alter.ne 0.0% 20 2.4 2.4 2.3 2.5 0.1 7. te-11-3-0.edge1.washington4. 0.0% 20 2.4 12.2 2.3 151.2 33.6 8. vlan99.csw4.washington1.leve 0.0% 20 3.1 7.3 3.0 15.0 4.3 9. ae-92-92.ebr2.washington1.le 0.0% 20 3.2 3.3 3.1 3.6 0.1 10. ae-42-42.ebr2.frankfurt1.lev 0.0% 20 94.1 94.4 93.7 104.0 2.3 11. ae-2-2.ebr1.dusseldorf1.leve 0.0% 20 106.1 100.6 95.8 107.0 4.1 12. ae-46-106.ebr2.dusseldorf1.l 0.0% 20 100.4 103.1 98.0 111.0 4.3 13. ae-41.ebr1.amsterdam1.level3 0.0% 20 107.2 99.9 94.4 107.7 5.7 14. ae-11-53.car1.amsterdam1.lev 0.0% 20 94.5 95.0 94.1 102.6 2.0 15. 212.72.42.14 0.0% 20 94.9 98.8 94.5 133.9 12.0 16. 209.85.254.250 0.0% 20 95.4 95.4 94.8 97.0 0.5 17. 72.14.233.114 0.0% 20 100.9 107.2 100.7 140.6 9.7 18. 209.85.255.166 0.0% 20 108.9 109.1 107.5 117.3 2.1 19. 209.85.255.110 5.0% 20 109.5 112.4 106.3 119.9 4.7 20. ew-in-f147.google.com 5.0% 20 107.9 108.0 107.5 108.9 0.3 Fri Feb 6 10:56:09 2009 Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. tomato.angryox.com 0.0% 8 0.6 0.6 0.5 0.6 0.0 2. 10.1.41.15 0.0% 8 2.1 2.4 2.1 3.3 0.4 3. P4-2.LCR-02.WASHDC.verizon-gni.net 0.0% 8 1.4 1.4 1.3 1.5 0.1 4. 130.81.29.218 0.0% 8 2.1 9.1 1.9 59.0 20.2 5. 0.so-1-2-0.XL4.IAD8.ALTER.NET 0.0% 8 2.4 2.4 2.3 2.6 0.1 0.so-6-1-0.XL4.IAD8.ALTER.NET 6. 0.ge-7-1-0.BR2.IAD8.ALTER.NET 0.0% 8 2.5 2.5 2.4 2.6 0.1 0.ge-3-3-0.BR2.IAD8.ALTER.NET 0.ge-5-1-0.BR2.IAD8.ALTER.NET 0.ge-7-0-0.BR2.IAD8.ALTER.NET 7. te-11-3-0.edge1.Washington4.level3.net 0.0% 7 2.4 6.0 2.3 27.2 9.4 8. vlan79.csw2.Washington1.Level3.net 0.0% 7 3.2 8.3 3.2 13.5 4.2 9. ae-72-72.ebr2.Washington1.Level3.net 0.0% 7 3.7 3.5 3.1 4.0 0.3 10. ae-44-44.ebr2.Frankfurt1.Level3.net 0.0% 7 94.5 94.9 94.4 97.2 1.0 11. ae-2-2.ebr1.Dusseldorf1.Level3.net 0.0% 7 106.2 100.7 96.4 106.7 4.6 12. ae-46-106.ebr2.Dusseldorf1.Level3.net 0.0% 7 107.6 106.1 100.1 108.9 3.0 13. ae-41.ebr1.Amsterdam1.Level3.net 0.0% 7 95.5 100.6 95.4 108.3 5.9 14. ae-11-55.car1.Amsterdam1.Level3.net 0.0% 7 95.3 95.8 94.4 98.7 1.5 15. GOOGLE-INC.car1.Amsterdam1.Level3.net 0.0% 7 97.0 96.7 96.5 97.0 0.2 16. 209.85.254.250 0.0% 7 102.0 97.0 95.7 102.0 2.2 17. 72.14.233.114 0.0% 7 107.5 104.8 101.5 107.5 2.7 209.85.248.79 18. 209.85.255.70 0.0% 7 109.8 109.1 107.9 110.3 0.8 72.14.239.123 209.85.255.166 209.85.255.20 19. 209.85.255.98 0.0% 7 118.3 114.9 109.7 120.2 4.6 209.85.255.102 209.85.255.110 20. ew-in-f103.google.com 0.0% 7 110.0 109.4 108.0 110.6 1.1 --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From bdfleming at kanren.net Fri Feb 6 10:20:21 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Fri, 6 Feb 2009 10:20:21 -0600 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <1317.64.39.177.10.1233737545.squirrel@webmail.ibctech.ca> References: <1317.64.39.177.10.1233737545.squirrel@webmail.ibctech.ca> Message-ID: <6E5ACC3A-6618-4ED8-848E-E48C136850D5@kanren.net> On Feb 4, 2009, at 2:52 AM, Steve Bertrand wrote: >>>> > > http://tools.ietf.org/html/draft-kumari-blackhole-urpf-02 > If I understand this correctly, there will be a route entered on each edge router for all sources that are participating in a DDoS attack. Is anyone worried about TCAM usage if one of their customers gets hit with a larger DDoS attack? Add in our IPv6 and V4 multicast tables chewing up more TCAM space and things get even more dicy! For my part, I'd be worried if the overall IPv4 unicast route table got much larger than ~1million entries because our hardware-based routers might run out of TCAM and bring the whole network to a screeching halt. From charles.regan at gmail.com Fri Feb 6 10:29:28 2009 From: charles.regan at gmail.com (Charles Regan) Date: Fri, 6 Feb 2009 12:29:28 -0400 Subject: One /22 Two ISP no BGP Message-ID: I want to advertise my /22 to two different ISP on different POP. I can't use BGP as ISP1 doesn't support it. Any suggestions ? Thanks, Charles From nanog-post at rsuc.gweep.net Fri Feb 6 10:33:21 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 6 Feb 2009 11:33:21 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: References: Message-ID: <20090206163321.GA69045@gweep.net> On Fri, Feb 06, 2009 at 12:29:28PM -0400, Charles Regan wrote: > I want to advertise my /22 to two different ISP on different POP. > > I can't use BGP as ISP1 doesn't support it. Get a new ISP and fire whoever signed that contract before getting the technical details correct. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From kwallace at pcconnection.com Fri Feb 6 10:35:47 2009 From: kwallace at pcconnection.com (Wallace Keith) Date: Fri, 6 Feb 2009 11:35:47 -0500 Subject: L3: Google from DC via the Netherlands? In-Reply-To: References: Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> Looks ok from Boston- 3 core2.po1-bbnet1.bsn.pnap.net (63.251.128.18) 2.590 ms 3.988 ms 3.181 ms 4 207.88.182.33.ptr.us.xo.net (207.88.182.33) 26.636 ms 7.651 ms 11.977 ms 5 207.88.182.18.ptr.us.xo.net (207.88.182.18) 7.603 ms 8.174 ms 7.405 ms 6 216.239.49.217 (216.239.49.217) 8.219 ms 8.388 ms 7.510 ms 7 72.14.236.213 (72.14.236.213) 8.468 ms 66.249.94.235 (66.249.94.235) 16.799 ms 72.14.236.213 (72.14.236.213) 9.196 ms 8 72.14.238.138 (72.14.238.138) 27.405 ms 209.85.248.216 (209.85.248.216) 16.352 ms 15.785 ms 9 72.14.238.235 (72.14.238.235) 15.691 ms 14.641 ms 15.628 ms 10 209.85.255.194 (209.85.255.194) 39.077 ms 72.14.239.136 (72.14.239.136) 31.206 ms 64.233.174.46 (64.233.174.46) 32.528 ms 11 209.85.254.247 (209.85.254.247) 28.897 ms 209.85.254.249 (209.85.254.249) 29.192 ms 29.649 ms 12 209.85.255.194 (209.85.255.194) 29.326 ms gw-in-f100.google.com (74.125.67.100) 28.393 ms 209.85.255.194 (209.85.255.194) 35.464 ms -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Friday, February 06, 2009 11:01 AM To: nanog at nanog.org Subject: L3: Google from DC via the Netherlands? Seems strange. Had a partial outage on Verizon network this morning around 9:50am EST, then when it came back around 10:05am, google routed via the Netherlands. My guess is that there's some sort of routing problem making my fastest or least cost route go to the Netherlands, but I wanted to find out if there was an ongoing issue, or if the Netherlands simply now serves the US East Coast for google. Isn't there anything closer? Or is this just indicative of an ongoing L3 outage? I'm guessing it's cheaper/faster to get to Google somewhere in the US, but maybe someone on NANOG knows better than I do. HOST: octal.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. tomato.angryox.com 0.0% 20 0.6 0.6 0.5 0.7 0.0 2. 10.1.41.15 0.0% 20 2.1 4.2 1.9 42.8 9.1 3. p4-2.lcr-02.washdc.verizon-g 0.0% 20 1.5 1.5 1.3 2.3 0.2 4. 130.81.29.218 0.0% 20 2.0 7.3 2.0 45.0 11.9 5. 0.so-1-2-0.xl4.iad8.alter.ne 0.0% 20 2.4 2.4 2.3 3.3 0.2 6. 0.ge-3-3-0.br2.iad8.alter.ne 0.0% 20 2.4 2.4 2.3 2.5 0.1 7. te-11-3-0.edge1.washington4. 0.0% 20 2.4 12.2 2.3 151.2 33.6 8. vlan99.csw4.washington1.leve 0.0% 20 3.1 7.3 3.0 15.0 4.3 9. ae-92-92.ebr2.washington1.le 0.0% 20 3.2 3.3 3.1 3.6 0.1 10. ae-42-42.ebr2.frankfurt1.lev 0.0% 20 94.1 94.4 93.7 104.0 2.3 11. ae-2-2.ebr1.dusseldorf1.leve 0.0% 20 106.1 100.6 95.8 107.0 4.1 12. ae-46-106.ebr2.dusseldorf1.l 0.0% 20 100.4 103.1 98.0 111.0 4.3 13. ae-41.ebr1.amsterdam1.level3 0.0% 20 107.2 99.9 94.4 107.7 5.7 14. ae-11-53.car1.amsterdam1.lev 0.0% 20 94.5 95.0 94.1 102.6 2.0 15. 212.72.42.14 0.0% 20 94.9 98.8 94.5 133.9 12.0 16. 209.85.254.250 0.0% 20 95.4 95.4 94.8 97.0 0.5 17. 72.14.233.114 0.0% 20 100.9 107.2 100.7 140.6 9.7 18. 209.85.255.166 0.0% 20 108.9 109.1 107.5 117.3 2.1 19. 209.85.255.110 5.0% 20 109.5 112.4 106.3 119.9 4.7 20. ew-in-f147.google.com 5.0% 20 107.9 108.0 107.5 108.9 0.3 Fri Feb 6 10:56:09 2009 Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. tomato.angryox.com 0.0% 8 0.6 0.6 0.5 0.6 0.0 2. 10.1.41.15 0.0% 8 2.1 2.4 2.1 3.3 0.4 3. P4-2.LCR-02.WASHDC.verizon-gni.net 0.0% 8 1.4 1.4 1.3 1.5 0.1 4. 130.81.29.218 0.0% 8 2.1 9.1 1.9 59.0 20.2 5. 0.so-1-2-0.XL4.IAD8.ALTER.NET 0.0% 8 2.4 2.4 2.3 2.6 0.1 0.so-6-1-0.XL4.IAD8.ALTER.NET 6. 0.ge-7-1-0.BR2.IAD8.ALTER.NET 0.0% 8 2.5 2.5 2.4 2.6 0.1 0.ge-3-3-0.BR2.IAD8.ALTER.NET 0.ge-5-1-0.BR2.IAD8.ALTER.NET 0.ge-7-0-0.BR2.IAD8.ALTER.NET 7. te-11-3-0.edge1.Washington4.level3.net 0.0% 7 2.4 6.0 2.3 27.2 9.4 8. vlan79.csw2.Washington1.Level3.net 0.0% 7 3.2 8.3 3.2 13.5 4.2 9. ae-72-72.ebr2.Washington1.Level3.net 0.0% 7 3.7 3.5 3.1 4.0 0.3 10. ae-44-44.ebr2.Frankfurt1.Level3.net 0.0% 7 94.5 94.9 94.4 97.2 1.0 11. ae-2-2.ebr1.Dusseldorf1.Level3.net 0.0% 7 106.2 100.7 96.4 106.7 4.6 12. ae-46-106.ebr2.Dusseldorf1.Level3.net 0.0% 7 107.6 106.1 100.1 108.9 3.0 13. ae-41.ebr1.Amsterdam1.Level3.net 0.0% 7 95.5 100.6 95.4 108.3 5.9 14. ae-11-55.car1.Amsterdam1.Level3.net 0.0% 7 95.3 95.8 94.4 98.7 1.5 15. GOOGLE-INC.car1.Amsterdam1.Level3.net 0.0% 7 97.0 96.7 96.5 97.0 0.2 16. 209.85.254.250 0.0% 7 102.0 97.0 95.7 102.0 2.2 17. 72.14.233.114 0.0% 7 107.5 104.8 101.5 107.5 2.7 209.85.248.79 18. 209.85.255.70 0.0% 7 109.8 109.1 107.9 110.3 0.8 72.14.239.123 209.85.255.166 209.85.255.20 19. 209.85.255.98 0.0% 7 118.3 114.9 109.7 120.2 4.6 209.85.255.102 209.85.255.110 20. ew-in-f103.google.com 0.0% 7 110.0 109.4 108.0 110.6 1.1 ------------------------------------------------------------------------ --- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ------------------------------------------------------------------------ --- From msmith at internap.com Fri Feb 6 10:32:24 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 6 Feb 2009 11:32:24 -0500 Subject: One /22 Two ISP no BGP Message-ID: <65C5927BEED3C2428307863DB5C6C6FB02006275@cx49.800onemail.com> How did you get a /22, and what isp won't run bgp with you? ----- Original Message ----- From: Charles Regan To: nanog at nanog.org Sent: Fri Feb 06 11:29:28 2009 Subject: One /22 Two ISP no BGP I want to advertise my /22 to two different ISP on different POP. I can't use BGP as ISP1 doesn't support it. Any suggestions ? Thanks, Charles From daniel.rogers at gmail.com Fri Feb 6 10:43:00 2009 From: daniel.rogers at gmail.com (Daniel Rogers) Date: Fri, 6 Feb 2009 10:43:00 -0600 Subject: One /22 Two ISP no BGP In-Reply-To: <65C5927BEED3C2428307863DB5C6C6FB02006275@cx49.800onemail.com> References: <65C5927BEED3C2428307863DB5C6C6FB02006275@cx49.800onemail.com> Message-ID: <5b8406bc0902060843k4cde0a1exc87d291ddef78ee4@mail.gmail.com> The ISP may not support peering BGP with you, but can they publish routes for you? I find it hard to believe ANY ISP just "doesn't support BGP". On Fri, Feb 6, 2009 at 10:32 AM, Michael Smith wrote: > How did you get a /22, and what isp won't run bgp with you? > > > ----- Original Message ----- > From: Charles Regan > To: nanog at nanog.org > Sent: Fri Feb 06 11:29:28 2009 > Subject: One /22 Two ISP no BGP > > I want to advertise my /22 to two different ISP on different POP. > > I can't use BGP as ISP1 doesn't support it. > > Any suggestions ? > > Thanks, > Charles > > From steve at ibctech.ca Fri Feb 6 10:52:41 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 06 Feb 2009 11:52:41 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: <5b8406bc0902060843k4cde0a1exc87d291ddef78ee4@mail.gmail.com> References: <65C5927BEED3C2428307863DB5C6C6FB02006275@cx49.800onemail.com> <5b8406bc0902060843k4cde0a1exc87d291ddef78ee4@mail.gmail.com> Message-ID: <498C6AD9.4010404@ibctech.ca> Daniel Rogers wrote: > The ISP may not support peering BGP with you, but can they publish routes > for you? I find it hard to believe ANY ISP just "doesn't support BGP". It is very possible that the ISP doesn't support BGP, but more likely, I'd bet that the ISP has never configured BGP on the client end of their network, and aren't too anxious to figure out how to do so. Steve From beckman at angryox.com Fri Feb 6 11:05:41 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 6 Feb 2009 12:05:41 -0500 Subject: L3: Google from DC via the Netherlands? In-Reply-To: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> References: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> Message-ID: I'm OK to that IP as well, but when I query www.google.com, I get multiple IPs, but here are the ones that in in 147: DNS Server IP Route (for me) 205.234.170.217 (tiggee) 74.125.79.147 Amsterdam 208.67.222.222 (opendns) 64.233.183.147 Amsterdam 4.2.2.1 (verizon) 74.125.19.147 San Jose 198.6.1.3 (uu.net/verizon) 74.125.47.147 Washington DC (yay) That's a lot of different answers for the same question! So maybe the problem is that some DNS servers are smarter than others. I am on Verizon FIOS in Northern VA (DC), and use tiggee's free resolving service, http://www.resolvingnameserver.com/freerns.html (they are great for DNS hosting). I used to use 198.6.1.1, but it seems so did everyone else who used to work at UUnet, and they shut it off. Rather than using 198.6.1.3 everywhere (which I'm sure the network folk would appreciate), I found Tiggee's resolving name service, which is nicely anycasted. So what's the deal here? Caching? Beckman On Fri, 6 Feb 2009, Wallace Keith wrote: > Looks ok from Boston- > > 3 core2.po1-bbnet1.bsn.pnap.net (63.251.128.18) 2.590 ms 3.988 ms > 3.181 ms > 4 207.88.182.33.ptr.us.xo.net (207.88.182.33) 26.636 ms 7.651 ms > 11.977 ms > 5 207.88.182.18.ptr.us.xo.net (207.88.182.18) 7.603 ms 8.174 ms > 7.405 ms > 6 216.239.49.217 (216.239.49.217) 8.219 ms 8.388 ms 7.510 ms > 7 72.14.236.213 (72.14.236.213) 8.468 ms 66.249.94.235 > (66.249.94.235) 16.799 ms 72.14.236.213 (72.14.236.213) 9.196 ms > 8 72.14.238.138 (72.14.238.138) 27.405 ms 209.85.248.216 > (209.85.248.216) 16.352 ms 15.785 ms > 9 72.14.238.235 (72.14.238.235) 15.691 ms 14.641 ms 15.628 ms > 10 209.85.255.194 (209.85.255.194) 39.077 ms 72.14.239.136 > (72.14.239.136) 31.206 ms 64.233.174.46 (64.233.174.46) 32.528 ms > 11 209.85.254.247 (209.85.254.247) 28.897 ms 209.85.254.249 > (209.85.254.249) 29.192 ms 29.649 ms > 12 209.85.255.194 (209.85.255.194) 29.326 ms gw-in-f100.google.com > (74.125.67.100) 28.393 ms 209.85.255.194 (209.85.255.194) 35.464 ms > > -----Original Message----- > From: Peter Beckman [mailto:beckman at angryox.com] > Sent: Friday, February 06, 2009 11:01 AM > To: nanog at nanog.org > Subject: L3: Google from DC via the Netherlands? > > Seems strange. Had a partial outage on Verizon network this morning > around > 9:50am EST, then when it came back around 10:05am, google routed via the > Netherlands. My guess is that there's some sort of routing problem > making > my fastest or least cost route go to the Netherlands, but I wanted to > find > out if there was an ongoing issue, or if the Netherlands simply now > serves > the US East Coast for google. > > Isn't there anything closer? Or is this just indicative of an ongoing > L3 > outage? I'm guessing it's cheaper/faster to get to Google somewhere in > the > US, but maybe someone on NANOG knows better than I do. > > HOST: octal.angryox.com Loss% Snt Last Avg Best Wrst > StDev > 1. tomato.angryox.com 0.0% 20 0.6 0.6 0.5 0.7 > 0.0 > 2. 10.1.41.15 0.0% 20 2.1 4.2 1.9 42.8 > 9.1 > 3. p4-2.lcr-02.washdc.verizon-g 0.0% 20 1.5 1.5 1.3 2.3 > 0.2 > 4. 130.81.29.218 0.0% 20 2.0 7.3 2.0 45.0 > 11.9 > 5. 0.so-1-2-0.xl4.iad8.alter.ne 0.0% 20 2.4 2.4 2.3 3.3 > 0.2 > 6. 0.ge-3-3-0.br2.iad8.alter.ne 0.0% 20 2.4 2.4 2.3 2.5 > 0.1 > 7. te-11-3-0.edge1.washington4. 0.0% 20 2.4 12.2 2.3 151.2 > 33.6 > 8. vlan99.csw4.washington1.leve 0.0% 20 3.1 7.3 3.0 15.0 > 4.3 > 9. ae-92-92.ebr2.washington1.le 0.0% 20 3.2 3.3 3.1 3.6 > 0.1 > 10. ae-42-42.ebr2.frankfurt1.lev 0.0% 20 94.1 94.4 93.7 104.0 > 2.3 > 11. ae-2-2.ebr1.dusseldorf1.leve 0.0% 20 106.1 100.6 95.8 107.0 > 4.1 > 12. ae-46-106.ebr2.dusseldorf1.l 0.0% 20 100.4 103.1 98.0 111.0 > 4.3 > 13. ae-41.ebr1.amsterdam1.level3 0.0% 20 107.2 99.9 94.4 107.7 > 5.7 > 14. ae-11-53.car1.amsterdam1.lev 0.0% 20 94.5 95.0 94.1 102.6 > 2.0 > 15. 212.72.42.14 0.0% 20 94.9 98.8 94.5 133.9 > 12.0 > 16. 209.85.254.250 0.0% 20 95.4 95.4 94.8 97.0 > 0.5 > 17. 72.14.233.114 0.0% 20 100.9 107.2 100.7 140.6 > 9.7 > 18. 209.85.255.166 0.0% 20 108.9 109.1 107.5 117.3 > 2.1 > 19. 209.85.255.110 5.0% 20 109.5 112.4 106.3 119.9 > 4.7 > 20. ew-in-f147.google.com 5.0% 20 107.9 108.0 107.5 108.9 > 0.3 > > Fri Feb 6 10:56:09 2009 > Packets Pings > Host Loss% Snt Last Avg > Best Wrst StDev > 1. tomato.angryox.com 0.0% 8 0.6 0.6 > 0.5 0.6 0.0 > 2. 10.1.41.15 0.0% 8 2.1 2.4 > 2.1 3.3 0.4 > 3. P4-2.LCR-02.WASHDC.verizon-gni.net 0.0% 8 1.4 1.4 > 1.3 1.5 0.1 > 4. 130.81.29.218 0.0% 8 2.1 9.1 > 1.9 59.0 20.2 > 5. 0.so-1-2-0.XL4.IAD8.ALTER.NET 0.0% 8 2.4 2.4 > 2.3 2.6 0.1 > 0.so-6-1-0.XL4.IAD8.ALTER.NET > 6. 0.ge-7-1-0.BR2.IAD8.ALTER.NET 0.0% 8 2.5 2.5 > 2.4 2.6 0.1 > 0.ge-3-3-0.BR2.IAD8.ALTER.NET > 0.ge-5-1-0.BR2.IAD8.ALTER.NET > 0.ge-7-0-0.BR2.IAD8.ALTER.NET > 7. te-11-3-0.edge1.Washington4.level3.net 0.0% 7 2.4 6.0 > 2.3 27.2 9.4 > 8. vlan79.csw2.Washington1.Level3.net 0.0% 7 3.2 8.3 > 3.2 13.5 4.2 > 9. ae-72-72.ebr2.Washington1.Level3.net 0.0% 7 3.7 3.5 > 3.1 4.0 0.3 > 10. ae-44-44.ebr2.Frankfurt1.Level3.net 0.0% 7 94.5 94.9 94.4 > 97.2 1.0 > 11. ae-2-2.ebr1.Dusseldorf1.Level3.net 0.0% 7 106.2 100.7 96.4 > 106.7 4.6 > 12. ae-46-106.ebr2.Dusseldorf1.Level3.net 0.0% 7 107.6 106.1 100.1 > 108.9 3.0 > 13. ae-41.ebr1.Amsterdam1.Level3.net 0.0% 7 95.5 100.6 95.4 > 108.3 5.9 > 14. ae-11-55.car1.Amsterdam1.Level3.net 0.0% 7 95.3 95.8 94.4 > 98.7 1.5 > 15. GOOGLE-INC.car1.Amsterdam1.Level3.net 0.0% 7 97.0 96.7 96.5 > 97.0 0.2 > 16. 209.85.254.250 0.0% 7 102.0 97.0 95.7 > 102.0 2.2 > 17. 72.14.233.114 0.0% 7 107.5 104.8 101.5 > 107.5 2.7 > 209.85.248.79 > 18. 209.85.255.70 0.0% 7 109.8 109.1 107.9 > 110.3 0.8 > 72.14.239.123 > 209.85.255.166 > 209.85.255.20 > 19. 209.85.255.98 0.0% 7 118.3 114.9 109.7 > 120.2 4.6 > 209.85.255.102 > 209.85.255.110 > 20. ew-in-f103.google.com 0.0% 7 110.0 109.4 108.0 > 110.6 1.1 > > ------------------------------------------------------------------------ > --- > Peter Beckman Internet > Guy > beckman at angryox.com > http://www.angryox.com/ > ------------------------------------------------------------------------ > --- > > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jason at biel-tech.com Fri Feb 6 11:06:35 2009 From: jason at biel-tech.com (Jason Biel) Date: Fri, 6 Feb 2009 11:06:35 -0600 Subject: One /22 Two ISP no BGP In-Reply-To: <498C6AD9.4010404@ibctech.ca> References: <65C5927BEED3C2428307863DB5C6C6FB02006275@cx49.800onemail.com> <5b8406bc0902060843k4cde0a1exc87d291ddef78ee4@mail.gmail.com> <498C6AD9.4010404@ibctech.ca> Message-ID: Pick your preferred link in, have them announce your /22, have the other provider announce the /22, just weighed. That way you are multi-homed with failover. After that is configured, find a new ISP to replace the one that will not let you peer with them. Jason On Fri, Feb 6, 2009 at 10:52 AM, Steve Bertrand wrote: > Daniel Rogers wrote: > > The ISP may not support peering BGP with you, but can they publish routes > > for you? I find it hard to believe ANY ISP just "doesn't support BGP". > > It is very possible that the ISP doesn't support BGP, but more likely, > I'd bet that the ISP has never configured BGP on the client end of their > network, and aren't too anxious to figure out how to do so. > > Steve > > -- Jason Biel From charles.regan at gmail.com Fri Feb 6 11:08:53 2009 From: charles.regan at gmail.com (Charles Regan) Date: Fri, 6 Feb 2009 13:08:53 -0400 Subject: One /22 Two ISP no BGP In-Reply-To: References: <498C65F3.7090104@yahoo.com> <498C6638.5080702@yahoo.com> Message-ID: Quick questions. If both ISP publish my /22, what will happen if ISP1 goes down ? Half the internet won't be able to reach me ? I'll have to call them to remove the route manually ? Charles. On Fri, Feb 6, 2009 at 12:54 PM, Charles Regan wrote: > Hmmm, McNamara descendent ? > > On Fri, Feb 6, 2009 at 12:32 PM, Charles Ragan wrote: >> yup... >> >> too funny heh. >> >> Charles Regan wrote: >> >> >From Irish descendent ? >> >> On Fri, Feb 6, 2009 at 12:31 PM, Charles Ragan >> wrote: >> >> >> ha - hey charles...i subscribe to nanog and saw your email come across and >> had to send a note...too funny. Charles Ragan here... >> >> Charles >> >> Charles Regan wrote: >> >> >> I want to advertise my /22 to two different ISP on different POP. >> >> I can't use BGP as ISP1 doesn't support it. >> >> Any suggestions ? >> >> Thanks, >> Charles >> >> >> >> >> >> >> >> > From jason at biel-tech.com Fri Feb 6 11:12:06 2009 From: jason at biel-tech.com (Jason Biel) Date: Fri, 6 Feb 2009 11:12:06 -0600 Subject: One /22 Two ISP no BGP In-Reply-To: References: <498C65F3.7090104@yahoo.com> <498C6638.5080702@yahoo.com> Message-ID: The link that goes down will trigger that provider to remove the route, traffic will swing and start coming in on the backup link. On Fri, Feb 6, 2009 at 11:08 AM, Charles Regan wrote: > Quick questions. > If both ISP publish my /22, what will happen if ISP1 goes down ? > Half the internet won't be able to reach me ? I'll have to call them > to remove the route manually ? > > Charles. > > On Fri, Feb 6, 2009 at 12:54 PM, Charles Regan > wrote: > > Hmmm, McNamara descendent ? > > > > On Fri, Feb 6, 2009 at 12:32 PM, Charles Ragan > wrote: > >> yup... > >> > >> too funny heh. > >> > >> Charles Regan wrote: > >> > >> >From Irish descendent ? > >> > >> On Fri, Feb 6, 2009 at 12:31 PM, Charles Ragan > > >> wrote: > >> > >> > >> ha - hey charles...i subscribe to nanog and saw your email come across > and > >> had to send a note...too funny. Charles Ragan here... > >> > >> Charles > >> > >> Charles Regan wrote: > >> > >> > >> I want to advertise my /22 to two different ISP on different POP. > >> > >> I can't use BGP as ISP1 doesn't support it. > >> > >> Any suggestions ? > >> > >> Thanks, > >> Charles > >> > >> > >> > >> > >> > >> > >> > >> > > > > -- Jason Biel From charles.regan at gmail.com Fri Feb 6 11:14:52 2009 From: charles.regan at gmail.com (Charles Regan) Date: Fri, 6 Feb 2009 13:14:52 -0400 Subject: One /22 Two ISP no BGP In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10482E5B4F66@ROCH-EXCH1.corp.pvt> References: <2E2FECEBAE57CC4BAACDE67638305F10482E5B4F66@ROCH-EXCH1.corp.pvt> Message-ID: I'll explain. We are a small ISP on a very remote Island. We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from ISP2. They are the only two we can get bandwidth. So we are stuck with ISP1 that doesn't support BGP. On Fri, Feb 6, 2009 at 12:48 PM, Azinger, Marla wrote: > im curiouse. you probably had a reason for wanting to do that. So cant you find another ISP that will do what you want? > > Cheers > Marla > > -----Original Message----- > From: Charles Regan [mailto:charles.regan at gmail.com] > Sent: Friday, February 06, 2009 8:29 AM > To: nanog at nanog.org > Subject: One /22 Two ISP no BGP > > I want to advertise my /22 to two different ISP on different POP. > > I can't use BGP as ISP1 doesn't support it. > > Any suggestions ? > > Thanks, > Charles > > From jason at biel-tech.com Fri Feb 6 11:19:05 2009 From: jason at biel-tech.com (Jason Biel) Date: Fri, 6 Feb 2009 11:19:05 -0600 Subject: One /22 Two ISP no BGP In-Reply-To: References: <2E2FECEBAE57CC4BAACDE67638305F10482E5B4F66@ROCH-EXCH1.corp.pvt> Message-ID: Charles, As I mentioned earlier, you'll want to have one provider announce the /22 unweighted and the other announce it weighted. Just pick the better of the two providers as the primary. Don't base it soley off bandwidth, but check your SLA and any recent outage occurances. Traffic will flow in via the primary until that link to you drops, the provider will remove the route, and traffic will come in the back up route. On Fri, Feb 6, 2009 at 11:14 AM, Charles Regan wrote: > I'll explain. We are a small ISP on a very remote Island. > We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from > ISP2. > > They are the only two we can get bandwidth. > > So we are stuck with ISP1 that doesn't support BGP. > > On Fri, Feb 6, 2009 at 12:48 PM, Azinger, Marla > wrote: > > im curiouse. you probably had a reason for wanting to do that. So cant > you find another ISP that will do what you want? > > > > Cheers > > Marla > > > > -----Original Message----- > > From: Charles Regan [mailto:charles.regan at gmail.com] > > Sent: Friday, February 06, 2009 8:29 AM > > To: nanog at nanog.org > > Subject: One /22 Two ISP no BGP > > > > I want to advertise my /22 to two different ISP on different POP. > > > > I can't use BGP as ISP1 doesn't support it. > > > > Any suggestions ? > > > > Thanks, > > Charles > > > > > > -- Jason Biel From jason at biel-tech.com Fri Feb 6 11:20:16 2009 From: jason at biel-tech.com (Jason Biel) Date: Fri, 6 Feb 2009 11:20:16 -0600 Subject: One /22 Two ISP no BGP In-Reply-To: <498C70DF.3040402@ibctech.ca> References: <498C65F3.7090104@yahoo.com> <498C6638.5080702@yahoo.com> <498C70DF.3040402@ibctech.ca> Message-ID: Good point on ISP1 Steve, being they are limited already, they might be just reselling. On Fri, Feb 6, 2009 at 11:18 AM, Steve Bertrand wrote: > Jason Biel wrote: > > The link that goes down will trigger that provider to remove the route, > > traffic will swing and start coming in on the backup link. > > This is assuming that 'ISP1' has the capability to advertise the OP's > route in the first place. > > What if ISP1 is simply a customer of another ISP, using PA space, and > just reselling connectivity? > > Charles, you really need to find out what others have asked... can the > ISP1 advertise your block of space for you, or do they really mean that > they *can't* do BGP at all. > > Steve > -- Jason Biel From sthaug at nethelp.no Fri Feb 6 11:22:30 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 06 Feb 2009 18:22:30 +0100 (CET) Subject: v6 & DSL / Cable modems In-Reply-To: <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> Message-ID: <20090206.182230.74716370.sthaug@nethelp.no> > The problem is that DHCP seemed like a good idea at the time but it > doesn't make any sense today. We know that parsing complex binary data > formats is asking for security problems. And parsing complex text data structures is better? > What we need is a simple, fast, efficient way to distribute the basic > information that a host needs to start sending and receiving packets > and a pointer to a place where additional location dependent > configuration information can be found. That would be: address+prefix, > gateway and (arguably) DNS and then something like a URL for a server > that has the config info. The system and applications can then load > information from the config server over HTTP in XML format or some such. No, this information must be available in *one* place. It's called a DHCP server. As an operator, this is clearly what I want, both for IPv4 and IPv6. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From msmith at internap.com Fri Feb 6 11:22:51 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 6 Feb 2009 12:22:51 -0500 Subject: One /22 Two ISP no BGP Message-ID: <65C5927BEED3C2428307863DB5C6C6FB02006279@cx49.800onemail.com> That is a possible scenario. If they are willing to tie the static route to their interface toward your net, that static route would be dynamically removed. Also, technologies like cisco's ip-sla would get you part of the way there. If they won't run bgp with you, one of the static route options is probably your only reasonable hope. All of the above are inferior to bgp. The best advice that I've heard thusfar is to deal with this the best way possible, and then start shopping. ----- Original Message ----- From: Charles Regan To: nanog at nanog.org Sent: Fri Feb 06 12:08:53 2009 Subject: Re: One /22 Two ISP no BGP Quick questions. If both ISP publish my /22, what will happen if ISP1 goes down ? Half the internet won't be able to reach me ? I'll have to call them to remove the route manually ? Charles. On Fri, Feb 6, 2009 at 12:54 PM, Charles Regan wrote: > Hmmm, McNamara descendent ? > > On Fri, Feb 6, 2009 at 12:32 PM, Charles Ragan wrote: >> yup... >> >> too funny heh. >> >> Charles Regan wrote: >> >> >From Irish descendent ? >> >> On Fri, Feb 6, 2009 at 12:31 PM, Charles Ragan >> wrote: >> >> >> ha - hey charles...i subscribe to nanog and saw your email come across and >> had to send a note...too funny. Charles Ragan here... >> >> Charles >> >> Charles Regan wrote: >> >> >> I want to advertise my /22 to two different ISP on different POP. >> >> I can't use BGP as ISP1 doesn't support it. >> >> Any suggestions ? >> >> Thanks, >> Charles >> >> >> >> >> >> >> >> > From charles.regan at gmail.com Fri Feb 6 11:24:53 2009 From: charles.regan at gmail.com (Charles Regan) Date: Fri, 6 Feb 2009 13:24:53 -0400 Subject: One /22 Two ISP no BGP In-Reply-To: References: <498C65F3.7090104@yahoo.com> <498C6638.5080702@yahoo.com> <498C70DF.3040402@ibctech.ca> Message-ID: The can't do BGP. They are already advertising two /24 for us. So they will advertise a /22 if I ask them. On Fri, Feb 6, 2009 at 1:20 PM, Jason Biel wrote: > Good point on ISP1 Steve, being they are limited already, they might be just > reselling. > > > > On Fri, Feb 6, 2009 at 11:18 AM, Steve Bertrand wrote: >> >> Jason Biel wrote: >> > The link that goes down will trigger that provider to remove the route, >> > traffic will swing and start coming in on the backup link. >> >> This is assuming that 'ISP1' has the capability to advertise the OP's >> route in the first place. >> >> What if ISP1 is simply a customer of another ISP, using PA space, and >> just reselling connectivity? >> >> Charles, you really need to find out what others have asked... can the >> ISP1 advertise your block of space for you, or do they really mean that >> they *can't* do BGP at all. >> >> Steve > > > > -- > Jason Biel > > From steve at ibctech.ca Fri Feb 6 11:18:23 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 06 Feb 2009 12:18:23 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: References: <498C65F3.7090104@yahoo.com> <498C6638.5080702@yahoo.com> Message-ID: <498C70DF.3040402@ibctech.ca> Jason Biel wrote: > The link that goes down will trigger that provider to remove the route, > traffic will swing and start coming in on the backup link. This is assuming that 'ISP1' has the capability to advertise the OP's route in the first place. What if ISP1 is simply a customer of another ISP, using PA space, and just reselling connectivity? Charles, you really need to find out what others have asked... can the ISP1 advertise your block of space for you, or do they really mean that they *can't* do BGP at all. Steve From msmith at internap.com Fri Feb 6 11:29:29 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 6 Feb 2009 12:29:29 -0500 Subject: One /22 Two ISP no BGP Message-ID: <65C5927BEED3C2428307863DB5C6C6FB0200627B@cx49.800onemail.com> ...small isp on a very remote island... Sounds like a nice problem to have... :) ----- Original Message ----- From: Charles Regan To: nanog at nanog.org Sent: Fri Feb 06 12:14:52 2009 Subject: Re: One /22 Two ISP no BGP I'll explain. We are a small ISP on a very remote Island. We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from ISP2. They are the only two we can get bandwidth. So we are stuck with ISP1 that doesn't support BGP. On Fri, Feb 6, 2009 at 12:48 PM, Azinger, Marla wrote: > im curiouse. you probably had a reason for wanting to do that. So cant you find another ISP that will do what you want? > > Cheers > Marla > > -----Original Message----- > From: Charles Regan [mailto:charles.regan at gmail.com] > Sent: Friday, February 06, 2009 8:29 AM > To: nanog at nanog.org > Subject: One /22 Two ISP no BGP > > I want to advertise my /22 to two different ISP on different POP. > > I can't use BGP as ISP1 doesn't support it. > > Any suggestions ? > > Thanks, > Charles > > From charles.regan at gmail.com Fri Feb 6 11:31:05 2009 From: charles.regan at gmail.com (Charles Regan) Date: Fri, 6 Feb 2009 13:31:05 -0400 Subject: One /22 Two ISP no BGP In-Reply-To: References: <498C65F3.7090104@yahoo.com> <498C6638.5080702@yahoo.com> <498C70DF.3040402@ibctech.ca> Message-ID: What if both annonce my /22 unweighted ? I know I will loose failover in this scenario. I am trying to figure out what will happen, traffic will flow inbound from both in a round-robin like method ? On Fri, Feb 6, 2009 at 1:24 PM, Charles Regan wrote: > The can't do BGP. > They are already advertising two /24 for us. So they will advertise a > /22 if I ask them. > > > On Fri, Feb 6, 2009 at 1:20 PM, Jason Biel wrote: >> Good point on ISP1 Steve, being they are limited already, they might be just >> reselling. >> >> >> >> On Fri, Feb 6, 2009 at 11:18 AM, Steve Bertrand wrote: >>> >>> Jason Biel wrote: >>> > The link that goes down will trigger that provider to remove the route, >>> > traffic will swing and start coming in on the backup link. >>> >>> This is assuming that 'ISP1' has the capability to advertise the OP's >>> route in the first place. >>> >>> What if ISP1 is simply a customer of another ISP, using PA space, and >>> just reselling connectivity? >>> >>> Charles, you really need to find out what others have asked... can the >>> ISP1 advertise your block of space for you, or do they really mean that >>> they *can't* do BGP at all. >>> >>> Steve >> >> >> >> -- >> Jason Biel >> >> > From jason at biel-tech.com Fri Feb 6 11:40:55 2009 From: jason at biel-tech.com (Jason Biel) Date: Fri, 6 Feb 2009 11:40:55 -0600 Subject: One /22 Two ISP no BGP In-Reply-To: References: <498C6638.5080702@yahoo.com> <498C70DF.3040402@ibctech.ca> Message-ID: It will depend on the source of the traffic and how that peer follows AS path into your providers. On Fri, Feb 6, 2009 at 11:31 AM, Charles Regan wrote: > What if both annonce my /22 unweighted ? > > I know I will loose failover in this scenario. > > I am trying to figure out what will happen, traffic will flow inbound > from both in a round-robin like method ? > > > > > On Fri, Feb 6, 2009 at 1:24 PM, Charles Regan > wrote: > > The can't do BGP. > > They are already advertising two /24 for us. So they will advertise a > > /22 if I ask them. > > > > > > On Fri, Feb 6, 2009 at 1:20 PM, Jason Biel wrote: > >> Good point on ISP1 Steve, being they are limited already, they might be > just > >> reselling. > >> > >> > >> > >> On Fri, Feb 6, 2009 at 11:18 AM, Steve Bertrand > wrote: > >>> > >>> Jason Biel wrote: > >>> > The link that goes down will trigger that provider to remove the > route, > >>> > traffic will swing and start coming in on the backup link. > >>> > >>> This is assuming that 'ISP1' has the capability to advertise the OP's > >>> route in the first place. > >>> > >>> What if ISP1 is simply a customer of another ISP, using PA space, and > >>> just reselling connectivity? > >>> > >>> Charles, you really need to find out what others have asked... can the > >>> ISP1 advertise your block of space for you, or do they really mean that > >>> they *can't* do BGP at all. > >>> > >>> Steve > >> > >> > >> > >> -- > >> Jason Biel > >> > >> > > > > -- Jason Biel From dhetzel at gmail.com Fri Feb 6 11:41:12 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 6 Feb 2009 12:41:12 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: References: <498C6638.5080702@yahoo.com> <498C70DF.3040402@ibctech.ca> Message-ID: <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com> I would guess that if one of them can't change their announcement when their link to you is down, then make sure their announcement is the less preferred. The ISP that *can* remove their announcement when their link to you is down should be the preferred path since their path is much more likely to be actually up... On Fri, Feb 6, 2009 at 12:31 PM, Charles Regan wrote: > What if both annonce my /22 unweighted ? > > I know I will loose failover in this scenario. > > I am trying to figure out what will happen, traffic will flow inbound > from both in a round-robin like method ? > > > > > On Fri, Feb 6, 2009 at 1:24 PM, Charles Regan > wrote: > > The can't do BGP. > > They are already advertising two /24 for us. So they will advertise a > > /22 if I ask them. > > > > > > On Fri, Feb 6, 2009 at 1:20 PM, Jason Biel wrote: > >> Good point on ISP1 Steve, being they are limited already, they might be > just > >> reselling. > >> > >> > >> > >> On Fri, Feb 6, 2009 at 11:18 AM, Steve Bertrand > wrote: > >>> > >>> Jason Biel wrote: > >>> > The link that goes down will trigger that provider to remove the > route, > >>> > traffic will swing and start coming in on the backup link. > >>> > >>> This is assuming that 'ISP1' has the capability to advertise the OP's > >>> route in the first place. > >>> > >>> What if ISP1 is simply a customer of another ISP, using PA space, and > >>> just reselling connectivity? > >>> > >>> Charles, you really need to find out what others have asked... can the > >>> ISP1 advertise your block of space for you, or do they really mean that > >>> they *can't* do BGP at all. > >>> > >>> Steve > >> > >> > >> > >> -- > >> Jason Biel > >> > >> > > > > From jbates at brightok.net Fri Feb 6 11:50:55 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 06 Feb 2009 11:50:55 -0600 Subject: v6 & DSL / Cable modems In-Reply-To: <20090206.182230.74716370.sthaug@nethelp.no> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> Message-ID: <498C787F.1060007@brightok.net> sthaug at nethelp.no wrote: > No, this information must be available in *one* place. It's called a > DHCP server. As an operator, this is clearly what I want, both for IPv4 > and IPv6. DHCP is available, spec'd and implemented on some systems. However, there are times that DHCP fails (from my experience). Two routers, 2 default routes. Support for shim6 or other multiple IP protocol. 2 routers, 2 global IP's assigned to the host, different default routes, and support for backup default route to opposite router. There are lots of cool things that RA's are used for, and assigning an address is just one of them. This argument over DHCP seems to be more noise; as there's room for both, and the specs and implementations exist for both. Cable modems, in particular, have a DHCP oriented nature to them; and while there are bugs being worked out on specific implementations (according to cable operators I know), they will be using DHCP with IPv6 as well. Jack From David_Hankins at isc.org Fri Feb 6 11:59:33 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 6 Feb 2009 09:59:33 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> Message-ID: <20090206175933.GD5164@isc.org> I think this part of the thread is in danger of leaving the realm of operational relevance, so I will treat these as my closing arguments. On Fri, Feb 06, 2009 at 03:48:53PM +0100, Iljitsch van Beijnum wrote: > It makes more sense to look at it like this. In the 1990s we had: No, I think that "shopping checklist view" is exactly the kind of wrong thinking that stunts the dialogue between tools and needs, and has been a cause in IPv6's current disconnect in operational reality. So no, I don't think it makes any sense to look at it like that. It makes the most sense to look at the IPv4 configuration protocols alone as a progression of tools, each built upon what was learned from the prior, and the conclusions that were determined to work best for most of the Internet's operators (neither Appletalk's nor IPX's). These conclusions were proper supersets of previously determined operational needs, and so became a pervasively deployed universal solution. This is a functioning model for tool growth. Shopping checklists only create Frankenstein monsters, stunted half-breeds that serve only their creators. > RIP is a routing protocol, not an address configuration protocol. This is a statement whose context predicates that you think I don't know that, which further confers that my intended message has been lost on you. This is far afield from the point! I am predisposed not to correct this, as the message was not intended for you, I hope this is mutually agreeable. :) > asking for security problems. Also, whenever you want to put something new > in DHCP you must update the client and server SOFTWARE. Because on the This actually is not true, which I have told you before. But I have to admit it is a nice contrived false factoid that supports your a-priori conclusions. My analysis of your further arguments is that you have selected a proper subset of actual Internet operational needs in order to further justify these same conclusions. I will leave it at that. :) -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From james.cutler at consultant.com Fri Feb 6 12:00:52 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Fri, 6 Feb 2009 13:00:52 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: <20090206.182230.74716370.sthaug@nethelp.no> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> Message-ID: DHCP items are end system considerations, not routing network considerations. The network operations staff and router configuration engineers do not generally concern themselves with end systems. End systems generally are managed quite independently from the routing network. And, they are more subject to the vagaries of day to day business variability. Note the "one place" in the quoted message below. The only overlap is broadcast forwarding for DHCP initiation. Besides, configuration control is hard enough for router engineers without adding the burden of changing end system requirements. Adding the forwarding entries is almost too much already! ;) So, for routing network operators to denigrate DHCP is probably due to lack of consideration of the end user system requirements. And those who denigrate DHCP and say "just hard code it" make end system management that much more difficult. I still conclude that DHCP is a useful tool for both IPv4 and IPv6 systems. Cutler On Feb 6, 2009, at 12:22 PM, sthaug at nethelp.no wrote: >> The problem is that DHCP seemed like a good idea at the time but it >> doesn't make any sense today. We know that parsing complex binary >> data >> formats is asking for security problems. > > And parsing complex text data structures is better? > >> What we need is a simple, fast, efficient way to distribute the basic >> information that a host needs to start sending and receiving packets >> and a pointer to a place where additional location dependent >> configuration information can be found. That would be: address >> +prefix, >> gateway and (arguably) DNS and then something like a URL for a server >> that has the config info. The system and applications can then load >> information from the config server over HTTP in XML format or some >> such. > > No, this information must be available in *one* place. It's called a > DHCP server. As an operator, this is clearly what I want, both for > IPv4 > and IPv6. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > James R. Cutler james.cutler at consultant.com From jmaimon at ttec.com Fri Feb 6 12:13:14 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 06 Feb 2009 13:13:14 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: References: <2E2FECEBAE57CC4BAACDE67638305F10482E5B4F66@ROCH-EXCH1.corp.pvt> Message-ID: <498C7DBA.5040607@ttec.com> Jason Biel wrote: > Charles, > > As I mentioned earlier, you'll want to have one provider announce the /22 > unweighted and the other announce it weighted. Just pick the better of the > two providers as the primary. Don't base it soley off bandwidth, but check > your SLA and any recent outage occurances. > > Traffic will flow in via the primary until that link to you drops, the > provider will remove the route, and traffic will come in the back up route. Perhaps ebgp-multihop with this ISP's upstream provider might offer you an advantage combined with this approach. Probably worth a try. > > > > On Fri, Feb 6, 2009 at 11:14 AM, Charles Regan wrote: > >> I'll explain. We are a small ISP on a very remote Island. >> We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from >> ISP2. >> >> They are the only two we can get bandwidth. >> >> So we are stuck with ISP1 that doesn't support BGP. >> >> On Fri, Feb 6, 2009 at 12:48 PM, Azinger, Marla >> wrote: >>> im curiouse. you probably had a reason for wanting to do that. So cant >> you find another ISP that will do what you want? >>> Cheers >>> Marla >>> >>> -----Original Message----- >>> From: Charles Regan [mailto:charles.regan at gmail.com] >>> Sent: Friday, February 06, 2009 8:29 AM >>> To: nanog at nanog.org >>> Subject: One /22 Two ISP no BGP >>> >>> I want to advertise my /22 to two different ISP on different POP. >>> >>> I can't use BGP as ISP1 doesn't support it. >>> >>> Any suggestions ? >>> >>> Thanks, >>> Charles >>> >>> >> > > From David_Hankins at isc.org Fri Feb 6 12:15:45 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 6 Feb 2009 10:15:45 -0800 Subject: v6 & DSL / Cable modems In-Reply-To: <498C787F.1060007@brightok.net> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> Message-ID: <20090206181545.GE5164@isc.org> On Fri, Feb 06, 2009 at 11:50:55AM -0600, Jack Bates wrote: > Two routers, 2 default routes. Support for shim6 or other multiple IP What most people do of course is VRRP. Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so. When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents). The net result is that the client uses the default gateway which it used to reach the DHCP server, and so will automatically receive an updated value if that router fails, as part of DHCP lease rebinding (it will reach the server via the alternate router). No need to take on 'routed -q' in the client, it can stay a simple dumb host, with all configuration complexity in the DHCP server or negotiated in HA by the routers. P.S. You can also set the DHCP server-identifier on the opposition of the giaddr field contents; so when the client reaches renewal time, if will be able to use the surviving router if its default router has failed (and thus will not have to wait for rebinding). This has further config implications as the server(s) are no longer able to detect the difference in a client's renewal or rebinding, but it can be an effective optimization. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From cscora at apnic.net Fri Feb 6 12:17:33 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Feb 2009 04:17:33 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200902061817.n16IHXZR025861@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 Feb, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 278566 Prefixes after maximum aggregation: 132796 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 136538 Total ASes present in the Internet Routing Table: 30495 Prefixes per ASN: 9.13 Origin-only ASes present in the Internet Routing Table: 26529 Origin ASes announcing only one prefix: 12914 Transit ASes present in the Internet Routing Table: 3966 Transit-only ASes present in the Internet Routing Table: 97 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 527 Unregistered ASNs in the Routing Table: 179 Number of 32-bit ASNs allocated by the RIRs: 92 Prefixes from 32-bit ASNs in the Routing Table: 15 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 229 Number of addresses announced to Internet: 1996544544 Equivalent to 119 /8s, 0 /16s and 218 /24s Percentage of available address space announced: 53.9 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 75.5 Total number of prefixes smaller than registry allocations: 136565 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 64198 Total APNIC prefixes after maximum aggregation: 22979 APNIC Deaggregation factor: 2.79 Prefixes being announced from the APNIC address blocks: 61033 Unique aggregates announced from the APNIC address blocks: 27621 APNIC Region origin ASes present in the Internet Routing Table: 3521 APNIC Prefixes per ASN: 17.33 APNIC Region origin ASes announcing only one prefix: 948 APNIC Region transit ASes present in the Internet Routing Table: 549 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 397493152 Equivalent to 23 /8s, 177 /16s and 67 /24s Percentage of available APNIC address space announced: 79.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123281 Total ARIN prefixes after maximum aggregation: 65154 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 92814 Unique aggregates announced from the ARIN address blocks: 35503 ARIN Region origin ASes present in the Internet Routing Table: 12756 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4905 ARIN Region transit ASes present in the Internet Routing Table: 1225 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 414233632 Equivalent to 24 /8s, 176 /16s and 180 /24s Percentage of available ARIN address space announced: 79.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 62962 Total RIPE prefixes after maximum aggregation: 37144 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 57789 Unique aggregates announced from the RIPE address blocks: 38547 RIPE Region origin ASes present in the Internet Routing Table: 12611 RIPE Prefixes per ASN: 4.58 RIPE Region origin ASes announcing only one prefix: 6637 RIPE Region transit ASes present in the Internet Routing Table: 1914 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 387972704 Equivalent to 23 /8s, 31 /16s and 254 /24s Percentage of available RIPE address space announced: 82.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23192 Total LACNIC prefixes after maximum aggregation: 5739 LACNIC Deaggregation factor: 4.04 Prefixes being announced from the LACNIC address blocks: 21390 Unique aggregates announced from the LACNIC address blocks: 11857 LACNIC Region origin ASes present in the Internet Routing Table: 1063 LACNIC Prefixes per ASN: 20.12 LACNIC Region origin ASes announcing only one prefix: 338 LACNIC Region transit ASes present in the Internet Routing Table: 176 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 60553600 Equivalent to 3 /8s, 155 /16s and 249 /24s Percentage of available LACNIC address space announced: 60.2 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4437 Total AfriNIC prefixes after maximum aggregation: 1371 AfriNIC Deaggregation factor: 3.24 Prefixes being announced from the AfriNIC address blocks: 3977 Unique aggregates announced from the AfriNIC address blocks: 1388 AfriNIC Region origin ASes present in the Internet Routing Table: 280 AfriNIC Prefixes per ASN: 14.20 AfriNIC Region origin ASes announcing only one prefix: 86 AfriNIC Region transit ASes present in the Internet Routing Table: 57 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC addresses announced to Internet: 9909248 Equivalent to 0 /8s, 151 /16s and 52 /24s Percentage of available AfriNIC address space announced: 29.5 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1646 6412 378 Korea Telecom (KIX) 17488 1521 110 97 Hathway IP Over Cable Interne 4755 1202 428 180 TATA Communications formerly 9583 1068 107 363 Sify Limited 4134 904 16247 368 CHINANET-BACKBONE 18101 751 198 25 Reliance Infocom Ltd Internet 7545 718 158 96 TPG Internet Pty Ltd 9498 681 297 53 BHARTI BT INTERNET LTD. 24560 664 226 178 Bharti Airtel Ltd. 9829 627 479 15 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4375 3434 344 bellsouth.net, inc. 209 2829 4037 620 Qwest 1785 1787 732 145 PaeTec Communications, Inc. 4323 1640 1080 374 Time Warner Telecom 20115 1593 1423 726 Charter Communications 7018 1445 5878 999 AT&T WorldNet Services 2386 1252 715 893 AT&T Data Communications Serv 6478 1225 295 494 AT&T Worldnet Services 11492 1224 192 12 Cable One 3356 1142 10976 438 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1037 188 7 TEDATA 3292 443 1765 388 TDC Tele Danmark 30890 439 88 201 SC Kappa Invexim SRL 12479 396 578 6 Uni2 Autonomous System 3301 338 1669 304 TeliaNet Sweden 3320 337 7064 288 Deutsche Telekom AG 8866 336 109 22 Bulgarian Telecommunication C 3215 333 2898 102 France Telecom Transpac 29049 331 26 3 AzerSat LLC. 8551 312 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1486 2834 230 UniNet S.A. de C.V. 10620 737 161 94 TVCABLE BOGOTA 11830 687 299 9 Instituto Costarricense de El 22047 619 302 14 VTR PUNTO NET S.A. 7303 508 253 78 Telecom Argentina Stet-France 6471 439 95 42 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 406 118 74 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 380 506 23 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 613 74 40 LINKdotNET AS number 20858 274 34 3 This AS will be used to conne 3741 268 857 226 The Internet Solution 2018 241 215 141 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 128 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 117 555 66 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4375 3434 344 bellsouth.net, inc. 209 2829 4037 620 Qwest 1785 1787 732 145 PaeTec Communications, Inc. 4766 1646 6412 378 Korea Telecom (KIX) 4323 1640 1080 374 Time Warner Telecom 20115 1593 1423 726 Charter Communications 17488 1521 110 97 Hathway IP Over Cable Interne 8151 1486 2834 230 UniNet S.A. de C.V. 7018 1445 5878 999 AT&T WorldNet Services 2386 1252 715 893 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2829 2209 Qwest 1785 1787 1642 PaeTec Communications, Inc. 17488 1521 1424 Hathway IP Over Cable Interne 4766 1646 1268 Korea Telecom (KIX) 4323 1640 1266 Time Warner Telecom 8151 1486 1256 UniNet S.A. de C.V. 11492 1224 1212 Cable One 18566 1061 1051 Covad Communications 8452 1037 1030 TEDATA 4755 1202 1022 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.12.96.0/19 15834 MenaNet network Autonomous Sy 62.12.107.0/24 15834 MenaNet network Autonomous Sy Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:54 /12:160 /13:309 /14:571 /15:1125 /16:10326 /17:4584 /18:7858 /19:16901 /20:19829 /21:19395 /22:24607 /23:24858 /24:145830 /25:673 /26:808 /27:509 /28:104 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2851 4375 bellsouth.net, inc. 209 1569 2829 Qwest 4766 1378 1646 Korea Telecom (KIX) 17488 1302 1521 Hathway IP Over Cable Interne 1785 1208 1787 PaeTec Communications, Inc. 11492 1188 1224 Cable One 18566 1042 1061 Covad Communications 8452 1006 1037 TEDATA 2386 942 1252 AT&T Data Communications Serv 9583 917 1068 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:179 12:2193 13:2 15:21 16:3 17:5 20:35 24:1116 32:51 38:539 40:96 41:1734 43:1 44:2 47:11 52:3 55:2 56:3 57:26 58:520 59:608 60:459 61:1101 62:1113 63:2008 64:3414 65:2431 66:3562 67:1468 68:650 69:2462 70:528 71:159 72:1604 73:2 74:1390 75:203 76:296 77:792 78:546 79:319 80:962 81:820 82:552 83:394 84:604 85:1013 86:400 87:621 88:353 89:1364 90:42 91:1936 92:298 93:1105 94:1017 95:292 96:96 97:176 98:192 99:16 110:1 111:1 112:11 113:74 114:163 115:213 116:1160 117:476 118:267 119:628 120:137 121:702 122:927 123:508 124:842 125:1271 128:223 129:222 130:134 131:410 132:71 133:9 134:344 135:35 136:223 137:141 138:145 139:80 140:411 141:105 142:377 143:317 144:319 145:39 146:371 147:146 148:522 149:234 150:141 151:200 152:150 153:132 154:10 155:257 156:171 157:271 158:159 159:239 160:282 161:138 162:274 163:142 164:516 165:505 166:274 167:355 168:672 169:161 170:469 171:40 172:10 173:196 174:55 186:6 187:60 189:326 190:2534 192:5798 193:4184 194:3332 195:2683 196:1070 198:3683 199:3284 200:5535 201:1485 202:7815 203:7968 204:3926 205:2144 206:2354 207:2794 208:3819 209:3482 210:2607 211:1122 212:1513 213:1704 214:68 215:30 216:4575 217:1196 218:371 219:407 220:1209 221:449 222:296 End of report From msmith at internap.com Fri Feb 6 12:20:14 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 6 Feb 2009 13:20:14 -0500 Subject: One /22 Two ISP no BGP Message-ID: <65C5927BEED3C2428307863DB5C6C6FB0200627E@cx49.800onemail.com> Ebgp multi-hop is a great idea. Have others seen this done for non-bandwidth customers? ...a 'bgp-only' service...?... ...catalog that right along with v6 and multicast tunnels... ----- Original Message ----- From: Joe Maimon To: Jason Biel Cc: nanog at nanog.org Sent: Fri Feb 06 13:13:14 2009 Subject: Re: One /22 Two ISP no BGP Jason Biel wrote: > Charles, > > As I mentioned earlier, you'll want to have one provider announce the /22 > unweighted and the other announce it weighted. Just pick the better of the > two providers as the primary. Don't base it soley off bandwidth, but check > your SLA and any recent outage occurances. > > Traffic will flow in via the primary until that link to you drops, the > provider will remove the route, and traffic will come in the back up route. Perhaps ebgp-multihop with this ISP's upstream provider might offer you an advantage combined with this approach. Probably worth a try. > > > > On Fri, Feb 6, 2009 at 11:14 AM, Charles Regan wrote: > >> I'll explain. We are a small ISP on a very remote Island. >> We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from >> ISP2. >> >> They are the only two we can get bandwidth. >> >> So we are stuck with ISP1 that doesn't support BGP. >> >> On Fri, Feb 6, 2009 at 12:48 PM, Azinger, Marla >> wrote: >>> im curiouse. you probably had a reason for wanting to do that. So cant >> you find another ISP that will do what you want? >>> Cheers >>> Marla >>> >>> -----Original Message----- >>> From: Charles Regan [mailto:charles.regan at gmail.com] >>> Sent: Friday, February 06, 2009 8:29 AM >>> To: nanog at nanog.org >>> Subject: One /22 Two ISP no BGP >>> >>> I want to advertise my /22 to two different ISP on different POP. >>> >>> I can't use BGP as ISP1 doesn't support it. >>> >>> Any suggestions ? >>> >>> Thanks, >>> Charles >>> >>> >> > > From steve at ibctech.ca Fri Feb 6 12:31:34 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 06 Feb 2009 13:31:34 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: <65C5927BEED3C2428307863DB5C6C6FB0200627E@cx49.800onemail.com> References: <65C5927BEED3C2428307863DB5C6C6FB0200627E@cx49.800onemail.com> Message-ID: <498C8206.2020102@ibctech.ca> Michael Smith wrote: > Ebgp multi-hop is a great idea. > > Have others seen this done for non-bandwidth customers? ...a 'bgp-only' service...?... Hmmm...given that I'm in a similar situation as the original poster, I wonder if this would be a feasible strategy to investigate. Since our ISP's transit providers already carry our traffic anyway, one has to wonder if they would be up to multi-hop peering directly to me instead. If this is being done, would anyone care to share any pricing for the initial turn-up? Steve From deric.kwok2000 at gmail.com Fri Feb 6 12:43:59 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Fri, 6 Feb 2009 13:43:59 -0500 Subject: Networking performance Message-ID: <40d8a95a0902061043u4988fc7bm2178cb47c554a43f@mail.gmail.com> Hi I would like to ask your professional experience about switch throughput I have Gig Switchs eg: H P3400 /3500, cisco c4 948../ dlink In their spec, they said that it can handles Gig So far, I couldn't see their ports are used up over 200M in mrtg graph when I try to transfer 3G size files to files between computers ls there any limitation in those switchs? or I have to do configuration eg: put it full duplex instead of auto Thank you for your help From bicknell at ufp.org Fri Feb 6 12:45:20 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 6 Feb 2009 13:45:20 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: References: <2E2FECEBAE57CC4BAACDE67638305F10482E5B4F66@ROCH-EXCH1.corp.pvt> Message-ID: <20090206184519.GB84034@ussenterprise.ufp.org> In a message written on Fri, Feb 06, 2009 at 01:14:52PM -0400, Charles Regan wrote: > I'll explain. We are a small ISP on a very remote Island. > We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from ISP2. Perhaps you could post the IP addresses on your end of both of these links? I believe then NANOG may be able to shame the appropriate folks into doing BGP for you. :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From cmills at accessdc.com Fri Feb 6 12:46:35 2009 From: cmills at accessdc.com (Mills, Charles) Date: Fri, 6 Feb 2009 13:46:35 -0500 Subject: Networking performance In-Reply-To: <40d8a95a0902061043u4988fc7bm2178cb47c554a43f@mail.gmail.com> References: <40d8a95a0902061043u4988fc7bm2178cb47c554a43f@mail.gmail.com> Message-ID: <58E0B21FC367B24485855A1DBD96B0BB11C055E0@adc-prd-exch1.internal.accessdc.com> Make sure MRTG is using SNMPv2 when it does its data gathering otherwise you'll suffer from counter rollover. -----Original Message----- From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] Sent: Friday, February 06, 2009 1:44 PM To: nanog at nanog.org Subject: Networking performance Hi I would like to ask your professional experience about switch throughput I have Gig Switchs eg: H P3400 /3500, cisco c4 948../ dlink In their spec, they said that it can handles Gig So far, I couldn't see their ports are used up over 200M in mrtg graph when I try to transfer 3G size files to files between computers ls there any limitation in those switchs? or I have to do configuration eg: put it full duplex instead of auto Thank you for your help This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From joelja at bogus.com Fri Feb 6 12:59:29 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 06 Feb 2009 10:59:29 -0800 Subject: Networking performance In-Reply-To: <40d8a95a0902061043u4988fc7bm2178cb47c554a43f@mail.gmail.com> References: <40d8a95a0902061043u4988fc7bm2178cb47c554a43f@mail.gmail.com> Message-ID: <498C8891.20100@bogus.com> Deric Kwok wrote: > Hi > > I would like to ask your professional experience about switch throughput > > I have Gig Switchs eg: H P3400 /3500, cisco c4 948../ dlink > In their spec, they said that it can handles Gig > So far, I couldn't see their ports are used up over 200M in mrtg graph > when I try to transfer 3G size files to files between computers So, first off there's the question of sample interval vs the actaul time the transfer takes... I'd use an instrument other than mrtg to measure the spead of the transfer for example bytes transfer/wall clock time. Second, you're benchmarking a bunch of components other than the network, like your disks for example, which are likely slower than the 125MB/s you're trying to measure... Switch to ttcp or iperf for your throughput measurement and you'll probably get a lot closer to measuring what you're in fact trying to measure. > ls there any limitation in those switchs? > or I have to do configuration eg: put it full duplex instead of auto autonegotiation on gigabit interfaces should almost always produce the desired result. > Thank you for your help > From patrick at ianai.net Fri Feb 6 13:17:05 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 6 Feb 2009 14:17:05 -0500 Subject: Networking performance In-Reply-To: <40d8a95a0902061043u4988fc7bm2178cb47c554a43f@mail.gmail.com> References: <40d8a95a0902061043u4988fc7bm2178cb47c554a43f@mail.gmail.com> Message-ID: On Feb 6, 2009, at 1:43 PM, Deric Kwok wrote: > I would like to ask your professional experience about switch > throughput > > I have Gig Switchs eg: H P3400 /3500, cisco c4 948../ dlink > In their spec, they said that it can handles Gig > So far, I couldn't see their ports are used up over 200M in mrtg graph > when I try to transfer 3G size files to files between computers > > ls there any limitation in those switchs? Those switches do more than 200 Mbps. (BTW, Are you measuring megaBITs or megaBYTES?) I suspect the machines transfering data, not the switches. -- TTFN, patrick From beckman at angryox.com Fri Feb 6 13:51:06 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 6 Feb 2009 14:51:06 -0500 Subject: L3: Google from DC via the Netherlands? In-Reply-To: References: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> Message-ID: On Fri, 6 Feb 2009, Peter Beckman wrote: > I'm OK to that IP as well, but when I query www.google.com, I get multiple > IPs, but here are the ones that in in 147: > > DNS Server IP Route (for me) > 205.234.170.217 (tiggee) 74.125.79.147 Amsterdam > 208.67.222.222 (opendns) 64.233.183.147 Amsterdam > 4.2.2.1 (verizon) 74.125.19.147 San Jose > 198.6.1.3 (uu.net/verizon) 74.125.47.147 Washington DC (yay) So someone from Google has been helpful in pointing out that the resolver IP, not YOUR IP, is the one that determines where you get routed to when you make a request for www.google.com. Which is simply due to the way things are implemented, which makes sense. The problem is, here I am, just some guy, and 99%* of the Internet resolves to the same IP(s) regardless of who I ask. But then the other 1%*, and this would likely be larger players who are diversified and have systems in multiple locations and networks, do something funky and give a different address depending on where your DNS server is in the network. Then throw in the possibility that YOUR DNS servers are anycasted for great justice, or at least for good reliability. Now when you base YOUR answer on the caching server's IP address, well, it may not make sense. It seems that Tiggee and OpenDNS are anycasted, as is DNS Advantage, as well as some root nameservers. Thus my problem -- because I ask two free resolving name services, which I believe to be anycasted, where to go, I get routed to Amsterdam instead of a few miles down the road in Ashburn, VA, and spend 100ms instead of 10ms travelling the globe, costing someone more money for Atlantic Ocean transit when it was unnecessary. SO. Who's problem is this to fix? Is it: 1. Me? Am I a dope for using a very reliable but anycasted resolving name service? Clearly, I could just use the handy dandy easy to remember because I worked there 198.6.1.x, or is that an Internet faux pas because technically I wasn't given permission to use it? 2. Google? They probably have an interest in making sure my experience to their services are fast and as close to me as possible, but I'm probably a minority and not worth the effort of refactoring a giant DNS implementation just to fix my one problem, nay, inconvenience. 3. Anycasted DNS Providers? Not sure how they could fix it, other than flag certain domains as special, and do something special for them, but man that smells like a hack. 4. My ISP? Does the ISP have to gripe at Google for providing bad results that causes traffic to go over expensive lines when it could have easily gone locally and much more cheaply? I'm assuming that sending my traffic over the Atlantic to the Netherlands costs SOMEONE more money than if I had gone to a datacenter nearby, both physically and network-wise. 5. Nobody? Is it just the price the customer (me, who helps generate income for Google by using Google and clicking AdWords ads all day) pays for the reliability, redundancy and fault tolerance that Google has implemented? I think things are working as implemented -- it's not "broken," but it seems it could be better. Then again, sometimes better is more expensive than the status quo, either in time or money or both. NOTE: I do not admit to knowing that 100% of what I've written is fact, and if you know better than I, please correct me and show me the light. * Numbers have no basis, just a guess. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From dts at senie.com Fri Feb 6 13:54:02 2009 From: dts at senie.com (Daniel Senie) Date: Fri, 06 Feb 2009 14:54:02 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <20090205220614.GA18219@jeeves.rigozsaurus.com> <016f01c987f0$98865110$c992f330$@edu> Message-ID: <498C955A.80003@senie.com> Randy Bush wrote: >> Wii should not even consider developing " a cool new protocol for the Wii" >> that is not NAT compliant via V4 or V6. > > what is "nat compliant?" RFC 3235 discusses how to make your application work in the Internet reality that exists today, with NAT boxes everywhere. The document is entitled, "Network Address Translator (NAT)-Friendly Application Design Guidelines." http://www.ietf.org/rfc/rfc3235.txt This was a product of the IETF NAT Working Group, published in 2002. Note though that this document provides guidance, not compliancy requirements. Nonetheless, application developers can find useful information on how to avoid problems. -- ----------------------------------------------------------------- Daniel Senie dts at senie.com Amaranth Networks Inc. http://www.amaranth.com Kindness in words creates confidence. Kindness in thinking creates profoundness. Kindness in giving creates love. -- Lao Tsu From jbates at brightok.net Fri Feb 6 14:37:00 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 06 Feb 2009 14:37:00 -0600 Subject: v6 & DSL / Cable modems In-Reply-To: <20090206181545.GE5164@isc.org> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> <20090206181545.GE5164@isc.org> Message-ID: <498C9F6C.7050109@brightok.net> David W. Hankins wrote: > > What most people do of course is VRRP. > I agree, and I have done this in the past. However, I am very happy with the support of IPv6 to do away with requiring VRRP. > Barring that, you just specify multiple default routers, and the > client will select the router that still responds to ARP. But > support for this is not universal, so. Always a problem, though arp doesn't timeout when a end node disappears in a reasonable fashion. > When that isn't available, what I have done in the past here is to use > the DHCP server to give out a default router option that is sorted > according to the DHCP relay agent that was used to reach the server > (keyed on giaddr contents). > This is a nice method as well, though limited by the half life of the DHCP lease. It also doesn't address the fact that you might be handing out IP addresses from *both* DHCP relay agents with cross redundancy for gateways. > No need to take on 'routed -q' in the client, it can stay a simple > dumb host, with all configuration complexity in the DHCP server or > negotiated in HA by the routers. Dumb hosts is exactly what makes life infuriating. I want smart hosts. The network should be relatively dumb. Perhaps I'm mistaken, but the premise of IP was that hosts are smart and networks are dumb. Then we started making smart networks to break things. I want built in multiple IP bindings on my hosts. I'd like (Windows 7 without having to call netsh, perhaps?) support for static and dynamic addresses (privacy extensions are beautiful). I especially want support for multiple dynamic addresses with communication to the host that it should start using a newer address for future requests, yet finish up what it's doing with the old address before unbonding it. Please don't get me wrong. I don't run a corporate network. I have my own little server farm and I have support to edge customers. What customer's do with the prefixes I give them is up to them. DHCP/SLAAC, it's all good. I'd rather not run DHCP for my servers or my little helpdesk network. On a standard ISP edge, I expect to see hybrid solutions; depending on the layout. Jack From william.allen.simpson at gmail.com Fri Feb 6 14:58:19 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 06 Feb 2009 15:58:19 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: <20090206184519.GB84034@ussenterprise.ufp.org> References: <2E2FECEBAE57CC4BAACDE67638305F10482E5B4F66@ROCH-EXCH1.corp.pvt> <20090206184519.GB84034@ussenterprise.ufp.org> Message-ID: <498CA46B.3080604@gmail.com> Leo Bicknell wrote: > In a message written on Fri, Feb 06, 2009 at 01:14:52PM -0400, Charles Regan wrote: >> I'll explain. We are a small ISP on a very remote Island. >> We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from ISP2. > > Perhaps you could post the IP addresses on your end of both of these > links? > > I believe then NANOG may be able to shame the appropriate folks into > doing BGP for you. :) > Leo's cogent answer actually caused me to go back and read the thread. :-) This is a group for network operations. Generally, we talk about public technical information, openly and transparently. What Island? What small ISP? Who are ISP1 and ISP2? From william.allen.simpson at gmail.com Fri Feb 6 15:04:18 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 06 Feb 2009 16:04:18 -0500 Subject: L3: Google from DC via the Netherlands? In-Reply-To: References: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> Message-ID: <498CA5D2.4030602@gmail.com> Peter Beckman wrote: > SO. Who's problem is this to fix? Is it: > > 1. Me? Am I a dope for using a very reliable but anycasted resolving > name service? Clearly, I could just use the handy dandy easy to > remember because I worked there 198.6.1.x, or is that an Internet > faux pas because technically I wasn't given permission to use it? > We are network operators. We all use robust distributed name servers, along with our own (usually hidden) primary. But as a network operator, why aren't you running your own caching resolver? Not since the '80s have I ever needed to point at somebody else's resolver, the DNS is much better distributed now. From bicknell at ufp.org Fri Feb 6 15:15:53 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 6 Feb 2009 16:15:53 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: References: <20090206184519.GB84034@ussenterprise.ufp.org> Message-ID: <20090206211553.GA91799@ussenterprise.ufp.org> From http://en.wikipedia.org/wiki/Smiley The two original text smileys, :-) to indicate a joke and :-( to mark things that are not a joke were invented on September 19, 1982 by Scott E. Fahlman, a research professor at Carnegie Mellon University's Department of Computer Science. His original post at the CMU CS general board, where he suggested the use of the smileys, was retrieved on September 10, 2002 by Jeff Baird from an October 1982 backup tape of the spice vax (cmu-750x) as proof to support the claim.[14] In a message written on Fri, Feb 06, 2009 at 03:36:14PM -0500, Dean Anderson wrote: > I doubt NANOG/BIND Cartel mafia can shame anyone, given its (members and > administrators) shameful and possibly illegal activities. > > --Dean > > > On Fri, 6 Feb 2009, Leo Bicknell wrote: > > > In a message written on Fri, Feb 06, 2009 at 01:14:52PM -0400, Charles Regan wrote: > > > I'll explain. We are a small ISP on a very remote Island. > > > We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from ISP2. > > > > Perhaps you could post the IP addresses on your end of both of these > > links? > > > > I believe then NANOG may be able to shame the appropriate folks into > > doing BGP for you. :) > > > > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From David_Hankins at isc.org Fri Feb 6 15:29:54 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 6 Feb 2009 13:29:54 -0800 Subject: v6 & DSL / Cable modems In-Reply-To: <498C9F6C.7050109@brightok.net> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> <20090206181545.GE5164@isc.org> <498C9F6C.7050109@brightok.net> Message-ID: <20090206212954.GG5164@isc.org> On Fri, Feb 06, 2009 at 02:37:00PM -0600, Jack Bates wrote: > I agree, and I have done this in the past. However, I am very happy with > the support of IPv6 to do away with requiring VRRP. I can respect that. I don't agree with it, mostly I don't think IPv6 really has obviated that need, but it's a reasonable position to have. > This is a nice method as well, though limited by the half life of the DHCP > lease. It also doesn't address the fact that you might be handing out IP > addresses from *both* DHCP relay agents with cross redundancy for gateways. Minor note; the redundancy problem isn't. :) It's solved trivially usually without any changes in config or design. DHCP just works that way. > Dumb hosts is exactly what makes life infuriating. I want smart hosts. The > network should be relatively dumb. Perhaps I'm mistaken, but the premise of > IP was that hosts are smart and networks are dumb. Then we started making > smart networks to break things. It is issues like this that we so often find polarizing. I'm not for a 'smart internet core', but rather for intelligent 'assist services' for simple/dumb clients to use to cross a simple/dumb network. I think expanding the behaviour of IP end hosts is going to create a real mess in terms of emergent behaviours. > I want built in multiple IP bindings on my hosts. I'd like (Windows 7 I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents). I prefer the model where I configure one (1) DHCPv6 server that does that for me. DHCPv6 and RA have all the same multiple-address features, and share the same semantics in terms of preferred and valid lifetimes. It gets back to the original philosophical question of design; should the algorithm run on the clients or on the network's assist services? Here we may never agree, but my position is that placing the burden on the assist services simplifies mandatory client implementation, and centralizes configuration management and control. Or put another way, it fulfills a larger set of requirements, while still keeping the rest as a subset of its offering. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From owen at delong.com Fri Feb 6 16:01:55 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Feb 2009 14:01:55 -0800 Subject: v6 & DSL / Cable modems In-Reply-To: <498C9F6C.7050109@brightok.net> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> <20090206181545.GE5164@isc.org> <498C9F6C.7050109@brightok.net> Message-ID: On Feb 6, 2009, at 12:37 PM, Jack Bates wrote: > David W. Hankins wrote: >> What most people do of course is VRRP. > > I agree, and I have done this in the past. However, I am very happy > with the support of IPv6 to do away with requiring VRRP. > If RA does that in your situation, great. In my situation, there are actually cases where I need different VRRP groups on the same LAN and need to point different things at different routers from hosts. It would be nice if DHCPv6 (or DHCPv4 for that matter) could include not only a default, but, a static routing table in what it distributes. Nonetheless, the built in assumption in IPv6 RA that all routers are equal is simply not valid in all environments and VRRP with DHCP provides some ability to cope in environments where that isn't true. >> Barring that, you just specify multiple default routers, and the >> client will select the router that still responds to ARP. But >> support for this is not universal, so. > > Always a problem, though arp doesn't timeout when a end node > disappears in a reasonable fashion. > Some OS handle this better than others. Try, wait, try, wait, re-arp, wait, fall over to other gateway -- 9 sec. delay in some situations. >> When that isn't available, what I have done in the past here is to >> use >> the DHCP server to give out a default router option that is sorted >> according to the DHCP relay agent that was used to reach the server >> (keyed on giaddr contents). > > This is a nice method as well, though limited by the half life of > the DHCP lease. It also doesn't address the fact that you might be > handing out IP addresses from *both* DHCP relay agents with cross > redundancy for gateways. > I'm not sure what you mean by that. >> No need to take on 'routed -q' in the client, it can stay a simple >> dumb host, with all configuration complexity in the DHCP server or >> negotiated in HA by the routers. > > Dumb hosts is exactly what makes life infuriating. I want smart > hosts. The network should be relatively dumb. Perhaps I'm mistaken, > but the premise of IP was that hosts are smart and networks are > dumb. Then we started making smart networks to break things. > That's great on paper, but, in some real world scenarios, it's not as supportable as one might want. The best thing is if both are smart in helpful ways and are willing to be told not to out-smart themselves in environments where that is counterproductive. > I want built in multiple IP bindings on my hosts. I'd like (Windows > 7 without having to call netsh, perhaps?) support for static and > dynamic addresses (privacy extensions are beautiful). I especially > want support for multiple dynamic addresses with communication to > the host that it should start using a newer address for future > requests, yet finish up what it's doing with the old address before > unbonding it. > Could you please explain a good reliable method for source address selection in a multiple IP binding scenario? That last one is available albeit really hard to support in any sort of scale. > Please don't get me wrong. I don't run a corporate network. I have > my own little server farm and I have support to edge customers. What > customer's do with the prefixes I give them is up to them. DHCP/ > SLAAC, it's all good. I'd rather not run DHCP for my servers or my > little helpdesk network. On a standard ISP edge, I expect to see > hybrid solutions; depending on the layout. > I don't know very many people who want DHCP for servers. However, when you're managing a bunch of user's desktops and laptops, DHCP is the only way to scale things reasonably in some environments. Owen From stu at spacehopper.org Fri Feb 6 16:57:47 2009 From: stu at spacehopper.org (Stuart Henderson) Date: Fri, 6 Feb 2009 22:57:47 +0000 (UTC) Subject: L3: Google from DC via the Netherlands? References: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> Message-ID: On 2009-02-06, Peter Beckman wrote: > On Fri, 6 Feb 2009, Peter Beckman wrote: > >> I'm OK to that IP as well, but when I query www.google.com, I get multiple >> IPs, but here are the ones that in in 147: >> >> DNS Server IP Route (for me) >> 205.234.170.217 (tiggee) 74.125.79.147 Amsterdam >> 208.67.222.222 (opendns) 64.233.183.147 Amsterdam >> 4.2.2.1 (verizon) 74.125.19.147 San Jose >> 198.6.1.3 (uu.net/verizon) 74.125.47.147 Washington DC (yay) > > So someone from Google has been helpful in pointing out that the resolver > IP, not YOUR IP, is the one that determines where you get routed to when > you make a request for www.google.com. Which is simply due to the way > things are implemented, which makes sense. you don't show the route to the DNS servers though... the resolver's queries to the auth servers obviously aren't going to be _sourced_ from the anycast address, or the auth servers' answers would often likely end up going to the wrong instance of the resolver. so, at least in google's nameservers opinion, the outgoing address used when the name was looked-up is closer to their european site... so perhaps you have ended up querying anycast instances of resolvers close on the network to the servers with the addresses which get returned, i.e. using resolvers nearer to SJC/AMS. if that's the case, i'd be much more concerned about using a nearby resolver for my dns queries, which i use all the time, than being worried about an extra 100ms the times i use google. (ok, it's common, but nowhere near as common as querying dns). there's another possibility though; perhaps these public resolvers share caches between their various anycast instances, and it so happens that the lookup that got cached was done from a european site. From fergdawgster at gmail.com Fri Feb 6 17:35:54 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 6 Feb 2009 15:35:54 -0800 Subject: From San Jose to Google.com - via Europe Message-ID: <6cd462c00902061535m1aa6e402p413a274bc9cad061@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was kind of wondering why my connectivity slowed to a crawl a little while ago... Any idea what is up with this? From Comcast in San Jose: %tracert www.google.com Tracing route to www.l.google.com [74.125.39.103] over a maximum of 30 hops: [snip] 5 24 ms 13 ms 9 ms te-9-1-ur06.sanjose.ca.sfba.comcast.net [68.87.1 92.54] 6 11 ms 11 ms * te-0-3-0-4-ar01.oakland.ca.sfba.comcast.net [68. 87.226.229] 7 * 23 ms 13 ms pos-0-2-0-0-cr01.sacramento.ca.ibone.comcast.net [68.86.90.141] 8 15 ms 26 ms 17 ms pos-0-9-0-0-cr01.sanjose.ca.ibone.comcast.net [6 8.86.85.181] 9 18 ms 21 ms 14 ms xe-8-3-0.edge1.sanjose1.level3.net [4.71.118.13] 10 33 ms 13 ms 16 ms vlan89.csw3.sanjose1.level3.net [4.68.18.190] 11 21 ms 18 ms 36 ms ae-84-84.ebr4.sanjose1.level3.net [4.69.134.249] 12 105 ms * * ae-2.ebr4.newyork1.level3.net [4.69.135.186] 13 121 ms 108 ms 111 ms ae-94-94.csw4.newyork1.level3.net [4.69.134.126] 14 126 ms 109 ms 109 ms ae-93-93.ebr3.newyork1.level3.net [4.69.134.109] 15 93 ms 93 ms 102 ms ae-3-3.ebr2.washington1.level3.net [4.69.132.89] 16 190 ms 184 ms 192 ms ae-42-42.ebr2.frankfurt1.level3.net [4.69.137.53 ] 17 184 ms 210 ms 185 ms ae-62-62.csw1.frankfurt1.level3.net [4.69.140.18 ] 18 182 ms 181 ms * ae-1-69.edge3.frankfurt1.level3.net [4.68.23.11] 19 184 ms 195 ms 181 ms 62.67.33.114 20 185 ms 184 ms 184 ms 209.85.254.108 21 198 ms 185 ms 184 ms 209.85.240.134 22 182 ms 192 ms 184 ms 209.85.254.134 23 181 ms 183 ms 181 ms fx-in-f103.google.com [74.125.39.103] Trace complete. 62.67.33.114: inetnum: 62.67.32.0 - 62.67.33.255 netname: FRANKFURT-SERIAL1 descr: DE transfer network1 country: DE admin-c: LTHM tech-c: LTEE status: ASSIGNED PA mnt-by: LEVEL3-MNT source: RIPE # Filtered role: LEVEL3 Hostmaster address: Level (3) Communications address: 100 Leman Street address: London address: E1 8EU - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJjMlLq1pz9mNUZTMRAkRxAJ44p1olXBSJATT3IFf+vkKyAvmOxQCdES0P 9EwfbAHSX0ioHiKE2rLRV2c= =9v8s -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From trall at almaden.ibm.com Fri Feb 6 17:51:42 2009 From: trall at almaden.ibm.com (Tony Rall) Date: Fri, 6 Feb 2009 15:51:42 -0800 Subject: From San Jose to Google.com - via Europe In-Reply-To: <6cd462c00902061535m1aa6e402p413a274bc9cad061@mail.gmail.com> Message-ID: Maybe you didn't read the thread "L3: Google from DC via the Netherlands? " Probably the same issue (your nameserver is now perhaps quite remote from you). -- Tony Rall From fergdawgster at gmail.com Fri Feb 6 17:55:49 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 6 Feb 2009 15:55:49 -0800 Subject: From San Jose to Google.com - via Europe In-Reply-To: References: <6cd462c00902061535m1aa6e402p413a274bc9cad061@mail.gmail.com> Message-ID: <6cd462c00902061555p52dddaaanc09a347a730e6524@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Feb 6, 2009 at 3:51 PM, Tony Rall wrote: > Maybe you didn't read the thread "L3: Google from DC via the Netherlands? > " > > Probably the same issue (your nameserver is now perhaps quite remote from > you). > No, I guess I missed it, but reviewing the archives I see my question is already answered. Thanks for that -- sorry for the noise. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJjM3qq1pz9mNUZTMRAl1yAKCFXsdRAW6bT8FZqNcqg6bFH/ByxgCdE4kA u/kTTqwOqNpKQhsMyuoFSRE= =2i5n -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Fri Feb 6 18:11:15 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 6 Feb 2009 16:11:15 -0800 Subject: From San Jose to Google.com - via Europe In-Reply-To: <6cd462c00902061555p52dddaaanc09a347a730e6524@mail.gmail.com> References: <6cd462c00902061535m1aa6e402p413a274bc9cad061@mail.gmail.com> <6cd462c00902061555p52dddaaanc09a347a730e6524@mail.gmail.com> Message-ID: <6cd462c00902061611i57bdf4dbxaf559ee47fd7e2df@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Feb 6, 2009 at 3:55 PM, Paul Ferguson wrote: > > On Fri, Feb 6, 2009 at 3:51 PM, Tony Rall wrote: > >> Maybe you didn't read the thread "L3: Google from DC via the >> Netherlands? " >> >> Probably the same issue (your nameserver is now perhaps quite remote >> from you). >> > > > No, I guess I missed it, but reviewing the archives I see my question is > already answered. > > Thanks for that -- sorry for the noise. > Just as an FYI, I did determine (hint from earlier thread) that I take "the long route" when I am connected to my corporate SLL VPN (which forces DNS resolution priority to my corporate DNS servers), but when I disconnect, I take the short route (and use OpenDNS servers for DNS resolution)... Go figure. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJjNGRq1pz9mNUZTMRAhioAKDgg3dm8noVz3EfMjs5+H2xloYgfACfepCc a1LREz0mST06K4EMODI8yZQ= =DvNx -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From robert at ufl.edu Fri Feb 6 18:15:37 2009 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 6 Feb 2009 19:15:37 -0500 Subject: From San Jose to Google.com - via Europe In-Reply-To: <6cd462c00902061611i57bdf4dbxaf559ee47fd7e2df@mail.gmail.com> References: <6cd462c00902061535m1aa6e402p413a274bc9cad061@mail.gmail.com> <6cd462c00902061555p52dddaaanc09a347a730e6524@mail.gmail.com> <6cd462c00902061611i57bdf4dbxaf559ee47fd7e2df@mail.gmail.com> Message-ID: <00f201c988b9$33a023b0$9ae06b10$@edu> I have had similar steaming issues with XMRadio. If I am at home and have a VPN tunnel open to campus my XM steam is poor and choppy on a regular basis. I need to open the stream before my VPN to get high quality. Different DNS, the tunnel DNS does not reflect the same path to the stream. Akamai instead of google. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Friday, February 06, 2009 7:11 PM To: Tony Rall Cc: nanog at nanog.org Subject: Re: From San Jose to Google.com - via Europe -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Feb 6, 2009 at 3:55 PM, Paul Ferguson wrote: > > On Fri, Feb 6, 2009 at 3:51 PM, Tony Rall wrote: > >> Maybe you didn't read the thread "L3: Google from DC via the >> Netherlands? " >> >> Probably the same issue (your nameserver is now perhaps quite remote >> from you). >> > > > No, I guess I missed it, but reviewing the archives I see my question is > already answered. > > Thanks for that -- sorry for the noise. > Just as an FYI, I did determine (hint from earlier thread) that I take "the long route" when I am connected to my corporate SLL VPN (which forces DNS resolution priority to my corporate DNS servers), but when I disconnect, I take the short route (and use OpenDNS servers for DNS resolution)... Go figure. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJjNGRq1pz9mNUZTMRAhioAKDgg3dm8noVz3EfMjs5+H2xloYgfACfepCc a1LREz0mST06K4EMODI8yZQ= =DvNx -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From nanog at republique.org Fri Feb 6 18:43:02 2009 From: nanog at republique.org (Nicolas Hyvernat) Date: Sat, 7 Feb 2009 01:43:02 +0100 Subject: L3: Google from DC via the Netherlands? In-Reply-To: References: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> Message-ID: <20090207004301.GB20700@republique.org> On Fri, Feb 06, 2009 at 12:05:41PM -0500, Peter Beckman wrote: > I'm OK to that IP as well, but when I query www.google.com, I get multiple > IPs, but here are the ones that in in 147: > > DNS Server IP Route (for me) > 205.234.170.217 (tiggee) 74.125.79.147 Amsterdam > 208.67.222.222 (opendns) 64.233.183.147 Amsterdam > 4.2.2.1 (verizon) 74.125.19.147 San Jose > 198.6.1.3 (uu.net/verizon) 74.125.47.147 Washington DC (yay) > > That's a lot of different answers for the same question! And you can add this one to your list: DNS Server IP 212.27.40.240 (free/proxad) 2001:4860:A003:0:0:0:0:68 $ host -t AAAA www.google.com 212.27.40.240 www.google.com CNAME www.l.google.com www.l.google.com AAAA 2001:4860:A003:0:0:0:0:68 As you can see, no need for http://ipv6.google.com/ to reach Google over IPv6 using default DNS resolver provided by some French ISPs. www.google.com starts to be resolved as an IPv4/IPv6 website. -- Nicolas Hyvernat From stuart at tech.org Fri Feb 6 18:51:31 2009 From: stuart at tech.org (Stephen Stuart) Date: Sat, 07 Feb 2009 00:51:31 +0000 Subject: L3: Google from DC via the Netherlands? In-Reply-To: Your message of "Sat, 07 Feb 2009 01:43:02 +0100." <20090207004301.GB20700@republique.org> Message-ID: <200902070051.n170pVn5097487@nb.tech.org> > On Fri, Feb 06, 2009 at 12:05:41PM -0500, Peter Beckman wrote: > > I'm OK to that IP as well, but when I query www.google.com, I get multiple > > IPs, but here are the ones that in in 147: > > > > DNS Server IP Route (for me) > > 205.234.170.217 (tiggee) 74.125.79.147 Amsterdam > > 208.67.222.222 (opendns) 64.233.183.147 Amsterdam > > 4.2.2.1 (verizon) 74.125.19.147 San Jose > > 198.6.1.3 (uu.net/verizon) 74.125.47.147 Washington DC (yay) > > > > That's a lot of different answers for the same question! > > And you can add this one to your list: > > DNS Server IP > 212.27.40.240 (free/proxad) 2001:4860:A003:0:0:0:0:68 > > $ host -t AAAA www.google.com 212.27.40.240 > www.google.com CNAME www.l.google.com > www.l.google.com AAAA 2001:4860:A003:0:0:0:0:68 > > As you can see, no need for http://ipv6.google.com/ to reach Google > over IPv6 using default DNS resolver provided by some French ISPs. > www.google.com starts to be resolved as an IPv4/IPv6 website. Certain IPv6-capable networks are able to get AAAA responses from us, yes. Read: http://www.google.com/ipv6/ Stephen From nanog at daork.net Fri Feb 6 19:39:39 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 7 Feb 2009 14:39:39 +1300 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <6E5ACC3A-6618-4ED8-848E-E48C136850D5@kanren.net> References: <1317.64.39.177.10.1233737545.squirrel@webmail.ibctech.ca> <6E5ACC3A-6618-4ED8-848E-E48C136850D5@kanren.net> Message-ID: <6C8CB5A9-70C1-4F60-8629-DD1AE35C3E58@daork.net> On 7/02/2009, at 5:20 AM, Brad Fleming wrote: > On Feb 4, 2009, at 2:52 AM, Steve Bertrand wrote: >>>>> >> >> http://tools.ietf.org/html/draft-kumari-blackhole-urpf-02 >> > > If I understand this correctly, there will be a route entered on > each edge router for all sources that are participating in a DDoS > attack. Is anyone worried about TCAM usage if one of their customers > gets hit with a larger DDoS attack? Add in our IPv6 and V4 multicast > tables chewing up more TCAM space and things get even more dicy! > > For my part, I'd be worried if the overall IPv4 unicast route table > got much larger than ~1million entries because our hardware-based > routers might run out of TCAM and bring the whole network to a > screeching halt. Or more than 256k routes on a SUP2, or 192k/239K routes on a SUP720. We are at 285798 as of last CIDR report. So, I guess you should be worried.. now :-) -- Nathan Ward From stephen at sprunk.org Fri Feb 6 20:20:40 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 06 Feb 2009 20:20:40 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090205043908.1BAA82B21F4@mx5.roble.com> References: <20090205043908.1BAA82B21F4@mx5.roble.com> Message-ID: <498CEFF8.6060403@sprunk.org> Roger Marquis wrote: > Seth Mattinen wrote: >> Far too many people see NAT as synonymous with a firewall so they >> think if you take away their NAT you're taking away the security of a >> firewall. > > NAT provides some security, often enough to make a firewall > unnecessary. It all depends on what's inside the edge device. But > really, I've never heard anyone seriously equate a simple NAT device > with a firewall. You must be very sheltered. Most end users, even "security" folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on "security" through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From stephen at sprunk.org Fri Feb 6 20:36:53 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 06 Feb 2009 20:36:53 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <25D9C2DB-2F93-4280-9FCE-77897E65E1F6@hopcount.ca> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <25D9C2DB-2F93-4280-9FCE-77897E65E1F6@hopcount.ca> Message-ID: <498CF3C5.7030108@sprunk.org> Joe Abley wrote: > On 4-Feb-2009, at 16:16, Patrick W. Gilmore wrote: >> I guess I was thinking about v4 modems which do not get a subnet, >> just an IP address. If we really are handing out a /64 to each DSL & >> Cable modem, then we may very well be recreating the same problem. > > All the advice I have heard about address assignment to broadband > subscribers is to give each subscriber a /56, in addition to the link > address (which is effectively a /128). The last time I looked, the v6 > allocation of every RIR apart from ARIN recommended a /48 instead of a > /56. I'm not sure that that counts as "advice". Current ARIN policy takes no position as to which ISPs should do. IIRC, the /56 allowance came at the behest of a particular cable ISP that wanted to assign addresses to every home passed, whether or not the residents signed up for service, but did not want to pay for the /24 or so that would be required if they were handing out /48s -- if ARIN would even accept that flimsy justification. I can understand the technical benefits of pre-assignment, and I would have preferred that the policy (and fee schedule) were amended to better handle that case. > I have been specifically advised against assigning a /64 per > subscriber on the grounds that it is short-sighted, since v6 > residential gateways, when they come in large numbers, will expect to > be able to assign addresses to more than one subnet in the customer > network. ... which could be handled by giving out additional /64s via DHCP PD. I would expect the majority of customers to need no more than two or perhaps three subnets, with a huge fraction of that needing only one (not including the /127 to the CPE device). > I suspect that for many regional ISPs a single allocation sufficient > to number 16 million customers is probably good enough. In Canada, for > example, that's half the total population, and probably larger than > the total number of residences. > > No doubt there are a countable and significant number of super-ISPs in > larger markets (or spanning multiple markets) that have requirements > that out-strip that of a single /32, but I feel comfortable predicting > that they are the minority in the grand scheme of things (and in any > case, they can always request a larger allocation). More importantly, we can see that in Europe, RIPE has been perfectly willing to hand out enormous allocations to such mega-ISPs. A few in the US have also gotten larger-than-/32 allocations, and IMHO that is the "correct" route, not shrinking the size of customer assignments. There are more than enough prefixes to go around in the minuscule part of the IPv6 space we're currently using. The real concerns should be (a) how we keep the number of prefixes per AS as close to 1.00 as possible, and (b) how to deal with the explosion in the number of ASes due to multihomed leaf sites. However, those problems are much harder, so some engineers are looking at how to solve problems that we already know how to solve "successfully" but don't actually matter. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From mmc at internode.com.au Fri Feb 6 21:06:50 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 07 Feb 2009 13:36:50 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <498CEFF8.6060403@sprunk.org> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> Message-ID: <498CFACA.1030101@internode.com.au> Stephen Sprunk wrote: > > You must be very sheltered. Most end users, even "security" folks at > major corporations, think a NAT box is a firewall and disabling NAT is > inherently less secure. Part of that is factual: NAT (er, dynamic > PAT) devices are inherently fail-closed because of their design, while > a firewall might fail open. Also, NAT prevents some information > leakage by hiding the internal details of the site's network, and many > folks place a high value on "security" through obscurity. This is > understandable, since the real threats -- uneducated users and flawed > software -- are ones they have no power to fix. It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream. (In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/ is for enterprise). MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From mmc at internode.com.au Fri Feb 6 21:12:08 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 07 Feb 2009 13:42:08 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498C3D51.1030303@brightok.net> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <0F8E47C2-B4B7-459A-862D-A59FFD7E556F@internode.com.au> <498C3D51.1030303@brightok.net> Message-ID: <498CFC08.9090009@internode.com.au> Jack Bates wrote: > > Dynamic or static; how does this alter the state of the routing table? > A network assigned is a network assigned. In addition, IPv6 has some > decent support for mobile IP, which my limited understanding of says > they enjoy routing tables the rest of us never get to see. Dynamic assigned addresses mean that the BRAS the customer terminates on can hand out a range out of a pool assigned to it. This means I can have a single route in my routing table for a whole BRAS (maybe 20k customers) vs 20k routes and associated processing when the dsl goes up/down/etc. > > IPv6 is designed to be renumbered. Not all implementations support > this extremely well, but it is there. I believe the mobile > technologies support renumber on the fly better than traditional > aggregation networks who have no expectation of mobility. My car is designed to go 200km/hr or more. But the roads are implemented poorly. IPv6 is design to do everything for everyone, but the reality is the implementations aren't there or it's not practical. Mobile just creates more mess, I'm trying to make this simple and make it work. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From owen at delong.com Fri Feb 6 21:32:10 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Feb 2009 19:32:10 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <498CFACA.1030101@internode.com.au> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> Message-ID: On Feb 6, 2009, at 7:06 PM, Matthew Moyle-Croft wrote: > > > Stephen Sprunk wrote: >> >> You must be very sheltered. Most end users, even "security" folks >> at major corporations, think a NAT box is a firewall and disabling >> NAT is inherently less secure. Part of that is factual: NAT (er, >> dynamic PAT) devices are inherently fail-closed because of their >> design, while a firewall might fail open. Also, NAT prevents some >> information leakage by hiding the internal details of the site's >> network, and many folks place a high value on "security" through >> obscurity. This is understandable, since the real threats -- >> uneducated users and flawed software -- are ones they have no power >> to fix. > It's also worth pointing out that CPE for DSL often has really poor > stateful firewall code. So often turning it off means less issues > for home users. At least NAT gives some semblance of protection. > IPv6 without NAT might be awesome to some, but the reality is CPE is > built to a price and decent firewall code is thin on the ground. > I'm not hopeful of it getting better when IPv6 starts to become > mainstream. > IPTables is decent firewall code. It's free. I don't buy that argument for a second. Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code. Owen > (In case it's not clear - I'm not talking about enterprise stuff - > I'm talking about CPE for domestic DSL/Cable users - please don't > tell me all about how cool NetScreen/PIX/ASA/ > is for enterprise). > > MMC > > -- > Matthew Moyle-Croft - Internode/Agile - Networks > Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia > Email: mmc at internode.com.au Web: http://www.on.net > Direct: +61-8-8228-2909 Mobile: +61-419-900-366 > Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 > From mmc at internode.com.au Fri Feb 6 23:14:51 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 7 Feb 2009 15:44:51 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> Message-ID: <6CB10EA9-0A20-4E9D-B108-C1B7825E2CBA@internode.com.au> Tell ya what Owen, When you can show me residential grade CPE which has a DECENT stateful firewall then PLEASE let me know. Needs to do other things well, not crash, not cost hundreds of dollars, supportable, does VOIP, WIFI etc are manufacturer supported etc. Of course, it needs to do IPv6 as well. (it's easy to say Owen, but quite frankly, the reality from my side of the fence as an operator is that it's not the norm). MMC On 07/02/2009, at 2:02 PM, Owen DeLong wrote: >> > IPTables is decent firewall code. > > It's free. > > I don't buy that argument for a second. > > Further, since more and more CPE is being built on embedded linux, > there's no reason > that IPTables isn't a perfectly valid approach to the underlying > firewall code. > > Owen From nanog at daork.net Sat Feb 7 00:51:36 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 7 Feb 2009 19:51:36 +1300 Subject: v6 & DSL / Cable modems In-Reply-To: <20090206212954.GG5164@isc.org> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> <20090206181545.GE5164@isc.org> <498C9F6C.7050109@brightok.net> <20090206212954.GG5164@isc.org> Message-ID: <07EE8177-9A56-4C46-95D0-D718C85906E1@daork.net> On 7/02/2009, at 10:29 AM, David W. Hankins wrote: >> I want built in multiple IP bindings on my hosts. I'd like (Windows 7 > > I suppose you can individually configure every host to get itself > temporary addresses from RA announcements. This isn't usually a > good default configuration, but OS implementation already seems to > be inconsistent on the default configuration here. So we're back to > the IPv4 dark ages where you have to walk around to all the devices to > effect changes in policy (beyond prefix field contents). I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. The RA message tells the host either "here is a prefix, number yourself out of it" or "go to the DHCPv6 server to get an address". OS implementation here is identical - one does not configure a host to listen for RA messages or to request addresses from DHCPv6, the host *always* listens for RA messages. Changing from SLAAC to DHCPv6 based address assignment only requires touching the router sending the RA messages. -- Nathan Ward From nanog at daork.net Sat Feb 7 01:09:17 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 7 Feb 2009 20:09:17 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498B6FA0.6050607@ttec.com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> <498B6FA0.6050607@ttec.com> Message-ID: <590831AE-1D9C-416F-B359-8B7A99CBDF26@daork.net> On 6/02/2009, at 12:00 PM, Joe Maimon wrote: > This assignment policy is NOT enough for every particle of sand on > earth, which is what I thought we were getting. There is enough for 3616 /64s, or 14 /56s per square centimetre of the earth's surface, modulo whatever we have set aside for multicast and non globally scoped unicast addresses and so on. If we pretend that hosts are only going to be on the area that is land, that gives us 12385 /64s, or 48 /56s per square centimetre. My suspicion is that before we get to a place where we have 48 humans per sq cm of land, we will run out of food. -- Nathan Ward From nanog at daork.net Sat Feb 7 01:10:12 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 7 Feb 2009 20:10:12 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090206000115.GE8174@isc.org> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <49C38A17-90FE-4C9F-9333-82DD1D51BDCC@consultant.com> <498B7253.1020008@brightok.net> <20090206000115.GE8174@isc.org> Message-ID: <540F6E20-B28C-4B32-BD11-4C74F420347D@daork.net> On 6/02/2009, at 1:01 PM, David W. Hankins wrote: > On Thu, Feb 05, 2009 at 05:12:19PM -0600, Jack Bates wrote: >> Operationally, this has been met from my experience. In fact, all >> of these >> items are handled with stateless DHCPv6 in coordination with SLAAC. >> Stateful DHCPv6 seems to be limited with some vendors, but unless >> they plan >> to do proxy-nd, I'm not sure they'll gain much except for end system >> compatibility. > > SLAAC fails in the end because you cannot predict what address the > client will choose. > > So it fails in scenarios where enforcing network policy is important. It works fine, you set the additional information flag, and the host goes to the DHCPv6 server and you can now do whatever dynamic network policy you want. This might break with privacy extensions, I'm not sure. I'm a bit confused though - do you consider it to be a good idea to set network policy differently for multiple hosts on a single broadcast domain? There are some people that do that, but as Randy would say, it is something that I would encourage my competitors to do. -- Nathan Ward From swmike at swm.pp.se Sat Feb 7 01:45:00 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 7 Feb 2009 08:45:00 +0100 (CET) Subject: IPv6 delivery model to end customers Message-ID: I didn't know where to jump in in the current discussion and what I wanted to discuss was quite general, so I thought I'd create a new thread instead. So, anyone saying IPv6 is ready for prime-time whereever IPv4 is used, has a very simplified view of the world. Yes, IPv6 works in the classic routed network model where everything is statically set up (often manually), for example with an ISP run CPE and static/dynamic routing and a fixed /48 issued for that customer and SWIPed. Then it's easy to delegate reverse-DNS etc to the customer DNS. Now, take for instance the residential LAN case. There are several models on how to do this, but they all (that I know of) reside around the fact that each customer gets one or more globally routed IP address via DHCP, and security against spoofing and "man in the middle"-attacks is either done via forced-forwarding in the L2 device the customer connects to, or it's done via setting L3 accesslists learnt via DHCP snooping that inspect L2-packets in that same device. Often both is done, and also things like "ARP inspection", rogue dhcp server protection, MAC-rewrite etc is used. These are essential security mechanisms because customers should be protected from each other when it comes to these types of L2 attacks. Tracability (who had what IP at what time) is done via DHCP option82 and logging of this information. So, the L2 devices closest to the customer does a lot of "magic". All of these mechanisms were developed in the first half of the last decade. Now, with IPv6 this model changes drastically. The proposed mechanisms for IP number handout etc, is RA and DHCPv6. How does that fit into the model above? It doesn't, and the L2 devices surely won't "sniff" it and enforce security measures mentioned above. My ideal model would be to replace the above mentioned L2 device with a small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8 times port number should be enough), where this device uses link-local with the CPEs (would require all customers to actually have a router at home), hands out prefixes via DHCPv6-PD, inserts route towards customer link-local address, provisions anti-spoofing ACLs on that port, logs what prefix was given out to each port at what time, and off we go. (Rationale for link-local only is to have only customer devices in "Customer IP space" and only ISP infrastructure in that IP-space. This is equivalent to "ip unnumbered" in IPv4 in my view.) I have pitched this idea in the IETF v6ops list and it's now included in a draft that lists different models of IPv6 delivery. As far as I know, this IPv6 L3 device doesn't exist (in the pricerange needed for massive residential roll-out anyhow). So, in the meantime, to get IPv6 to the end customers I see two ways (because they need to fit into the IPv4 security model mentioned above). We have either 6to4 tunneling (Cisco 7600 does this very well and code for Linux CPEs exist already), or we try to fit IPv6 into the IPv4 security model. Current recommendation from the swedish "city networks association" (they consists mostly of entities running LANs to residential, I believe there are approx 400-500k ports of that in Sweden at this time) is that if you don't know if your network is secure against IPv6, block it at the ethertype level (I'll come back to the security risks later). So, how can we fit current IPv6 into the IPv4 security model? We can't. Current L2 devices won't do any of the IPv6 security stuff needed, and just turning on RA/DHCPv6 would make it work from a "let's move packets"-aspect, but it wouldn't be secure (perhaps in some forced-forwarding cases there might be a possibility of doing it securely, but what devices will log what customer had what IP at what time when it's done via RA?). So, what is the security problem with IPv6 in an IPv4 network? Well, imagine an IPv4 network where security is done via ARP inspection, DHCP snooping and L3 ACLs. Now, insert rogue customer who announces itself via RA/DHCPv6 and says it's also DNS. Vista machines will get itself an IPv6 address via RA, ask for DNS-server via DHCPv6, so if the rogue customer can do some NAT-PT like functionality, they are now man in the middle for all the IPv4 traffic (because between the customers it's IPv6 and the L2 device doesn't know anything about that). I don't know if this has actually been done, but I see no theoretical problem with it, if someone can come up with something, please do tell. So, my view on IPv6 is that I would love to roll it out to all residential customers, but unfortunately all the development done for IPv4 security has gone unnoticed by the people developing IPv6 and now it's behind and needs to catch up, or pitch a different model and then get vendors to develop products that do this. In the mean time, we do (and I encourage everybody else to do the same) support 6to4 and Teredo, plus we do IPv6 native in the core and peering where possible plus we give IPv6 to customers where we're able to securely (mostly transit customers and corporate customers with IPv6 capable CPEs). -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at daork.net Sat Feb 7 02:28:31 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 7 Feb 2009 21:28:31 +1300 Subject: IPv6 delivery model to end customers In-Reply-To: References: Message-ID: On 7/02/2009, at 8:45 PM, Mikael Abrahamsson wrote: > So, what is the security problem with IPv6 in an IPv4 network? Well, > imagine an IPv4 network where security is done via ARP inspection, > DHCP snooping and L3 ACLs. Now, insert rogue customer who announces > itself via RA/DHCPv6 and says it's also DNS. Vista machines will get > itself an IPv6 address via RA, ask for DNS-server via DHCPv6, so if > the rogue customer can do some NAT-PT like functionality, they are > now man in the middle for all the IPv4 traffic (because between the > customers it's IPv6 and the L2 device doesn't know anything about > that). I don't know if this has actually been done, but I see no > theoretical problem with it, if someone can come up with something, > please do tell. It is worth noting that this problem does not require you to start sending RA messages - this is a problem as soon as one customer is listening to RA messages. The problem may very well exist right now. -- Nathan Ward From elmi at 4ever.de Sat Feb 7 05:16:44 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Sat, 7 Feb 2009 12:16:44 +0100 Subject: One /22 Two ISP no BGP In-Reply-To: <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com> References: <498C6638.5080702@yahoo.com> <498C70DF.3040402@ibctech.ca> <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com> Message-ID: <20090207111644.GA91662@ronin.4ever.de> Re Charles, this is all about control, so you don't lose connectivity in case something outside your control fails. The best idea so far is the ebgp-multihop idea with your ISP's transit provider. This means speaking BGP to them yourself and taking care that the traffic takes the intended path, too (will usually work). If you can spare the money, I'd set up my own hubs on the "mainland", tunnel to them through each of my ISPs and use that hub for the routing of all incoming traffic. This does of course mean additional hardware, housing, local loops and probably additional transit providers. It would nonetheless give you full control. The second best idea so far is that the NANOG people could "talk" to your ISP(s)...this has worked in more than one case. So - where is your island, how's the weather, and are you hiring? ;-) Yours, Elmar. From patrick at ianai.net Sat Feb 7 09:36:14 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 7 Feb 2009 10:36:14 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <590831AE-1D9C-416F-B359-8B7A99CBDF26@daork.net> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <3ABE26AC-57AB-4A85-8C14-27084F1DFCBD@hopcount.ca> <498B6FA0.6050607@ttec.com> <590831AE-1D9C-416F-B359-8B7A99CBDF26@daork.net> Message-ID: On Feb 7, 2009, at 2:09 AM, Nathan Ward wrote: > On 6/02/2009, at 12:00 PM, Joe Maimon wrote: >> This assignment policy is NOT enough for every particle of sand on >> earth, which is what I thought we were getting. > > > There is enough for 3616 /64s, or 14 /56s per square centimetre of > the earth's surface, modulo whatever we have set aside for multicast > and non globally scoped unicast addresses and so on. > > If we pretend that hosts are only going to be on the area that is > land, that gives us 12385 /64s, or 48 /56s per square centimetre. > > My suspicion is that before we get to a place where we have 48 > humans per sq cm of land, we will run out of food. This has nothing to do with the number of blocks per area. Nice marketing, not useful for reality. How many IP-connected devices do you have on your person right now? How many non-IP-connected devices (e.g. bluetooth) that may someday be IP-connected? And how many more will we have? If you think you can answer the last one, you are lying to yourself. We will find a way to waste & fritter away thing. We always have, we always will. In the mean time, we'll do the best with what we have. -- TTFN, patrick From sthaug at nethelp.no Sat Feb 7 09:43:46 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 07 Feb 2009 16:43:46 +0100 (CET) Subject: v6 & DSL / Cable modems In-Reply-To: <07EE8177-9A56-4C46-95D0-D718C85906E1@daork.net> References: <498C9F6C.7050109@brightok.net> <20090206212954.GG5164@isc.org> <07EE8177-9A56-4C46-95D0-D718C85906E1@daork.net> Message-ID: <20090207.164346.41698438.sthaug@nethelp.no> > > I suppose you can individually configure every host to get itself > > temporary addresses from RA announcements. This isn't usually a > > good default configuration, but OS implementation already seems to > > be inconsistent on the default configuration here. So we're back to > > the IPv4 dark ages where you have to walk around to all the devices to > > effect changes in policy (beyond prefix field contents). > > > I'm not sure, but you seem to be implying that you need to configure > hosts to tell them to use RA or DHCPv6 to get addresses. My apologies > if this is not your intention. > > RA messages are always going to be sent by routers and received by > hosts, even if DHCPv6 is being used for address assignment. This does not seem to be generally true: - For the routers I am most familiar with (Juniper M/MX), you need to explicitly turn on router advertisement to make the router perform this. I.e. it is perfectly possible to have an interface with an IPv6 address which does *not* send RAs. - For the operating system I am most familiar with (FreeBSD), RAs are *not* accepted by default if the interface in question is configured with a static IPv6 address. Both of these choices seem perfectly reasonable to me. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From swmike at swm.pp.se Sat Feb 7 09:59:16 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 7 Feb 2009 16:59:16 +0100 (CET) Subject: v6 & DSL / Cable modems In-Reply-To: <20090207.164346.41698438.sthaug@nethelp.no> References: <498C9F6C.7050109@brightok.net> <20090206212954.GG5164@isc.org> <07EE8177-9A56-4C46-95D0-D718C85906E1@daork.net> <20090207.164346.41698438.sthaug@nethelp.no> Message-ID: On Sat, 7 Feb 2009, sthaug at nethelp.no wrote: > This does not seem to be generally true: > > - For the routers I am most familiar with (Juniper M/MX), you need to > explicitly turn on router advertisement to make the router perform this. > I.e. it is perfectly possible to have an interface with an IPv6 address > which does *not* send RAs. Cisco routers do send RA by default as soon as IPv6 is enabled on the interface. > - For the operating system I am most familiar with (FreeBSD), RAs are > *not* accepted by default if the interface in question is configured > with a static IPv6 address. Linux (at least Debian/Ubuntu kernels) will accept RAs by default even if you set a static IPv6 address. To stop it you have to do: sysctl net.ipv6.conf.eth0.accept_ra=0 -- Mikael Abrahamsson email: swmike at swm.pp.se From charles.regan at gmail.com Sat Feb 7 10:31:26 2009 From: charles.regan at gmail.com (Charles Regan) Date: Sat, 7 Feb 2009 12:31:26 -0400 Subject: One /22 Two ISP no BGP In-Reply-To: <20090207111644.GA91662@ronin.4ever.de> References: <498C70DF.3040402@ibctech.ca> <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com> <20090207111644.GA91662@ronin.4ever.de> Message-ID: For the folks asking what island. http://en.wikipedia.org/wiki/Magdalen_Islands http://www.panoramio.com/user/45210 We are hiring if someone is interested :) It's not like the Bahamas. I wish it was. It's alot colder here. I've talked to ISP1 yesterday and they will let me know what they can do. There's a chance... I will also have to scale up. I don't think my Soekris with OpenBSD can handle two full route of the Internet. Any suggestions ? Charles On Sat, Feb 7, 2009 at 7:16 AM, Elmar K. Bins wrote: > Re Charles, > > this is all about control, so you don't lose connectivity in case something > outside your control fails. > > The best idea so far is the ebgp-multihop idea with your ISP's transit > provider. This means speaking BGP to them yourself and taking care that > the traffic takes the intended path, too (will usually work). > > If you can spare the money, I'd set up my own hubs on the "mainland", > tunnel to them through each of my ISPs and use that hub for the > routing of all incoming traffic. This does of course mean additional > hardware, housing, local loops and probably additional transit > providers. It would nonetheless give you full control. > > The second best idea so far is that the NANOG people could "talk" to > your ISP(s)...this has worked in more than one case. > > So - where is your island, how's the weather, and are you hiring? ;-) > > Yours, > Elmar. > From trejrco at gmail.com Sat Feb 7 10:37:22 2009 From: trejrco at gmail.com (TJ) Date: Sat, 7 Feb 2009 11:37:22 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)] In-Reply-To: <70EC72941042AA48ABE651C40408D9C9C11E3C@hal.photon.com> References: <49555.1233631443@turing-police.cc.vt.edu><76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net><498A2DED.5040601@rollernet.us><9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <70EC72941042AA48ABE651C40408D9C9C11E3C@hal.photon.com> Message-ID: <00a101c98942$5ac003f0$10400bd0$@com> >Five things? Really? My DHCP server hands out the following things to its >clients: > >Default Route >DNS Servers >Log host >Domain Name (or, our case, the sub-domain for the office) NIS Domain NIS >Servers NTP Server WINS Servers SMTP Server POP Server NNTP Server Domain >suffix search orders. > >All these useful and handy things that my Windows, Unix (Irix and Solaris), >Linux, and FreeBSD clients all need some portion of, in one place where I >configure and control it. Super, great and wonderful. Keep doing so. But I think Iljitsch's point is that I shouldn't have to run DHCPv6 when I can get everything I need from SLAAC. In other words, what is wrong with having two complimentary pieces: Router: Sends out RAs, gets hosts a default gateway ... and maybe a prefix ... and maybe a DNS server DHCPv6: Hands out other information (DNS server) and maybe addresses upon request from host >Having to deal with configuration and control of this in multiple places is >only going to make the sysadmins of the world hate you. Sorry, are your routers not getting any sort of configuration now? If it is a Cisco box once you give that Ethernet interface an address it will send out RAs by default, no extra work. In fact, less work - you don't need to configure your DHCPv6 server with the default gateway addresses of every subnet. From trejrco at gmail.com Sat Feb 7 10:43:48 2009 From: trejrco at gmail.com (TJ) Date: Sat, 7 Feb 2009 11:43:48 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)] In-Reply-To: <75cb24520902060754o726e578bt3557bfc87ad90f62@mail.gmail.com> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <70EC72941042AA48ABE651C40408D9C9C11E3C@hal.photon.com> <75cb24520902060754o726e578bt3557bfc87ad90f62@mail.gmail.com> Message-ID: <00a201c98943$406a1d00$c13e5700$@com> >as I've said a few times now, reason #775 that autoconf is a broken and non- >useful 'gadget' for network operators. There is a system today that does >lots of client-conf (including the simple default-route + >dns-server) called DHCP, there MUST be a similarly featured system in the >'new world order' of ipv6. > >This really is non-negotiable, why are people still holding out hope that >autoconf is 'enough' when users and operators have so clearly said >otherwise? There IS a similarly featured system. Why is it so hard to accept that in MANY cases SLAAC is enough (especially when RFC5006 is more widely supported, or while IPv4 is still around to cheat off of (glaring at WinXP)) ... and when it isn't enough, or when you feel like doing more DHCPv6 is there waiting for you? Almost no one is arguing that DHCPv6 can't exist, shouldn't exist, etc. Perhaps with the exception of Apple, that is - and that is still OK! I certainly see value in DHCPv6, but I see value in SLAAC as well. I don't want to force anyone to not do DHCPv6, why do others want to force me to do DHCPv6? Can't we all just get along? From trejrco at gmail.com Sat Feb 7 10:54:52 2009 From: trejrco at gmail.com (TJ) Date: Sat, 7 Feb 2009 11:54:52 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: <20090206181545.GE5164@isc.org> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> <20090206181545.GE5164@isc.org> Message-ID: <00af01c98944$cc628580$65279080$@com> >What most people do of course is VRRP. Sure, or HSRP or GLBP ... all still doable. > >Barring that, you just specify multiple default routers, and the client will >select the router that still responds to ARP. But support for this is not >universal, so. Indeed, not universal and in fact default behaviors vary wildly. > >When that isn't available, what I have done in the past here is to use the >DHCP server to give out a default router option that is sorted according to >the DHCP relay agent that was used to reach the server (keyed on giaddr >contents). > >The net result is that the client uses the default gateway which it used to >reach the DHCP server, and so will automatically receive an updated value if >that router fails, as part of DHCP lease rebinding (it will reach the server >via the alternate router). Which I think is pretty slick. OOC - between the "router fails" and "I renew/rebind my address", is the host down and out? So you are accepting either a noticeable outage or tweaking your lease times, yes? From trejrco at gmail.com Sat Feb 7 11:03:39 2009 From: trejrco at gmail.com (TJ) Date: Sat, 7 Feb 2009 12:03:39 -0500 Subject: L3: Google from DC via the Netherlands? In-Reply-To: References: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> Message-ID: <00b601c98946$0612a110$1237e330$@com> IMHO, off the top of my head, on a weekend where I haven't had enough coffee yet: 3. Anycasted DNS Providers? Not sure how they could fix it, other than flag certain domains as special, and do something special for them, but man that smells like a hack. Anycast is a good thing, but when geo-location style concerns are factored in maybe they should have region-based anycast addresses. Interestingly, with Google there could be another similar concern WRT the IPv6 "trusted tester program" (or whatever the correct name of that is) where the DNS resolver / organization could have sufficient IPv6 connectivity to qualify, but that capability might not expand to the clients of / hosts within the service. /TJ >-----Original Message----- >From: Peter Beckman [mailto:beckman at angryox.com] >Sent: Friday, February 06, 2009 2:51 PM >To: nanog at nanog.org >Subject: RE: L3: Google from DC via the Netherlands? > >On Fri, 6 Feb 2009, Peter Beckman wrote: > >> I'm OK to that IP as well, but when I query www.google.com, I get >> multiple IPs, but here are the ones that in in 147: >> >> DNS Server IP Route (for me) >> 205.234.170.217 (tiggee) 74.125.79.147 Amsterdam >> 208.67.222.222 (opendns) 64.233.183.147 Amsterdam >> 4.2.2.1 (verizon) 74.125.19.147 San Jose >> 198.6.1.3 (uu.net/verizon) 74.125.47.147 Washington DC (yay) > > So someone from Google has been helpful in pointing out that the resolver > IP, not YOUR IP, is the one that determines where you get routed to when > you make a request for www.google.com. Which is simply due to the way > things are implemented, which makes sense. > > The problem is, here I am, just some guy, and 99%* of the Internet >resolves > to the same IP(s) regardless of who I ask. But then the other 1%*, and > this would likely be larger players who are diversified and have systems > in multiple locations and networks, do something funky and give a > different address depending on where your DNS server is in the network. > > Then throw in the possibility that YOUR DNS servers are anycasted for > great justice, or at least for good reliability. Now when you base YOUR > answer on the caching server's IP address, well, it may not make sense. > It seems that Tiggee and OpenDNS are anycasted, as is DNS Advantage, as > well as some root nameservers. > > Thus my problem -- because I ask two free resolving name services, which > I believe to be anycasted, where to go, I get routed to Amsterdam instead > of a few miles down the road in Ashburn, VA, and spend 100ms instead of > 10ms travelling the globe, costing someone more money for Atlantic Ocean > transit when it was unnecessary. > > SO. Who's problem is this to fix? Is it: > > 1. Me? Am I a dope for using a very reliable but anycasted resolving > name service? Clearly, I could just use the handy dandy easy to > remember because I worked there 198.6.1.x, or is that an Internet > faux pas because technically I wasn't given permission to use it? > > 2. Google? They probably have an interest in making sure my experience > to their services are fast and as close to me as possible, but I'm > probably a minority and not worth the effort of refactoring a giant > DNS implementation just to fix my one problem, nay, inconvenience. > > 3. Anycasted DNS Providers? Not sure how they could fix it, other than > flag certain domains as special, and do something special for them, > but man that smells like a hack. > > 4. My ISP? Does the ISP have to gripe at Google for providing bad > results that causes traffic to go over expensive lines when it could > have easily gone locally and much more cheaply? I'm assuming that > sending my traffic over the Atlantic to the Netherlands costs > SOMEONE more money than if I had gone to a datacenter nearby, both > physically and network-wise. > > 5. Nobody? Is it just the price the customer (me, who helps generate > income for Google by using Google and clicking AdWords ads all day) > pays for the reliability, redundancy and fault tolerance that Google > has implemented? > > I think things are working as implemented -- it's not "broken," but it > seems it could be better. Then again, sometimes better is more expensive > than the status quo, either in time or money or both. > > NOTE: I do not admit to knowing that 100% of what I've written is fact, > and if you know better than I, please correct me and show me the light. > > * Numbers have no basis, just a guess. > >Beckman >--------------------------------------------------------------------------- >Peter Beckman Internet Guy >beckman at angryox.com http://www.angryox.com/ >--------------------------------------------------------------------------- From jbates at brightok.net Sat Feb 7 11:16:17 2009 From: jbates at brightok.net (Jack Bates) Date: Sat, 07 Feb 2009 11:16:17 -0600 Subject: IPv6 delivery model to end customers In-Reply-To: References: Message-ID: <498DC1E1.8000706@brightok.net> If you didn't see it in last thread, http://geekmerc.livejournal.com/699.html may provide some information for you, but I can tell from your concerns that your current choice of edge layouts is different than mine. As such, more below. Mikael Abrahamsson wrote: > Now, take for instance the residential LAN case. There are several > models on how to do this, but they all (that I know of) reside around > the fact that each customer gets one or more globally routed IP address > via DHCP, and security against spoofing and "man in the middle"-attacks > is either done via forced-forwarding in the L2 device the customer > connects to, or it's done via setting L3 accesslists learnt via DHCP > snooping that inspect L2-packets in that same device. Often both is > done, and also things like "ARP inspection", rogue dhcp server > protection, MAC-rewrite etc is used. These are essential security > mechanisms because customers should be protected from each other when it > comes to these types of L2 attacks. Tracability (who had what IP at what > time) is done via DHCP option82 and logging of this information. So, the > L2 devices closest to the customer does a lot of "magic". All of these > mechanisms were developed in the first half of the last decade. > Unnumbered vlans and RBE support on cisco, I guess could be considered forced forwarding in layer 2. It definitely makes for beautifully long configurations and severely limits dslams to support enough vlans for 1 vlan per port, preferably with q-in-q. It also had the benefit of separation of responsibility, as telco could play with dslams (atm or vlans) and networking played with routers where tracking/policing was implemented. Of course, moving away from ATM terminated systems seems to be the big deal, and not all systems support massive vlan terminations. I believe the vendors said, "Why on earth would you want to do that! It's like replicating pvc's!" Those vendors do cute things in their dslams such as dhcp snooping and limiting broadcast domains. IPv6 changes this from broadcast domains to multicast. Luckily, thanks to triple play, most of these same dslams also understand multicast and do igmp snooping. Adding support for multicast RA snooping is considered trivial by most, which is why they haven't bothered with it yet. > Now, with IPv6 this model changes drastically. The proposed mechanisms > for IP number handout etc, is RA and DHCPv6. How does that fit into the > model above? It doesn't, and the L2 devices surely won't "sniff" it and > enforce security measures mentioned above. > Why not? They "sniff" igmp. What's the difference? Multicast is already commonly supported by most dslam manufacturers using flat topology. > My ideal model would be to replace the above mentioned L2 device with a > small and simple L3 device (L3 switch) with very small TCAM (TCAM size > 6-8 times port number should be enough), where this device uses > link-local with the CPEs (would require all customers to actually have a > router at home), hands out prefixes via DHCPv6-PD, inserts route towards > customer link-local address, provisions anti-spoofing ACLs on that port, > logs what prefix was given out to each port at what time, and off we go. I suggest heavy testing of this. I'm not sure that CPE's will be happy about doing PD requests without having received a prefix/IP for the interface. It'll also create create problems for traceroutes. ;) The other option that is extremely simple is statically assign /64 to each port and then if they do PD, insert the route and do anti-spoofing. This is, btw, what RBE sorta does with IPv6 in atm world. > So, how can we fit current IPv6 into the IPv4 security model? We can't. > Current L2 devices won't do any of the IPv6 security stuff needed, and > just turning on RA/DHCPv6 would make it work from a "let's move > packets"-aspect, but it wouldn't be secure (perhaps in some > forced-forwarding cases there might be a possibility of doing it > securely, but what devices will log what customer had what IP at what > time when it's done via RA?). > I'll agree that I haven't seen the necessary support by vendors for what should be trivial to change as mentioned above. One reason I took the headache of treating vlans like pvcs is lack of uniform support at layer 2 for security policies. Vlans, though. Simple. They either support the required number, or they don't. > and the L2 device doesn't know anything about that). I don't know if > this has actually been done, but I see no theoretical problem with it, > if someone can come up with something, please do tell. > Depends on the L2 device and how it's configured to deal with multicast. If you didn't think about multicast when deploying, then IPv6 is doing a service by reminding people that it exists. ;) > So, my view on IPv6 is that I would love to roll it out to all > residential customers, but unfortunately all the development done for > IPv4 security has gone unnoticed by the people developing IPv6 and now > it's behind and needs to catch up, or pitch a different model and then > get vendors to develop products that do this. Vendors are the ones who are behind. Talk to yours. Multicast is simpler to manage in L2 than broadcast. As to the support by vendors, that's another question. I can't say I've been impressed with the overall vendor support. On the other hand, I'm the first to order equipment I didn't like to begin with into the trash due to no IPv6 support. ;) > In the mean time, we do (and I encourage everybody else to do the same) > support 6to4 and Teredo, plus we do IPv6 native in the core and peering > where possible plus we give IPv6 to customers where we're able to > securely (mostly transit customers and corporate customers with IPv6 > capable CPEs). > Hate Teredo, and 6to4 rarely works due to the billions of home routers. The best one can hope for is securing down to the edge and customers eventually will have to buy a new home router to get their IPv6. (Most cheapy routers on the market now have 2MB flash. The current images for download are ususally about 1.8MB in size. I don't see 2MB flash routers supporting the additional overhead of IPv6 support.) Jack From john at internetassociatesllc.com Sat Feb 7 11:30:41 2009 From: john at internetassociatesllc.com (John Lee) Date: Sat, 7 Feb 2009 11:30:41 -0600 Subject: IPv6 delivery model to end customers In-Reply-To: References: Message-ID: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> Michael, >From my work in access networks they are: IPv6 native support for: Routed Access - Ethernet or Wireless, global prefix under the main or dot1Q isl encapsulated sub-interfaces. For DSL and ATM PVCs routed RFC 2684 encapsulation with a different IPv6 prefix for each one of the PVCs. Bridged Access - RFC 2684 where the user traffic reaches the access router over a bridged PVC. PPP-Encapsulated IPv6 - PPPoA/IPv4 access was my favorite in the early days and finally moving in about 2004 or so to PPPoE (RFC 2516). Most DSL and Layer 2 providers that I used had PPPoA in their access network and then handed off to me as an ATM PVC with L2TP encapsulated user streams. PPPoE/PPPoA support both IPv4 and IPv6 packets natively. SP can leverage their existing IPv4 access infrastructure by utilizing IPv6 over L2TPv2 or in deploying IPv6 natively to the CPE by utilizing L2TPv3. My IPv4 only deployment in 2001 used DSLAMs that had limited number of active CPEs and DS3/T3 upstreams to the network. We used front end Fore/Marconi ATM switches in front of Redback aggregation switches connecting to Cisco 6509s and then GSR 12012s as the backbone routers. The Redback authenticated with RADIUS servers using CHAP. The DSLAMs were upgrade over the next two to three years for larger number of CPE tributaries and optical (OC-3c and OC-12c) network uplinks. In my advancing years if memory serves in 2005/2006 timeframe (in the US) the CPE, DSLAMS, aggregation and other switches and routers supported IPv6. Now you have both second and third generation support for IPv6 in these devices (Cisco, Juniper, et al) and rumor has it that Linksys and Netgear have IPv6 plans in their roadmaps or devices in their labs. For PD and DHCPv6 there are other tools that allow much more control over IP address assignment and lifecycle control that I will not discuss here. I am not slighting Cable here, I do not have the first hand experience with cable supporting IPv6. IMHO rolling out IPv6 to the customer is a business decision now not a technical one. John (ISDN) Lee ________________________________________ From: Mikael Abrahamsson [swmike at swm.pp.se] Sent: Saturday, February 07, 2009 2:45 AM To: nanog at nanog.org Subject: IPv6 delivery model to end customers I didn't know where to jump in in the current discussion and what I wanted to discuss was quite general, so I thought I'd create a new thread instead. So, anyone saying IPv6 is ready for prime-time whereever IPv4 is used, has a very simplified view of the world. Yes, IPv6 works in the classic routed network model where everything is statically set up (often manually), for example with an ISP run CPE and static/dynamic routing and a fixed /48 issued for that customer and SWIPed. Then it's easy to delegate reverse-DNS etc to the customer DNS. Now, take for instance the residential LAN case. There are several models on how to do this, but they all (that I know of) reside around the fact that each customer gets one or more globally routed IP address via DHCP, and security against spoofing and "man in the middle"-attacks is either done via forced-forwarding in the L2 device the customer connects to, or it's done via setting L3 accesslists learnt via DHCP snooping that inspect L2-packets in that same device. Often both is done, and also things like "ARP inspection", rogue dhcp server protection, MAC-rewrite etc is used. These are essential security mechanisms because customers should be protected from each other when it comes to these types of L2 attacks. Tracability (who had what IP at what time) is done via DHCP option82 and logging of this information. So, the L2 devices closest to the customer does a lot of "magic". All of these mechanisms were developed in the first half of the last decade. Now, with IPv6 this model changes drastically. The proposed mechanisms for IP number handout etc, is RA and DHCPv6. How does that fit into the model above? It doesn't, and the L2 devices surely won't "sniff" it and enforce security measures mentioned above. My ideal model would be to replace the above mentioned L2 device with a small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8 times port number should be enough), where this device uses link-local with the CPEs (would require all customers to actually have a router at home), hands out prefixes via DHCPv6-PD, inserts route towards customer link-local address, provisions anti-spoofing ACLs on that port, logs what prefix was given out to each port at what time, and off we go. (Rationale for link-local only is to have only customer devices in "Customer IP space" and only ISP infrastructure in that IP-space. This is equivalent to "ip unnumbered" in IPv4 in my view.) I have pitched this idea in the IETF v6ops list and it's now included in a draft that lists different models of IPv6 delivery. As far as I know, this IPv6 L3 device doesn't exist (in the pricerange needed for massive residential roll-out anyhow). So, in the meantime, to get IPv6 to the end customers I see two ways (because they need to fit into the IPv4 security model mentioned above). We have either 6to4 tunneling (Cisco 7600 does this very well and code for Linux CPEs exist already), or we try to fit IPv6 into the IPv4 security model. Current recommendation from the swedish "city networks association" (they consists mostly of entities running LANs to residential, I believe there are approx 400-500k ports of that in Sweden at this time) is that if you don't know if your network is secure against IPv6, block it at the ethertype level (I'll come back to the security risks later). So, how can we fit current IPv6 into the IPv4 security model? We can't. Current L2 devices won't do any of the IPv6 security stuff needed, and just turning on RA/DHCPv6 would make it work from a "let's move packets"-aspect, but it wouldn't be secure (perhaps in some forced-forwarding cases there might be a possibility of doing it securely, but what devices will log what customer had what IP at what time when it's done via RA?). So, what is the security problem with IPv6 in an IPv4 network? Well, imagine an IPv4 network where security is done via ARP inspection, DHCP snooping and L3 ACLs. Now, insert rogue customer who announces itself via RA/DHCPv6 and says it's also DNS. Vista machines will get itself an IPv6 address via RA, ask for DNS-server via DHCPv6, so if the rogue customer can do some NAT-PT like functionality, they are now man in the middle for all the IPv4 traffic (because between the customers it's IPv6 and the L2 device doesn't know anything about that). I don't know if this has actually been done, but I see no theoretical problem with it, if someone can come up with something, please do tell. So, my view on IPv6 is that I would love to roll it out to all residential customers, but unfortunately all the development done for IPv4 security has gone unnoticed by the people developing IPv6 and now it's behind and needs to catch up, or pitch a different model and then get vendors to develop products that do this. In the mean time, we do (and I encourage everybody else to do the same) support 6to4 and Teredo, plus we do IPv6 native in the core and peering where possible plus we give IPv6 to customers where we're able to securely (mostly transit customers and corporate customers with IPv6 capable CPEs). -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Sat Feb 7 12:12:49 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 7 Feb 2009 19:12:49 +0100 (CET) Subject: IPv6 delivery model to end customers In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> Message-ID: On Sat, 7 Feb 2009, John Lee wrote: > My IPv4 only deployment in 2001 used DSLAMs that had limited number of > active CPEs and DS3/T3 upstreams to the network. We used front end > Fore/Marconi ATM switches in front of Redback aggregation switches > connecting to Cisco 6509s and then GSR 12012s as the backbone routers. > The Redback authenticated with RADIUS servers using CHAP. My ADSL2+ design I did in 2002-03 or so, used one vlan per customer in the DSLAM (first version was 1U 24 port ADSL L2 ethernet DSLAM, second generation was chassis based ADSL2+ DSLAM did 1024 vlans and had ~800 ADSL2+ ports), vlans aggregated with an L3 switch doing GigE with the DSLAM, and one IP address per vlan (L3 switch was RFC3069 capable), no DHCP just statically provisioned when doing customer delivery. Worked great. Quite cheap as well. DSLAM was basically a L2 PVC->VLAN and PHY media converter. But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option. So, we have ~500k ports in my 9 million inhabitants country which are done via L2 switches in basements with CAT5/6 or fiber to the home. They use the security model I talked about before which I didn't really see a mention of in the list of IPv6 supported access models you listed. There are probably many millions more in Asia with the same model. > IMHO rolling out IPv6 to the customer is a business decision now not a > technical one. Well, I want to be able to do IPv6 at close to the same cost and security as I do IPv4 today. In your BRAS/LNS world it might be easy, but that's not the world I live in. -- Mikael Abrahamsson email: swmike at swm.pp.se From David_Hankins at isc.org Sat Feb 7 12:51:35 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Sat, 7 Feb 2009 10:51:35 -0800 Subject: v6 & DSL / Cable modems In-Reply-To: <07EE8177-9A56-4C46-95D0-D718C85906E1@daork.net> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> <20090206181545.GE5164@isc.org> <498C9F6C.7050109@brightok.net> <20090206212954.GG5164@isc.org> <07EE8177-9A56-4C46-95D0-D718C85906E1@daork.net> Message-ID: <20090207185134.GK5164@isc.org> On Sat, Feb 07, 2009 at 07:51:36PM +1300, Nathan Ward wrote: > I'm not sure, but you seem to be implying that you need to configure hosts > to tell them to use RA or DHCPv6 to get addresses. My apologies if this is > not your intention. Close, but it is worth clearing up. > RA messages are always going to be sent by routers and received by hosts, > even if DHCPv6 is being used for address assignment. Most clients "default out of the box" to accept RA, getting a single address within each prefix indicating automatic address assignment. The ones that do support DHCPv6 will also initiate DHCPv6 services based on RA M and O flags. There are some bugs here and there, but it mostly works. This is all well and good, you are right on these points. However, Jack was referring to a practice of "temporary address" assignments. In this configuration, a client has one "permanent" (for as long as they are on that wire) address they use (per prefix, because that is how IPv6 multihomes, so they say) for general purpose and reachability from the outside world ("dial in"). They also have a range of "temporary" addresses which are in a state of preferred use, unpreferred use, or validity-timer expiration (again, per prefix, for multi-homing). Each temporary address is allocated based on a re-hash of a previously used seed, and half of the seed bits are not used in the public address (so outsiders can not easily predict what the client's next address will be). The theory is that these temporary addresses enhance privacy, as the client seems to hop from address to address. This seems to ignore application context hints such as cookies and keys embedded in URL's, so to my thinking the point of this is to enhance privacy for spammers or illegal file sharers. Anyway. So far as I am aware, this is default behaviour only on certain versions of Mac OSX, and must be explicitly enabled on all others. Manually, on the console. RA does not dynamically distribute this behaviour; the client has to choose it. Usually it is a sysctl or a registry variable or the like. Conversely, with DHCPv6, clients that support "normal" and "temporary" addresses simply always ask for them; this indicates they possess support. The service determines which type of address to actually provide (one, the other, both, with multiple bindings in either). In this way, all is automated from a central point. The philosophies of design of these two systems are entirely at odds. In RA the client determines what configuration it seeks, placing its own arbitrary demands upon the network, but still heeds some of its vague handwaving. In DHCPv6, the client submits to the network's will, but still has some of its own vague handwaving choices. It is Marxism (turned Socialism) vs Fascism at its root. I hope I have not spent my year's worth of NANOG tolerance for DHCP related discussions with the above. :) -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From john at internetassociatesllc.com Sat Feb 7 13:24:58 2009 From: john at internetassociatesllc.com (John Lee) Date: Sat, 7 Feb 2009 13:24:58 -0600 Subject: IPv6 delivery model to end customers In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local>, Message-ID: <53A6C7E936ED8544B1A2BC990D254F943524A77C91@MEMEXG1.HOST.local> Yes it was definitely last century. With your 30 USD per port and no tunnels poses some interesting challenges. Customer CPE tunnel access was the main method discussed in the different v6 meetings I attended. I appreciate you bringing up this set of requirements since it needs to be addressed for fuller deployment of IPv6 to residential customers. John ________________________________________ From: Mikael Abrahamsson [swmike at swm.pp.se] Sent: Saturday, February 07, 2009 1:12 PM To: John Lee Cc: nanog at nanog.org Subject: RE: IPv6 delivery model to end customers On Sat, 7 Feb 2009, John Lee wrote: > My IPv4 only deployment in 2001 used DSLAMs that had limited number of > active CPEs and DS3/T3 upstreams to the network. We used front end > Fore/Marconi ATM switches in front of Redback aggregation switches > connecting to Cisco 6509s and then GSR 12012s as the backbone routers. > The Redback authenticated with RADIUS servers using CHAP. My ADSL2+ design I did in 2002-03 or so, used one vlan per customer in the DSLAM (first version was 1U 24 port ADSL L2 ethernet DSLAM, second generation was chassis based ADSL2+ DSLAM did 1024 vlans and had ~800 ADSL2+ ports), vlans aggregated with an L3 switch doing GigE with the DSLAM, and one IP address per vlan (L3 switch was RFC3069 capable), no DHCP just statically provisioned when doing customer delivery. Worked great. Quite cheap as well. DSLAM was basically a L2 PVC->VLAN and PHY media converter. But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option. So, we have ~500k ports in my 9 million inhabitants country which are done via L2 switches in basements with CAT5/6 or fiber to the home. They use the security model I talked about before which I didn't really see a mention of in the list of IPv6 supported access models you listed. There are probably many millions more in Asia with the same model. > IMHO rolling out IPv6 to the customer is a business decision now not a > technical one. Well, I want to be able to do IPv6 at close to the same cost and security as I do IPv4 today. In your BRAS/LNS world it might be easy, but that's not the world I live in. -- Mikael Abrahamsson email: swmike at swm.pp.se From stephen at sprunk.org Sat Feb 7 13:31:57 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 07 Feb 2009 13:31:57 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <498CFACA.1030101@internode.com.au> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> Message-ID: <498DE1AD.1000807@sprunk.org> Matthew Moyle-Croft wrote: > Stephen Sprunk wrote: >> You must be very sheltered. Most end users, even "security" folks at >> major corporations, think a NAT box is a firewall and disabling NAT >> is inherently less secure. Part of that is factual: NAT (er, dynamic >> PAT) devices are inherently fail-closed because of their design, >> while a firewall might fail open. Also, NAT prevents some >> information leakage by hiding the internal details of the site's >> network, and many folks place a high value on "security" through >> obscurity. This is understandable, since the real threats -- >> uneducated users and flawed software -- are ones they have no power >> to fix. > It's also worth pointing out that CPE for DSL often has really poor > stateful firewall code. So often turning it off means less issues for > home users. I assume you're referring to ALG code? Indeed, I've found that turning off ALGs in NAT/FW boxes fixes a lot of problems, because every vendor's seem to be broken in a different way. I deal mainly with SIP these days, and the first step in any sort of firewall-related troubleshooting is to turn _off_ any SIP ALG functionality in the CPE because 90% of the time, that's whats breaking things; the end devices can deal with NAT as long as there's nobody in the middle mangling their packets. Ideally, ALGs would fix up the packets such that the endpoints didn't need to be NAT-aware, but they're all (and I mean all, not most) so hideously broken that they make things worse, not better. They can't get even simple, fossilized protocols like active FTP working most of the time; there's no way they'll do better with newer, more complicated ones like SIP or the dizzying array of P2P and IM protocols. > At least NAT gives some semblance of protection. IPv6 without NAT > might be awesome to some, but the reality is CPE is built to a price > and decent firewall code is thin on the ground. I'm not hopeful of it > getting better when IPv6 starts to become mainstream. Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate. However, to be safe the endpoints cannot assume any firewalls in the path are going to work properly, and the absence of NAT makes it tougher for endpoints to detect firewalls' presence and react as needed... > (In case it's not clear - I'm not talking about enterprise stuff - I'm > talking about CPE for domestic DSL/Cable users - please don't tell me > all about how cool NetScreen/PIX/ASA/ is for > enterprise). I've found the "enterprise" NAT/FW gear to be worse: they attempt to implement more ALGs, but they do no better a job at implementing them than the less-ambitious consumer vendors, so more things break. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From trejrco at gmail.com Sat Feb 7 13:58:08 2009 From: trejrco at gmail.com (TJ) Date: Sat, 7 Feb 2009 14:58:08 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: References: <9e246b4d0902060628q6301f2b7r5a61eb87434995b7@mail.gmail.com> Message-ID: <00ea01c9895e$66939950$33bacbf0$@com> >But I don't see how you could route some >/48s without having software to route all /48s and that is hugemongous. As currently spec'ed, you [would|should|could] allow /48s from the specific PI ranges (1/RIR?) - not just auto-accept all /48s. /TJ From trejrco at gmail.com Sat Feb 7 14:19:22 2009 From: trejrco at gmail.com (TJ) Date: Sat, 7 Feb 2009 15:19:22 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> <20090206181545.GE5164@isc.org> <498C9F6C.7050109@brightok.net> Message-ID: <00f401c98961$5de71c70$19b55550$@com> >It would be nice if DHCPv6 (or DHCPv4 for that matter) could include not only a default, but, a static routing table in what it distributes. In theory, RAs can - "more specific routes", although I don't believe any vendor (router or client side) supports these as of yet ... (Default Router Preference more widely supported, but less granular) > Could you please explain a good reliable method for source address selection in a multiple IP binding scenario? RFC3484 being revisited as we speak, feel free to help :) ... may include things like policy table updates to clients ... Note - no great/clean answer yet to the "multi-homed to disparate networks" scenario. (It's a hard problem to automagically solve for all cases) /TJ From scg at gibbard.org Sat Feb 7 15:23:19 2009 From: scg at gibbard.org (Steve Gibbard) Date: Sat, 7 Feb 2009 13:23:19 -0800 (PST) Subject: One /22 Two ISP no BGP In-Reply-To: References: <2E2FECEBAE57CC4BAACDE67638305F10482E5B4F66@ROCH-EXCH1.corp.pvt> Message-ID: On Fri, 6 Feb 2009, Jason Biel wrote: > As I mentioned earlier, you'll want to have one provider announce the /22 > unweighted and the other announce it weighted. Just pick the better of the > two providers as the primary. Don't base it soley off bandwidth, but check > your SLA and any recent outage occurances. > > Traffic will flow in via the primary until that link to you drops, the > provider will remove the route, and traffic will come in the back up route. This is unlikely to work, on a couple of levels. Given the same prefix-length on both announcements, you're unlikely to have much luck keeping traffic off your back-up path as Jason suggests. This means you'll need to have ways to withdraw the routes through both providers if their respective links fail, rather than just being able to withdraw the routes from one. I'm not sure what he means by doing a "weighted" announcement. If he means using the Cisco "weight" attribute, it's local to the router where it's set and won't propagate upstream. Your upstream providers could use that to control how traffic exits their networks, but not how traffic gets to them. Indeed, given two routing announcements of the same route to two different upstream providers who connect to the rest of the Internet in different ways, the announcing network has very little control over which route will be followed. Once an announcement is out there, routing decisions get made according to the policies of the networks sending traffic in the announcing network's direction, which are generally based more on customer relationships than on topological distance or anything that can be set on the announcing end. The usual way to attempt to influence inbound traffic flow is with AS path prepending -- making one path into a network look artifically long so that the other will look comparitively short. This partly works. Those who don't have any other reason to prefer one path over the other will prefer the shortest one. But it's not going to shift 100 percent of inbound traffic. The upstream provider, and their upstream providers, and anybody upstream from them, will probably all be using the BGP local-preference attribute to prefer paths they get paid for over paths they don't, and local-preference trumps AS path length no matter how many prepends are put into a path. As others here have suggested, you could have the provider that won't do BGP with you tie their own BGP announcement to your interface, such that if the interface facing you goes down the route will go away. Or you could have them use Cisco's conditional routing feature to only announce your route if they stop seeing your route being announced through your other provider. The problem with both of these approaches is that they depend on some BGP routing flexibility on the part of your upstream provider, and if your upstream provider were flexible in terms of how they handle BGP for customers we wouldn't be having this discussion. If you did want to follow Jason's suggestion of having primary/backup providers, such that inbound routing decisions are made based on whether the primary one is up, the tool you've probably got available is to announce more and less specific routes. Barring filters in your upstream providers' networks, a more specific route will always be chosen over a less specific one. So, if you've got a /22, you could have your non-BGP-speaking provider announce it as a /22 on your backup link, and announce it yourself as two /23s on your BGP-aware primary link. That should more or less work, at the cost of having two more routes in the global routing table and getting you some dirty looks from peers who will consider it irresponsible. That said, if you've got the resources, I think tunneling over the uncooperative provider to somebody who will do BGP with you on the mainland is probably a better answer. -Steve From nonobvious at gmail.com Sat Feb 7 19:17:08 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Sat, 7 Feb 2009 17:17:08 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <498CFC08.9090009@internode.com.au> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <0F8E47C2-B4B7-459A-862D-A59FFD7E556F@internode.com.au> <498C3D51.1030303@brightok.net> <498CFC08.9090009@internode.com.au> Message-ID: <18a5e7cb0902071717y7a607828yb06b09b643011f1f@mail.gmail.com> On Fri, Feb 6, 2009 at 7:12 PM, Matthew Moyle-Croft wrote: > Jack Bates wrote: > > Dynamic or static; how does this alter the state of the routing table?... > Dynamic assigned addresses mean that the BRAS the customer terminates on can > hand out a range out of a pool assigned to it. This means I can have a > single route in my routing table for a whole BRAS (maybe 20k customers) vs > 20k routes and associated processing when the dsl goes up/down/etc. That's not because it's doing dynamic address assignment - it's because you're only advertising the aggregate route from the BRAS/DSLAM/etc., and you can just as well do the same thing if you're using static addresses. You've got pretty much the same sized bunch of addresses and subnets regardless of how you're assigning them (except in rare cases where you're getting some statistical gain from lightly-loaded dynamic address pools), and while static addresses make it easier to use a dynamic routing protocol instead of static routing, you don't have to, or you can optionally use a dynamic routing protocol to hand routing information to the end users and then summarize at/above your BRAS. In the ipv4 world, you'd be advertising 1.2.0.0/15 either way, or a /12 if you're handing out /29s to your users instead of /32s; in the ipv6 world you'd be advertising 1337::0/39 if you're giving them /56s or 1337::0/47 if you're giving them /64s. The real difference is that if they have a static address (and can therefore advertise it with DNS easily without resorting to dynamic-DNS trickery), they may start to serve web pages, and then want to do so reliably, and then start multihoming, and then want a routing protocol to do better routing, and then either you'll need to do real work, or else you'll need to tell them to get a real circuit for their server instead of broadband, or else you'll need to tell them to use tunnels over the broadband so it's not your DSLAM/BRAS's problem. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From mmc at internode.com.au Sat Feb 7 19:56:28 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 08 Feb 2009 12:26:28 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <18a5e7cb0902071717y7a607828yb06b09b643011f1f@mail.gmail.com> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <498A3514.1050608@internode.com.au> <0F8E47C2-B4B7-459A-862D-A59FFD7E556F@internode.com.au> <498C3D51.1030303@brightok.net> <498CFC08.9090009@internode.com.au> <18a5e7cb0902071717y7a607828yb06b09b643011f1f@mail.gmail.com> Message-ID: <498E3BCC.6060607@internode.com.au> Bill Stewart wrote: > That's not because it's doing dynamic address assignment - it's > because you're only advertising the aggregate route from the > BRAS/DSLAM/etc., and you can just as well do the same thing if you're > using static addresses. Customers can land on one of a fleet of large BRAS across multiple POPs in a geographic region so that a failure of one piece of equipment or POP doesn't cause an outage. If I want to run a hint of redundancy then I need to propogate statics out of the POP itself. There are corners that can be cut but none seem to fit into the kind of redundancy we like. Unlike a most BGP routes DSL circuits tend to go up and down a lot, this adds to convergence time and CPU load on the router. My issue is not basic network design skills. My issue is that customers have indicated that they feel statics are a given for IPv6 and this would be a problem if I went from tens of thousands of statics to hundreds of thousands of static routes (ie. from a minority to all). Even injecting statics into iBGP rather than an IGP I feel would add considerably to the load routers face and give a big hit in the event of failure. (We already have a class of customer with statically assigned addresses or ranges). The indication so far seems to be that on this list at least people don't see IPv6 statics for all as the general option. This gives me a bit more hope. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From jsw at inconcepts.biz Sat Feb 7 20:24:30 2009 From: jsw at inconcepts.biz (Jeff S Wheeler) Date: Sat, 07 Feb 2009 21:24:30 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless Message-ID: <1234059870.17985.294.camel@guardian.inconcepts.net> Dear list, Since IPv4 exhaustion is an increasingly serious and timely topic lately, I would like to point out something that interests me, and maybe everyone else who will be spending a lot on Tylenol and booze when we really do run out of v4 IPs. I have trouble understanding why an ARIN record for a network regularly receiving new, out-sized IPv4 allocations on the order of millions of addresses at once would publish a remark like the one below, indicating that Verizon Wireless has about 2 million IPs allocated. OrgName: Cellco Partnership DBA Verizon Wireless CIDR: 97.128.0.0/9 Comment: Verizon Wireless currently has 44.3 Million Comment: subscribers with 2.097 Million IP addresses allocated. RegDate: 2008-04-14 This may be unscientific and full of error, but if you add up all the IPs behind AS6167, you get a pretty big number, about 27 million. If I make more dangerous assumptions, I might argue that a network with a need for 2 million IPs, at the time this /9 was handed out, already had about 19 million. Then it received 8 million more. Sure, smart phones are becoming more popular. It's reasonable to assume that virtually all cell phones will eventually have an IP address almost all the time. But that isn't the case right now, and the ARIN is in the business of supplying its members with six months worth of addresses. If everyone is expected to run out and buy a new phone and start using "the Google" right away, and stay on it all the time, maybe cellular operators really need a lot more IP addresses. If not, why does Verizon Wireless have 27 million IPs when the above comment indicates they need only a tenth of that? - j From jeffrey.lyon at blacklotus.net Sat Feb 7 22:06:28 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 7 Feb 2009 23:06:28 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <1234059870.17985.294.camel@guardian.inconcepts.net> References: <1234059870.17985.294.camel@guardian.inconcepts.net> Message-ID: <16720fe00902072006p1f8d441dpb1dcf58f49021837@mail.gmail.com> Whatever happened to NAT? Jeff On Sat, Feb 7, 2009 at 9:24 PM, Jeff S Wheeler wrote: > Dear list, > > Since IPv4 exhaustion is an increasingly serious and timely topic > lately, I would like to point out something that interests me, and maybe > everyone else who will be spending a lot on Tylenol and booze when we > really do run out of v4 IPs. > > I have trouble understanding why an ARIN record for a network regularly > receiving new, out-sized IPv4 allocations on the order of millions of > addresses at once would publish a remark like the one below, indicating > that Verizon Wireless has about 2 million IPs allocated. > > OrgName: Cellco Partnership DBA Verizon Wireless > CIDR: 97.128.0.0/9 > Comment: Verizon Wireless currently has 44.3 Million > Comment: subscribers with 2.097 Million IP addresses allocated. > RegDate: 2008-04-14 > > This may be unscientific and full of error, but if you add up all the > IPs behind AS6167, you get a pretty big number, about 27 million. If I > make more dangerous assumptions, I might argue that a network with a > need for 2 million IPs, at the time this /9 was handed out, already had > about 19 million. Then it received 8 million more. > > Sure, smart phones are becoming more popular. It's reasonable to assume > that virtually all cell phones will eventually have an IP address almost > all the time. But that isn't the case right now, and the ARIN is in the > business of supplying its members with six months worth of addresses. > If everyone is expected to run out and buy a new phone and start using > "the Google" right away, and stay on it all the time, maybe cellular > operators really need a lot more IP addresses. If not, why does Verizon > Wireless have 27 million IPs when the above comment indicates they need > only a tenth of that? > > - j > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From xmin0s at gmail.com Sat Feb 7 22:18:53 2009 From: xmin0s at gmail.com (Tim Eberhard) Date: Sat, 7 Feb 2009 22:18:53 -0600 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <1234059870.17985.294.camel@guardian.inconcepts.net> References: <1234059870.17985.294.camel@guardian.inconcepts.net> Message-ID: <2c52b84e0902072018k769a5089p323e71f5680da194@mail.gmail.com> Any cell phone that uses data service to download a ringtone, wallpaper, picature, use their TV/radio webcast service, or their walkie talkie feature will use an IP address. In addition to that Verizon wireless sells their EVDO aircards for laptops. Given the size of their customer base it is not shocking that they have 27 million IP addresses in their pool. ARIN doesn't just give them away it would be up to Verizon to prove that they are utilizing 90+% before they could be alloted any additional IP's. Hope this helps explain things a little bit. -Tim Eberhard Sure, smart phones are becoming more popular. It's reasonable to assume > that virtually all cell phones will eventually have an IP address almost > all the time. But that isn't the case right now, and the ARIN is in the > business of supplying its members with six months worth of addresses. > If everyone is expected to run out and buy a new phone and start using > "the Google" right away, and stay on it all the time, maybe cellular > operators really need a lot more IP addresses. If not, why does Verizon > Wireless have 27 million IPs when the above comment indicates they need > only a tenth of that? > > - j > > > From martin at theicelandguy.com Sat Feb 7 23:38:10 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Sun, 8 Feb 2009 00:38:10 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <1234059870.17985.294.camel@guardian.inconcepts.net> References: <1234059870.17985.294.camel@guardian.inconcepts.net> Message-ID: On Sat, Feb 7, 2009 at 9:24 PM, Jeff S Wheeler wrote: > Dear list, > > Since IPv4 exhaustion is an increasingly serious and timely topic > lately, I would like to point out something that interests me, and maybe > everyone else who will be spending a lot on Tylenol and booze when we > really do run out of v4 IPs. > > I have trouble understanding why an ARIN record for a network regularly > receiving new, out-sized IPv4 allocations on the order of millions of > addresses at once would publish a remark like the one below, indicating > that Verizon Wireless has about 2 million IPs allocated. > > OrgName: Cellco Partnership DBA Verizon Wireless > CIDR: 97.128.0.0/9 > Comment: Verizon Wireless currently has 44.3 Million > Comment: subscribers with 2.097 Million IP addresses allocated. > RegDate: 2008-04-14 > > Why don't you try asking them? OrgTechHandle: MGE16-ARIN OrgTechName: George, Matt OrgTechPhone: +1-908-306-7000 OrgTechEmail: abuse at verizonwireless.com From mtinka at globaltransit.net Sat Feb 7 23:42:53 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sun, 8 Feb 2009 13:42:53 +0800 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <8896CE14-9EEE-4F4C-8CF1-93925DF95B10@daork.net> References: <497D1764.4050709@ibctech.ca> <4988F2C4.3090100@ibctech.ca> <8896CE14-9EEE-4F4C-8CF1-93925DF95B10@daork.net> Message-ID: <200902081342.58379.mtinka@globaltransit.net> On Wednesday 04 February 2009 09:51:16 am Nathan Ward wrote: > You get the same with OSPF - you run OSPFv2 and OSPFv3 in > parallel. Suffice it to say that some vendors are already implementing 'draft-ietf-ospf-af-alt-06.txt', which allows OSPFv3 to handle multiple address families, including IPv4. But this still runs over an IPv6 link. I'd still recommend running IPv4 and IPv6 IGP's separately, unless the IGP integrates both protocols, as in the case of IS-IS. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Sat Feb 7 23:43:35 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sun, 8 Feb 2009 13:43:35 +0800 Subject: [Update] Re: New ISP to market, BCP 38, and new tactics In-Reply-To: <4988F8FA.3080402@ibctech.ca> References: <497D1764.4050709@ibctech.ca> <4988F8FA.3080402@ibctech.ca> Message-ID: <200902081343.36524.mtinka@globaltransit.net> On Wednesday 04 February 2009 10:10:02 am Steve Bertrand wrote: > I'm not ready for MPLS (but I am interested in the theory > of it's purpose), so when I'm done what I'm doing now, > I'll look at it. Well, having a v6 core will prevent from you running MPLS, as a v6 control plane for MPLS is not yet implemented by the vendors today. A draft for this is already out, though - 'draft-manral- mpls-ldp-ipv6-02'. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From mysidia at gmail.com Sun Feb 8 03:32:51 2009 From: mysidia at gmail.com (James Hess) Date: Sun, 8 Feb 2009 03:32:51 -0600 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: References: <1234059870.17985.294.camel@guardian.inconcepts.net> Message-ID: <6eb799ab0902080132m44e1e4f7ke68c821cd6bc5c71@mail.gmail.com> >> I have trouble understanding why an ARIN record for a network regularly >> receiving new, out-sized IPv4 allocations on the order of millions of >> OrgName: Cellco Partnership DBA Verizon Wireless >> CIDR: 97.128.0.0/9 >> Comment: Verizon Wireless currently has 44.3 Million >> Comment: subscribers with 2.097 Million IP addresses allocated. >> RegDate: 2008-04-14 If they have immediately allocated 2.097 million out of 8.388 million, then they have satisfied the 25% immediate utilization requirement. In fact, 2.097 million is exactly how many they would need immediate use for in order to justify an allocation of 8 million IPs according to ARIN policy. I expect the 2.097 million figure applies only to this particular range, this comment in whois does not indicate that Verizon has _only_ assigned that many across all its various ranges; I would fully expect they have massively more IPs in use. I would expect ARIN would have followed policy, and so Verizon had to show to ARIN their well-founded projection that within one year, at least 50% of the new assignment would be allocated. And also that they met the additional requirements for ISPs; 80% utilization over all previous allocations, and also 80% of their most recent allocation. -- -Jimmy From lear at cisco.com Sun Feb 8 07:09:36 2009 From: lear at cisco.com (Eliot Lear) Date: Sun, 08 Feb 2009 14:09:36 +0100 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <1234059870.17985.294.camel@guardian.inconcepts.net> References: <1234059870.17985.294.camel@guardian.inconcepts.net> Message-ID: <498ED990.2010806@cisco.com> On 2/8/09 3:24 AM, Jeff S Wheeler wrote: > Sure, smart phones are becoming more popular. It's reasonable to assume > that virtually all cell phones will eventually have an IP address almost > all the time. The numbers I keep seeing for so-called "smartphones" in the press for U.S. and Europe are 49% and 50% within two years, respectively. Here's an article you might find interesting about the U.S. domestic market, and it may help you calculate what sort of growth rate we can expect in the future, when combined with both of the above numbers. Put another way, the news is bad, but there is a cap on growth. http://albuquerque.bizjournals.com/dallas/stories/2008/09/29/story10.html Eliot From joelja at bogus.com Sun Feb 8 09:04:26 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 08 Feb 2009 07:04:26 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <498ED990.2010806@cisco.com> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <498ED990.2010806@cisco.com> Message-ID: <498EF47A.4080206@bogus.com> Eliot Lear wrote: > On 2/8/09 3:24 AM, Jeff S Wheeler wrote: >> Sure, smart phones are becoming more popular. It's reasonable to assume >> that virtually all cell phones will eventually have an IP address almost >> all the time. > > The numbers I keep seeing for so-called "smartphones" in the press for > U.S. and Europe are 49% and 50% within two years, respectively. Here's > an article you might find interesting about the U.S. domestic market, > and it may help you calculate what sort of growth rate we can expect in > the future, when combined with both of the above numbers. Put another > way, the news is bad, but there is a cap on growth. We live in rather sad times if, subscriber, arpu and internet usage growth is considered bad news. > http://albuquerque.bizjournals.com/dallas/stories/2008/09/29/story10.html > > Eliot > From eslerj at gmail.com Sun Feb 8 09:19:10 2009 From: eslerj at gmail.com (Joel Esler) Date: Sun, 8 Feb 2009 10:19:10 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <498EF47A.4080206@bogus.com> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <498ED990.2010806@cisco.com> <498EF47A.4080206@bogus.com> Message-ID: <8c643a500902080719k12f15a83qa5e17301b3308cba@mail.gmail.com> Exactly. On Sun, Feb 8, 2009 at 10:04 AM, Joel Jaeggli wrote: > Eliot Lear wrote: > > On 2/8/09 3:24 AM, Jeff S Wheeler wrote: > >> Sure, smart phones are becoming more popular. It's reasonable to assume > >> that virtually all cell phones will eventually have an IP address almost > >> all the time. > > > > The numbers I keep seeing for so-called "smartphones" in the press for > > U.S. and Europe are 49% and 50% within two years, respectively. Here's > > an article you might find interesting about the U.S. domestic market, > > and it may help you calculate what sort of growth rate we can expect in > > the future, when combined with both of the above numbers. Put another > > way, the news is bad, but there is a cap on growth. > > We live in rather sad times if, subscriber, arpu and internet usage > growth is considered bad news. > > > > http://albuquerque.bizjournals.com/dallas/stories/2008/09/29/story10.html > > > > Eliot > > > > > From bicknell at ufp.org Sun Feb 8 10:32:04 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 8 Feb 2009 11:32:04 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <1234059870.17985.294.camel@guardian.inconcepts.net> References: <1234059870.17985.294.camel@guardian.inconcepts.net> Message-ID: <20090208163203.GA97085@ussenterprise.ufp.org> I have no personal knowledge of this situation, so this is wild speculation. http://news.cnet.com/verizon-completes-alltel-purchase/ Verizon Wireless is going to be soon selling operations in 105 markets. It may well be that the IP addresses for those markets will be transfered to the new company as well, and you'll see some of these blocks leave their name soon. It could also be that AllTel had a much lower percentage of subscribers using data, and Verizon is fixing to change that soon. With the merger complete Verizon Wireless will have 83.7 million subscribers (per the article). I see 27,371,520 IP's in all their advertised blocks now, add in the 8,388,608 they just got, for a total of 35,760,128. If we assume across all blocks they can get 80% USAGE efficiency (which would surprise me) that's enough IP's to feed data to 28,608,102 subs. That would mean they can serve about 34% of their customers with data. Lastly, you've assumed that only a "smart phone" (not that the term is well defined) needs an IP address. I believe this is wrong. There are plenty of simpler phones (e.g. not a PDA, touch screen, read your e-mail thing) that can use cellular data to WEP browse, or to fetch things like ring tones. They use an IP on the network. By the same math they have 55.1 million (83.7 million subs - 28.6 they can serve now) they can't serve data to yet, and using the same 80% effiency that will take another 68.9 million addresses to do that. A /6 has 67.1 million addresses, so I suspect you'll see over time another /6, or two /7's, or four /8's, or eight /9's....... Which leaves us with two take aways: 1) The comment is weird. 2) If one company is likely to need four more /8's, and there are now 32 in the free pool man is IPv4 in trouble. At this point it would only take eight companies the size of verizon wireless to exhaust the free pool WORLDWIDE. No matter how much effort we put into reclaiming IPv4 space there's just no way to keep up with new demand. Is your network IPv6 enabled yet? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From a.harrowell at gmail.com Sun Feb 8 11:05:50 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Sun, 8 Feb 2009 17:05:50 +0000 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <20090208163203.GA97085@ussenterprise.ufp.org> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <20090208163203.GA97085@ussenterprise.ufp.org> Message-ID: Leo Bicknell: Lastly, you've assumed that only a "smart phone" (not that the term > is well defined) needs an IP address. I believe this is wrong. > There are plenty of simpler phones (e.g. not a PDA, touch screen, > read your e-mail thing) that can use cellular data to WEP browse, > or to fetch things like ring tones. They use an IP on the network. Alternatively, Verizon is planning to build an all-IP NGN architecture in the near future, or is at least providing for the possibility of building one. Mobilkom Austria, for example, has done a deal with Fring to put their SIP VoIP client on handsets and serve their voice traffic over IP. In that case, you'd need IP addresses for all the people who use VOICE. You can do ringtones and the like through USSD...but there's no escape from voice. From brandon at rd.bbc.co.uk Sun Feb 8 13:18:22 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 8 Feb 2009 19:18:22 GMT Subject: 97.128.0.0/9 allocation to verizon wireless Message-ID: <200902081918.TAA14374@sunf10.rd.bbc.co.uk> > 2) If one company is likely to need four more /8's, and there are now > 32 in the free pool man is IPv4 in trouble. It's going to happen soon enough anyway. > At this point it > would only take eight companies the size of verizon wireless to > exhaust the free pool WORLDWIDE. No matter how much effort we put > into reclaiming IPv4 space there's just no way to keep up with new > demand. If they were allowed to. At some point I hope (I've heard the RIRs are making plans) they'll be told "no, you can't roll out something that big as v4, that's enough infrastructure you can afford to build it as v6, the rest of the v4 is now only for smaller necessary v4 use". What is necessary v4 and the v6 only threshold can now be argued over while everyone else gets on with building v6 or big v4 NATs brandon From rs at seastrom.com Sun Feb 8 14:06:44 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Sun, 08 Feb 2009 15:06:44 -0500 Subject: Seeking FIOS tech support with two (or more) brain cells In-Reply-To: <863aetcwzl.fsf@seastrom.com> (Robert E. Seastrom's message of "Wed, 04 Feb 2009 23:45:50 -0500") References: <863aetcwzl.fsf@seastrom.com> Message-ID: <86fxio66cr.fsf@seastrom.com> A big thank-you to everyone who replied, called, sent kind words and shared frustration. Clearly I'm not alone here (even had frustration shared by people who actually work in a different business unit of Verizon), and it would be nice if the folks at VZ would take some steps to fix these apparently-endemic problems but so far no joy. Eventually I got called back by someone who, after listening to what I want to do, said "I know... we can turn off the MOCA and turn on the Ethernet right on your ONT, bypassing the firewall completely. Would that accomplish what you want to do?" I said yes, and we're now sailing happily along. No word yet on whether this burns our ability to get FIOS TV or not. Also, sadly, no way to repeat it other than the old "escalate, escalate, escalate" dance. I'm still not clear on how this was supposed to be a "business" service if you weren't intended to hang your own CPE on it. -r From beckman at angryox.com Sun Feb 8 14:10:15 2009 From: beckman at angryox.com (Peter Beckman) Date: Sun, 8 Feb 2009 15:10:15 -0500 Subject: L3: Google from DC via the Netherlands? In-Reply-To: <00b601c98946$0612a110$1237e330$@com> References: <0E8773C725A1674E9F7B35EABB5EEEB1047F1AB0@MKA134.pcc.int> <00b601c98946$0612a110$1237e330$@com> Message-ID: After a few emails traded with David Ulevitch from OpenDNS, it is clear to me that they do NOT suffer from this issue, and have a work-around. My apologies to David and to OpenDNS for lumping them in and not doing better due dilligence when researching this issue. On Sat, 7 Feb 2009, TJ wrote: > IMHO, off the top of my head, on a weekend where I haven't had enough coffee > yet: > > 3. Anycasted DNS Providers? Not sure how they could fix it, other than > flag certain domains as special, and do something special for them, > but man that smells like a hack. > > Anycast is a good thing, but when geo-location style concerns are factored > in maybe they should have region-based anycast addresses. Anycast is extremely useful for fault tolerance, agreed. But what I personally didn't consider, and I don't think other people consider, when they chose to use an alternative DNS caching resolution providers is what might break or not operate as expected. Having traded a few private emails from people smarter than I at Google and OpenDNS, I understand the issue much better than when I first posted. Thank you to you both. Here's a theoretical solution to this problem that I'd like to open for discussion. In each location where a provider hosts their anycasted service, there is likely a local, non-anycasted IP address for each server. When receiving a DNS request that is not in the local cache, or has expired, make the new request on that local IP address interface, rather than on the anycasted IP address interface. In those cases, GSLB records would likely return a more accurate set of results for clients making DNS requests of it, and when those records were requested from the anycasted DNS resolving service, the cached records would more likely be closer from a network standpoint to the actual service. Obviously there are some issues: * need to patch BIND or PowerDNS to use a different interface for making new requests * possibility of the responding anycasted DNS server being close to server farm A, while being far away from DNS record requestor B I'm curious to find out if others on the list know what other companies are using GSLB, and what the actual impact of anycasted DNS caching nameservers has on GSLB records. If enough people are using anycasted DNS resolution services, implementing a fix like this would reduce network traffic. By how much, I don't know. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From Mark_Andrews at isc.org Sun Feb 8 15:00:09 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon, 09 Feb 2009 08:00:09 +1100 Subject: L3: Google from DC via the Netherlands? In-Reply-To: Your message of "Sun, 08 Feb 2009 15:10:15 CDT." Message-ID: <200902082100.n18L09PP011051@drugs.dv.isc.org> In message , Peter Beckman writes: > After a few emails traded with David Ulevitch from OpenDNS, it is clear to > me that they do NOT suffer from this issue, and have a work-around. My > apologies to David and to OpenDNS for lumping them in and not doing better > due dilligence when researching this issue. > > On Sat, 7 Feb 2009, TJ wrote: > > > IMHO, off the top of my head, on a weekend where I haven't had enough coffe > e > > yet: > > > > 3. Anycasted DNS Providers? Not sure how they could fix it, other than > > flag certain domains as special, and do something special for them, > > but man that smells like a hack. > > > > Anycast is a good thing, but when geo-location style concerns are factored > > in maybe they should have region-based anycast addresses. > > Anycast is extremely useful for fault tolerance, agreed. But what I > personally didn't consider, and I don't think other people consider, when > they chose to use an alternative DNS caching resolution providers is what > might break or not operate as expected. > > Having traded a few private emails from people smarter than I at Google > and OpenDNS, I understand the issue much better than when I first posted. > Thank you to you both. > > Here's a theoretical solution to this problem that I'd like to open for > discussion. > > In each location where a provider hosts their anycasted service, there > is likely a local, non-anycasted IP address for each server. When > receiving a DNS request that is not in the local cache, or has expired, > make the new request on that local IP address interface, rather than on > the anycasted IP address interface. In those cases, GSLB records would > likely return a more accurate set of results for clients making DNS > requests of it, and when those records were requested from the > anycasted DNS resolving service, the cached records would more likely > be closer from a network standpoint to the actual service. > > Obviously there are some issues: > * need to patch BIND or PowerDNS to use a different interface for > making new requests query-source ....; > * possibility of the responding anycasted DNS server being close to > server farm A, while being far away from DNS record requestor B > > I'm curious to find out if others on the list know what other companies > are using GSLB, and what the actual impact of anycasted DNS caching > nameservers has on GSLB records. If enough people are using anycasted DNS > resolution services, implementing a fix like this would reduce network > traffic. By how much, I don't know. > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From lear at cisco.com Sun Feb 8 15:45:51 2009 From: lear at cisco.com (Eliot Lear) Date: Sun, 08 Feb 2009 22:45:51 +0100 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <20090208163203.GA97085@ussenterprise.ufp.org> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <20090208163203.GA97085@ussenterprise.ufp.org> Message-ID: <498F528F.70809@cisco.com> On 2/8/09 5:32 PM, Leo Bicknell wrote: > Lastly, you've assumed that only a "smart phone" (not that the term > is well defined) needs an IP address. I believe this is wrong. > There are plenty of simpler phones (e.g. not a PDA, touch screen, > read your e-mail thing) that can use cellular data to WEP browse, > or to fetch things like ring tones. They use an IP on the network. > The term is ill defined, but the general connotation is that they will be supplanting dumb phones. So say what you will,phones with IP addresses is likely to increase as a percentage of the installed base. The only thing offsetting that is the indication that the U.S. is saturating on total # of cell phones, which is what that article says. Moving on... Eliot From smb at cs.columbia.edu Sun Feb 8 15:58:17 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sun, 8 Feb 2009 16:58:17 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <498F528F.70809@cisco.com> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <20090208163203.GA97085@ussenterprise.ufp.org> <498F528F.70809@cisco.com> Message-ID: <20090208165817.6bf8aecc@cs.columbia.edu> On Sun, 08 Feb 2009 22:45:51 +0100 Eliot Lear wrote: > On 2/8/09 5:32 PM, Leo Bicknell wrote: > > Lastly, you've assumed that only a "smart phone" (not that the term > > is well defined) needs an IP address. I believe this is wrong. > > There are plenty of simpler phones (e.g. not a PDA, touch screen, > > read your e-mail thing) that can use cellular data to WEP browse, > > or to fetch things like ring tones. They use an IP on the network. > > > > The term is ill defined, but the general connotation is that they > will be supplanting dumb phones. So say what you will,phones with IP > addresses is likely to increase as a percentage of the installed > base. The only thing offsetting that is the indication that the U.S. > is saturating on total # of cell phones, which is what that article > says. > Of course, my iPhone is currently showing an IP address in 10/8, and though my EVDO card shows a global address in 70.198/16, I can't ssh to it -- a TCP traceroute appears to be blocked at the border of Verizon Wireless' network. But hey, at least I can ping it. (Confirmed by tcpdump on my laptop: the pings are not being spoofed by a border router.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From jgreco at ns.sol.net Sun Feb 8 15:58:10 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 8 Feb 2009 15:58:10 -0600 (CST) Subject: L3: Google from DC via the Netherlands? In-Reply-To: <200902082100.n18L09PP011051@drugs.dv.isc.org> from "Mark Andrews" at Feb 09, 2009 08:00:09 AM Message-ID: <200902082158.n18LwAds021222@aurora.sol.net> > > Here's a theoretical solution to this problem that I'd like to open for > > discussion. > > > > In each location where a provider hosts their anycasted service, there > > is likely a local, non-anycasted IP address for each server. There should be, yes. > > When > > receiving a DNS request that is not in the local cache, or has expired, > > make the new request on that local IP address interface, rather than on > > the anycasted IP address interface. Yes. You probably have to do this in any case. Think about it. If you have anycasted recursers in IAD, SJC, AMS, and HKG, and you're asking for an answer hosted on a nameserver near IAD, and the query goes from the anycast address to the near-IAD auth nameserver, then the response will probably wind up at IAD, even if it was the HKG server asking. That will not enable the HKG server to answer you. You can probably hack your way around that issue by creative use of VPNs and port assignments, but that's just a really poor-sounding solution. Using the local IP address makes the right thing just magically happen. > > I'm curious to find out if others on the list know what other companies > > are using GSLB, and what the actual impact of anycasted DNS caching > > nameservers has on GSLB records. If enough people are using anycasted DNS > > resolution services, implementing a fix like this would reduce network > > traffic. By how much, I don't know. The real problem is that if you're using an anycasted service, there is a good chance that the recurser you're using is much further away from you topologically than if you were just using a "local" recurser. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From trejrco at gmail.com Sun Feb 8 16:16:32 2009 From: trejrco at gmail.com (TJ) Date: Sun, 8 Feb 2009 17:16:32 -0500 Subject: IPv6 delivery model to end customers In-Reply-To: References: Message-ID: <018501c98a3a$e628a750$b279f5f0$@com> >I didn't know where to jump in in the current discussion and what I wanted >to discuss was quite general, so I thought I'd create a new thread instead. And the right move, IMHO! (FWIW) >So, anyone saying IPv6 is ready for prime-time whereever IPv4 is used, has a >very simplified view of the world. Yes, IPv6 works in the classic routed >network model where everything is statically set up (often manually), for >example with an ISP run CPE and static/dynamic routing and a fixed /48 >issued for that customer and SWIPed. Then it's easy to delegate reverse-DNS >etc to the customer DNS. We would need to differentiate between the protocol being ready, and the vendors' support of the protocol here. In other words, the ivory tower work is done - now it is up to the real world. Oh, and yes, in that "enterprise" deployment scenario we are almost ready! >My ideal model would be to replace the above mentioned L2 device with a >small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8 >times port number should be enough), where this device uses link-local with >the CPEs (would require all customers to actually have a router at home), >hands out prefixes via DHCPv6-PD, inserts route towards customer link-local >address, provisions anti-spoofing ACLs on that port, logs what prefix was >given out to each port at what time, and off we go. (Rationale for link- >local only is to have only customer devices in "Customer IP space" and only >ISP infrastructure in that IP-space. This is equivalent to "ip unnumbered" >in IPv4 in my view.) I have pitched this idea in the IETF v6ops list and >it's now included in a draft that lists different models of >IPv6 delivery. > >As far as I know, this IPv6 L3 device doesn't exist (in the pricerange >needed for massive residential roll-out anyhow). While that sounds functional/useful, I would first ask - to the residential-focused ISPs - how they currently plan (or how are they moving towards) delivering IPv6 to their clients? >So, in the meantime, to get IPv6 to the end customers I see two ways >(because they need to fit into the IPv4 security model mentioned above). >We have either 6to4 tunneling (Cisco 7600 does this very well and code for >Linux CPEs exist already), or we try to fit IPv6 into the IPv4 security >model. Current recommendation from the swedish "city networks association" >(they consists mostly of entities running LANs to residential, I believe >there are approx 400-500k ports of that in Sweden at this time) is that if >you don't know if your network is secure against IPv6, block it at the >ethertype level (I'll come back to the security risks later). 6to4 works just fine, assuming you and your customers are OK with tunneling and relays ... up until there are no more public IPs. Then you are talking about "A+P + 6to4" or somesuch. *EVEN MORE FUN* >So, what is the security problem with IPv6 in an IPv4 network? Well, imagine >an IPv4 network where security is done via ARP inspection, DHCP snooping and >L3 ACLs. Now, insert rogue customer who announces itself via >RA/DHCPv6 and says it's also DNS. Vista machines will get itself an IPv6 >address via RA, ask for DNS-server via DHCPv6, so if the rogue customer can >do some NAT-PT like functionality, they are now man in the middle for all >the IPv4 traffic (because between the customers it's IPv6 and the L2 device >doesn't know anything about that). I don't know if this has actually been >done, but I see no theoretical problem with it, if someone can come up with >something, please do tell. "RA Guard"; learn it, live it, love it. At some point, maybe SEND/CGA as well ... but that isn't a "ready today" thing. >So, my view on IPv6 is that I would love to roll it out to all residential >customers, but unfortunately all the development done for IPv4 security has >gone unnoticed by the people developing IPv6 and now it's behind and needs >to catch up, or pitch a different model and then get vendors to develop >products that do this. I think that is a bit harsh - the work hasn't gone unnoticed. Rather, it has not been high enough on the list of priorities and is therefore, yes, lagging. >In the mean time, we do (and I encourage everybody else to do the same) >support 6to4 and Teredo, plus we do IPv6 native in the core and peering >where possible plus we give IPv6 to customers where we're able to securely >(mostly transit customers and corporate customers with IPv6 capable CPEs). AMEN! From trejrco at gmail.com Sun Feb 8 16:24:08 2009 From: trejrco at gmail.com (TJ) Date: Sun, 8 Feb 2009 17:24:08 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: <20090207.164346.41698438.sthaug@nethelp.no> References: <498C9F6C.7050109@brightok.net> <20090206212954.GG5164@isc.org> <07EE8177-9A56-4C46-95D0-D718C85906E1@daork.net> <20090207.164346.41698438.sthaug@nethelp.no> Message-ID: <018601c98a3b$f65db650$e31922f0$@com> >> > I suppose you can individually configure every host to get itself >> > temporary addresses from RA announcements. This isn't usually a >> > good default configuration, but OS implementation already seems to >> > be inconsistent on the default configuration here. So we're back to >> > the IPv4 dark ages where you have to walk around to all the devices >> > to effect changes in policy (beyond prefix field contents). >> >> >> I'm not sure, but you seem to be implying that you need to configure >> hosts to tell them to use RA or DHCPv6 to get addresses. My apologies >> if this is not your intention. >> >> RA messages are always going to be sent by routers and received by >> hosts, even if DHCPv6 is being used for address assignment. > >This does not seem to be generally true: > >- For the routers I am most familiar with (Juniper M/MX), you need to >explicitly turn on router advertisement to make the router perform this. >I.e. it is perfectly possible to have an interface with an IPv6 address >which does *not* send RAs. Yes, vendors differ ... for Ciso/IOS - broadcast capable, multi-access interfaces (a la Ethernet) will automatically send RAs ones a /64 IPv6 address is configured. Or once you explicitly tell it to advertise one. >- For the operating system I am most familiar with (FreeBSD), RAs are >*not* accepted by default if the interface in question is configured with a >static IPv6 address. I don't believe that is the general behavior, and specifically - for Win* a static being configured does not prevent autoconfiguration. And this is the correct behavior - to allow for cases where multiple prefixes are correct/expected, and only one is static. >Both of these choices seem perfectly reasonable to me. I slightly disagree on the latter; autoconfiguration in the presence of RAs (including a (or several) prefix options) should be the default. ((... and now begins (continues, really) the pseudo-religious debate between the autoconfiguration people and the DHCPv6 people ...)) /TJ From aaron.glenn at gmail.com Sun Feb 8 16:37:31 2009 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Sun, 8 Feb 2009 14:37:31 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <16720fe00902072006p1f8d441dpb1dcf58f49021837@mail.gmail.com> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <16720fe00902072006p1f8d441dpb1dcf58f49021837@mail.gmail.com> Message-ID: <18f601940902081437x6236a207q483cbb92ca8d91d0@mail.gmail.com> On Sat, Feb 7, 2009 at 8:06 PM, Jeffrey Lyon wrote: > Whatever happened to NAT? > > Jeff NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? there should be a FOIA-like method to see large allocation justifications From jsw at inconcepts.biz Sun Feb 8 15:32:41 2009 From: jsw at inconcepts.biz (Jeff S Wheeler) Date: Sun, 08 Feb 2009 16:32:41 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <18f601940902081437x6236a207q483cbb92ca8d91d0@mail.gmail.com> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <16720fe00902072006p1f8d441dpb1dcf58f49021837@mail.gmail.com> <18f601940902081437x6236a207q483cbb92ca8d91d0@mail.gmail.com> Message-ID: <1234128761.17985.352.camel@guardian.inconcepts.net> On Sun, 2009-02-08 at 14:37 -0800, Aaron Glenn wrote: > NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? > there should be a FOIA-like method to see large > allocation justifications Realistically, I suppose Verizon Wireless is big enough to dictate to the manufacturers of handsets and infrastructure, "you must support IPv6 by X date or we will no longer buy / sell your product." I wonder if any wireless carriers are doing this today? What services require an IP, whether they can be supplied via NAT, how soon "smart phone" adoption will bring IP to every handset ... all these are good and valid points. However, they all distract from the glaring and obvious reality that there is no current explanation for Verizon Wireless needing 27M IPs. Does ARIN lack sufficient resources to vet jumbo requests? Did Verizon Wireless benefit from favoritism? Is Barack Obama concerned that his blackberry will not function if Verizon one day runs out of v4 addresses for its customers? - j From gtb at slac.stanford.edu Sun Feb 8 17:33:11 2009 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Sun, 8 Feb 2009 15:33:11 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <1234128761.17985.352.camel@guardian.inconcepts.net> References: <18f601940902081437x6236a207q483cbb92ca8d91d0@mail.gmail.com> <1234128761.17985.352.camel@guardian.inconcepts.net> Message-ID: > Does ARIN lack sufficient resources to vet jumbo requests? I am fairly confident ARIN followed their policies. The existing policies allow anyone (including Verizon) to make a request for (and receive) a /9 with appropriate justification. If you do not like the policies, please participate in the ARIN policy process and work to change them. Mailing lists: arin-ppml at arin.net Open to the general public. Provides a forum to raise and discuss policy-related ideas and issues surrounding existing and proposed ARIN policies. The PPML list is an intrinsic part of ARIN's Policy Development Process (PDP), which details how proposed policies are handled. http://www.arin.net/mailing_lists/index.html From Mark_Andrews at isc.org Sun Feb 8 18:07:52 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon, 09 Feb 2009 11:07:52 +1100 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: Your message of "Sun, 08 Feb 2009 16:32:41 CDT." <1234128761.17985.352.camel@guardian.inconcepts.net> Message-ID: <200902090007.n1907qY2069724@drugs.dv.isc.org> In message <1234128761.17985.352.camel at guardian.inconcepts.net>, Jeff S Wheeler writes: > On Sun, 2009-02-08 at 14:37 -0800, Aaron Glenn wrote: > > NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? > > there should be a FOIA-like method to see large > > allocation justifications > Realistically, I suppose Verizon Wireless is big enough to dictate to > the manufacturers of handsets and infrastructure, "you must support IPv6 > by X date or we will no longer buy / sell your product." I wonder if > any wireless carriers are doing this today? > > What services require an IP, whether they can be supplied via NAT, how > soon "smart phone" adoption will bring IP to every handset ... all these > are good and valid points. However, they all distract from the glaring > and obvious reality that there is no current explanation for Verizon > Wireless needing 27M IPs. Well it's a 8M allocation for current population of 2M with a 25M more potential handsets that will be upgraded soon. This looks to be consistent with how ARIN hands out other blocks of address space. Say on average that you replace a cell phone every three years. In 6 months there will be ~4M more addresses needed. I don't see any reason to complain based on those numbers. It's just a extremely high growth period due to technology change over bring in new functionality. Mark > Does ARIN lack sufficient resources to vet jumbo requests? > > Did Verizon Wireless benefit from favoritism? > > Is Barack Obama concerned that his blackberry will not function if > Verizon one day runs out of v4 addresses for its customers? > > - j > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From aaron.glenn at gmail.com Sun Feb 8 21:37:08 2009 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Sun, 8 Feb 2009 19:37:08 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <200902090007.n1907qY2069724@drugs.dv.isc.org> References: <1234128761.17985.352.camel@guardian.inconcepts.net> <200902090007.n1907qY2069724@drugs.dv.isc.org> Message-ID: <18f601940902081937u7e71244ai430612b4044a5fdf@mail.gmail.com> On Sun, Feb 8, 2009 at 4:07 PM, Mark Andrews wrote: > > I don't see any reason to complain based on those numbers. > It's just a extremely high growth period due to technology > change over bring in new functionality. so if they don't deploy IPv6 then ('extremely high growth period'), when will they? I don't presume to speak for everyone who immediately felt that tinge of surprise at reading of a /9 being allocated, but the blame is being laid on vzw not doing something other than 'can we have a /9 please?' --not ARIN and/or it's policies (another mailing list, duly noted) From frnkblk at iname.com Sun Feb 8 21:47:37 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 8 Feb 2009 21:47:37 -0600 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <20090208165817.6bf8aecc@cs.columbia.edu> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <20090208163203.GA97085@ussenterprise.ufp.org> <498F528F.70809@cisco.com> <20090208165817.6bf8aecc@cs.columbia.edu> Message-ID: This discussion about smartphones and the like was presuming that those devices all received public IPs -- my experience has been more often than not that they get RFC 1918 addresses. Frank -----Original Message----- From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] Sent: Sunday, February 08, 2009 3:58 PM To: Eliot Lear Cc: nanog at nanog.org Subject: Re: 97.128.0.0/9 allocation to verizon wireless On Sun, 08 Feb 2009 22:45:51 +0100 Eliot Lear wrote: > On 2/8/09 5:32 PM, Leo Bicknell wrote: > > Lastly, you've assumed that only a "smart phone" (not that the term > > is well defined) needs an IP address. I believe this is wrong. > > There are plenty of simpler phones (e.g. not a PDA, touch screen, > > read your e-mail thing) that can use cellular data to WEP browse, > > or to fetch things like ring tones. They use an IP on the network. > > > > The term is ill defined, but the general connotation is that they > will be supplanting dumb phones. So say what you will,phones with IP > addresses is likely to increase as a percentage of the installed > base. The only thing offsetting that is the indication that the U.S. > is saturating on total # of cell phones, which is what that article > says. > Of course, my iPhone is currently showing an IP address in 10/8, and though my EVDO card shows a global address in 70.198/16, I can't ssh to it -- a TCP traceroute appears to be blocked at the border of Verizon Wireless' network. But hey, at least I can ping it. (Confirmed by tcpdump on my laptop: the pings are not being spoofed by a border router.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From drc at virtualized.org Sun Feb 8 22:10:51 2009 From: drc at virtualized.org (David Conrad) Date: Sun, 8 Feb 2009 20:10:51 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <18f601940902081937u7e71244ai430612b4044a5fdf@mail.gmail.com> References: <1234128761.17985.352.camel@guardian.inconcepts.net> <200902090007.n1907qY2069724@drugs.dv.isc.org> <18f601940902081937u7e71244ai430612b4044a5fdf@mail.gmail.com> Message-ID: <886FB5BA-FAF7-40FE-BF2E-C8E81E7AD853@virtualized.org> On Feb 8, 2009, at 7:37 PM, Aaron Glenn wrote: > so if they don't deploy IPv6 then ('extremely high growth period'), > when will they? Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled? Regards, -drc From Skywing at valhallalegends.com Sun Feb 8 22:19:20 2009 From: Skywing at valhallalegends.com (Skywing) Date: Sun, 8 Feb 2009 22:19:20 -0600 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: References: <1234059870.17985.294.camel@guardian.inconcepts.net> <20090208163203.GA97085@ussenterprise.ufp.org> <498F528F.70809@cisco.com> <20090208165817.6bf8aecc@cs.columbia.edu> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6C00B33CB45@caralain.haven.nynaeve.net> For better or worse, Verizon hands out globally routable addresses for smartphones. (Certainly, the one I've got has one.) They seem to come from the same pool as data card links. Note that I suspect that there's a nontrivial number of folk that are used to using some not quite really NAT friendly protocols like IPsec on their (targeted-for-business primarily smartphones). (Yeah, there's IPsec NAT-T, which I've seen fall flat on its face countless times.) Breaking that sort of connectivity is likely to be hard to swallow for some nontrivial portion of some of their customers. - S -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, February 08, 2009 10:48 PM To: nanog at nanog.org Subject: RE: 97.128.0.0/9 allocation to verizon wireless This discussion about smartphones and the like was presuming that those devices all received public IPs -- my experience has been more often than not that they get RFC 1918 addresses. Frank -----Original Message----- From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] Sent: Sunday, February 08, 2009 3:58 PM To: Eliot Lear Cc: nanog at nanog.org Subject: Re: 97.128.0.0/9 allocation to verizon wireless On Sun, 08 Feb 2009 22:45:51 +0100 Eliot Lear wrote: > On 2/8/09 5:32 PM, Leo Bicknell wrote: > > Lastly, you've assumed that only a "smart phone" (not that the term > > is well defined) needs an IP address. I believe this is wrong. > > There are plenty of simpler phones (e.g. not a PDA, touch screen, > > read your e-mail thing) that can use cellular data to WEP browse, > > or to fetch things like ring tones. They use an IP on the network. > > > > The term is ill defined, but the general connotation is that they > will be supplanting dumb phones. So say what you will,phones with IP > addresses is likely to increase as a percentage of the installed > base. The only thing offsetting that is the indication that the U.S. > is saturating on total # of cell phones, which is what that article > says. > Of course, my iPhone is currently showing an IP address in 10/8, and though my EVDO card shows a global address in 70.198/16, I can't ssh to it -- a TCP traceroute appears to be blocked at the border of Verizon Wireless' network. But hey, at least I can ping it. (Confirmed by tcpdump on my laptop: the pings are not being spoofed by a border router.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From Skywing at valhallalegends.com Sun Feb 8 22:22:29 2009 From: Skywing at valhallalegends.com (Skywing) Date: Sun, 8 Feb 2009 22:22:29 -0600 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <18f601940902081937u7e71244ai430612b4044a5fdf@mail.gmail.com> References: <1234128761.17985.352.camel@guardian.inconcepts.net> <200902090007.n1907qY2069724@drugs.dv.isc.org> <18f601940902081937u7e71244ai430612b4044a5fdf@mail.gmail.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6C00B33CB46@caralain.haven.nynaeve.net> I think that you've got a bit of a logic fault here. You seem to be assuming that because you can't find any external any sign of Verizon preparing for IPv6, that they're definitely not doing so. Maybe they are, maybe they aren't (your -guess- is as good as mine), but that process is not necessarily going to be broadcast to the entire world. Especially after the earlier thread via customer IPv6 rollouts by ISPs, I think it should be fairly evident that there can be nontrivial "backend" plumbing work needed to get things IPv6 ready, not all of which is necessarily going to be inherently customer-visible for all stages of progress. - S -----Original Message----- From: Aaron Glenn [mailto:aaron.glenn at gmail.com] Sent: Sunday, February 08, 2009 10:37 PM To: nanog at nanog.org Subject: Re: 97.128.0.0/9 allocation to verizon wireless On Sun, Feb 8, 2009 at 4:07 PM, Mark Andrews wrote: > > I don't see any reason to complain based on those numbers. > It's just a extremely high growth period due to technology > change over bring in new functionality. so if they don't deploy IPv6 then ('extremely high growth period'), when will they? I don't presume to speak for everyone who immediately felt that tinge of surprise at reading of a /9 being allocated, but the blame is being laid on vzw not doing something other than 'can we have a /9 please?' --not ARIN and/or it's policies (another mailing list, duly noted) From pauldotwall at gmail.com Mon Feb 9 00:08:54 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 9 Feb 2009 01:08:54 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <18f601940902081437x6236a207q483cbb92ca8d91d0@mail.gmail.com> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <16720fe00902072006p1f8d441dpb1dcf58f49021837@mail.gmail.com> <18f601940902081437x6236a207q483cbb92ca8d91d0@mail.gmail.com> Message-ID: <620fd17c0902082208s27f9c75cpb68d132f24358d3c@mail.gmail.com> On Sun, Feb 8, 2009 at 5:37 PM, Aaron Glenn wrote: > NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? > there should be a FOIA-like method to see large > allocation justifications Probably because Verizon Business isn't using it, unless you count a couple of lab GRE tunnels. Drive Slow, Paul Wall From pauldotwall at gmail.com Mon Feb 9 00:11:58 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 9 Feb 2009 01:11:58 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <1234128761.17985.352.camel@guardian.inconcepts.net> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <16720fe00902072006p1f8d441dpb1dcf58f49021837@mail.gmail.com> <18f601940902081437x6236a207q483cbb92ca8d91d0@mail.gmail.com> <1234128761.17985.352.camel@guardian.inconcepts.net> Message-ID: <620fd17c0902082211l6e21999et509d6d06e5d43bdd@mail.gmail.com> On Sun, Feb 8, 2009 at 4:32 PM, Jeff S Wheeler wrote: > What services require an IP, whether they can be supplied via NAT, how > soon "smart phone" adoption will bring IP to every handset ... all these > are good and valid points. However, they all distract from the glaring > and obvious reality that there is no current explanation for Verizon > Wireless needing 27M IPs. 27 million IP addresses for 45 million customers with addressable devices sounds well within ARIN's justification guidelines. Just because most of your customers are trying to pull the wool over ARIN's eyes doesn't mean Verizon is too. :) Drive Slow, Paul Wall From morrowc.lists at gmail.com Mon Feb 9 00:14:25 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Feb 2009 01:14:25 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <620fd17c0902082208s27f9c75cpb68d132f24358d3c@mail.gmail.com> References: <1234059870.17985.294.camel@guardian.inconcepts.net> <16720fe00902072006p1f8d441dpb1dcf58f49021837@mail.gmail.com> <18f601940902081437x6236a207q483cbb92ca8d91d0@mail.gmail.com> <620fd17c0902082208s27f9c75cpb68d132f24358d3c@mail.gmail.com> Message-ID: <75cb24520902082214n114662a0j84c4b80131d48474@mail.gmail.com> On Mon, Feb 9, 2009 at 1:08 AM, Paul Wall wrote: > On Sun, Feb 8, 2009 at 5:37 PM, Aaron Glenn wrote: >> NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? >> there should be a FOIA-like method to see large >> allocation justifications > > Probably because Verizon Business isn't using it, unless you count a > couple of lab GRE tunnels. so... actually... if you ask for v6 apparently vzb's deployment is still moving along and is accessible for customers. FiOS/DSL though is not :( -Chris From mleber at he.net Mon Feb 9 00:38:41 2009 From: mleber at he.net (Mike Leber) Date: Sun, 08 Feb 2009 22:38:41 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <886FB5BA-FAF7-40FE-BF2E-C8E81E7AD853@virtualized.org> References: <1234128761.17985.352.camel@guardian.inconcepts.net> <200902090007.n1907qY2069724@drugs.dv.isc.org> <18f601940902081937u7e71244ai430612b4044a5fdf@mail.gmail.com> <886FB5BA-FAF7-40FE-BF2E-C8E81E7AD853@virtualized.org> Message-ID: <498FCF71.9030807@he.net> David Conrad wrote: > On Feb 8, 2009, at 7:37 PM, Aaron Glenn wrote: >> so if they don't deploy IPv6 then ('extremely high growth period'), >> when will they? > > Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled? haha, I went insane for a moment and though you said Freenix top 1000, and so I just checked that. Here is the answer to the question you didn't ask: Top 1000 Usenet Servers in the World list here: http://news.anthologeek.net/top1000.current.txt details here: http://news.anthologeek.net 1000 usenet server names 913 are potentially valid hostnames (in usenet news a server name does necessarily correspond directly to a hostname) 722 have ipv4 address records (A) 67 have ipv6 address records (AAAA) 9.2% of the top 1000 usenet servers have added support for ipv6 I'm sure there are more this took exactly 183 seconds of work. ;) Here they are: feeder.erje.net 2001:470:992a::3e19:561 feeder4.cambrium.nl 2a02:58:3:119::4:1 news.dal.ca 2001:410:a010:1:214:5eff:fe0a:4a4e news.nonexiste.net 2002:6009:93d5::1 nrc-news.nrc.ca 2001:410:9000:2::2 news.z74.net 2001:610:637:4::211 news.kjsl.com 2001:1868:204::104 npeer.de.kpn-eurorings.net 2001:680:0:26::2 feeder6.cambrium.nl 2a02:58:3:119::6:1 feeder3.cambrium.nl 2a02:58:3:119::3:1 news.belnet.be 2001:6a8:3c80::38 feeder2.cambrium.nl 2a02:58:3:119::2:1 feeder5.cambrium.nl 2a02:58:3:119::5:1 syros.belnet.be 2001:6a8:3c80::17 vlad-tepes.bofh.it 2001:1418:13:1::5 news.stack.nl 2001:610:1108:5011:230:48ff:fe12:2794 ikarus.belnet.be 2001:6a8:3c80::38 news.space.net 2001:608::1000:7 feed.news.tnib.de 2001:1b18:f:4::4 newsfeed.velia.net 2a01:7a0:3::254 news.isoc.lu 2001:a18:0:405:0:a0:456:1 ikaria.belnet.be 2001:6a8:3c80::39 newsfeed.teleport-iabg.de 2001:1b10:100::119:1 news.tnib.de 2001:1b18:f:4::2 kanaga.switch.ch 2001:620:0:8::119:2 erode.bofh.it 2001:1418:13:1::3 irazu.switch.ch 2001:620:0:8::119:3 bofh.it 2001:1418:13::42 newsfeed.atman.pl 2001:1a68:0:4::2 news.mb-net.net 2a01:198:292:0:210:dcff:fe67:6b03 news.gnuher.de 2a01:198:293::2 switch.ch 2001:620:0:1b::b news.k-dsl.de 2a02:7a0:1::5 news.task.gda.pl 2001:4070:1::fafe news1.tnib.de 2001:1b18:f:4::2 aspen.stu.neva.ru 2001:b08:2:100::96 novso.com 2001:1668:2102:4::4 citadel.nobulus.com 2001:6f8:892:6ff::11:133 feeder.news.heanet.ie 2001:770:18:2::c101:db29 news-zh.switch.ch 2001:620:0:3::119:1 news.szn.dk 2001:1448:89::10:d85d news.litech.org 2001:440:fff9:100:202:b3ff:fea4:a44e news.weisnix.org 2001:6f8:892:6ff:213:8fff:febb:bec3 news.panservice.it 2001:40d0:0:4000::e nntp.eutelia.it 2001:750:2:3::20 bolzen.all.de 2001:bf0::60 newsfeed.esat.net 2001:7c8:3:1::3 news.snarked.org 2607:f350:1::1:4 feed1.news.be.easynet.net 2001:6f8:200:2::5:46 aotearoa.belnet.be 2001:6a8:3c80::58 news.babsi.de 2a01:198:292:0:230:48ff:fe51:a68c news.muc.de 2001:608:1000::2 newsfeed.carnet.hr 2001:b68:e160::3 news.nask.pl 2001:a10:1:ffff::3:c9a2 news.linuxfan.it 2001:4c90:2::6 texta.sil.at 2001:858:2:1::2 news.stupi.se 2001:440:1880:5::10 news.supermedia.pl 2001:4c30:0:3::12 news.trigofacile.com 2001:41d0:1:6d44::1 nuzba.szn.dk 2001:6f8:1232::263:8546 geiz-ist-geil.priv.at 2001:858:666:f001::57 newsfeed.sunet.se 2001:6b0:7:88::101 news.pimp.lart.info 2001:6f8:9ed::1 glou.fr.eu.org 2001:838:30b::1 news.germany.com 2001:4068:101:119:1::77 feeder.z74.net 2001:610:637:4::211 news.nask.org.pl 2001:a10:1:ffff::3:c9a2 Mike. -- +---------------- H U R R I C A N E - E L E C T R I C ----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric AS6939 | | mleber at he.net Internet Backbone & Colocation http://he.net | +---------------------------------------------------------------------+ From andris at hpl.hp.com Mon Feb 9 00:59:37 2009 From: andris at hpl.hp.com (Andris Kalnozols) Date: Sun, 08 Feb 2009 22:59:37 PST Subject: Packet Loss between Qwest and Global Crossing Message-ID: <200902090659.WAA20506@nasdaq.hpl.hp.com> This post to the NANOG list in the hope that an interested engineer from either Qwest or GBLX will act on the problem I have observed. I've identified a packet loss problem (10-15%) between Qwest and Global Crossing. From one end (HP), the partial traceroute is: traceroute to 68.85.190.221 (68.85.190.221), 30 hops max, 40 byte packets 1 lpagwb01-vlan151-phy.hpl.hp.com (192.6.19.2) 0.622 ms 0.378 ms 0.315 ms 2 * * * 3 * * * 4 65.115.64.25 (65.115.64.25) 1.380 ms 1.297 ms 1.233 ms 5 205.171.14.150 (205.171.14.150) 1.377 ms 1.385 ms 1.277 ms 6 67.14.34.14 (67.14.34.14) 1.955 ms 2.046 ms 1.962 ms 7 205.171.233.18 (205.171.233.18) 2.204 ms 2.204 ms 2.076 ms 8 63.146.26.42 (63.146.26.42) 5.937 ms 4.253 ms 4.574 ms 9 * COMCAST-IP-SERVICES-LLC.TenGigabitEthernet1-3.ar2.snv2.gblx.net (64.211.1.214) 21.942 ms 21.670 ms There's no packet loss until the `gblx.net' (64.211.1.214) is pinged. Coming from the other end (Comcast), the partial traceroute is: Tracing route to gundega.hpl.hp.com [192.6.19.190] over a maximum of 30 hops: 1 * * * Request timed out. 2 9 ms 7 ms 7 ms 68.85.190.221 3 8 ms 6 ms 6 ms 68.87.226.66 4 7 ms 6 ms 7 ms te-9-1-ur06.sanjose.ca.sfba.comcast.net [68.87.192.54] 5 9 ms 9 ms 11 ms te-0-3-0-4-ar01.oakland.ca.sfba.comcast.net [68.87.226.229] 6 11 ms 11 ms 11 ms pos-0-4-0-0-cr01.sacramento.ca.ibone.comcast.net [68.86.90.141] 7 13 ms 12 ms 13 ms pos-0-8-0-0-cr01.sanjose.ca.ibone.comcast.net [68.86.85.78] 8 14 ms 12 ms 12 ms TenGigabitEthernet3-1.ar1.snv2.gblx.net [64.214.174.109] 9 41 ms * 38 ms sjp-brdr-02.inet.qwest.net [63.146.26.41] Pinging from this direction, there no packet loss until the first Qwest router (63.146.26.41) is pinged. So it seems clear that the problem is between Qwest and Global Crossing. ------ Andris From joelja at bogus.com Mon Feb 9 01:21:55 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 08 Feb 2009 23:21:55 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: <49555.1233631443@turing-police.cc.vt.edu> References: <49555.1233631443@turing-police.cc.vt.edu> Message-ID: <498FD993.5060604@bogus.com> Valdis.Kletnieks at vt.edu wrote: > On Tue, 03 Feb 2009 11:25:40 +0900, Randy Bush said: >>> Not quite.. >>> 2^96 = 79228162514264337593543950336 >>> 2^128-2^32 = 340282366920938463463374607427473244160 >> not quite. let's posit 42 devices on the average lan segment >> (ymmv). >> >> 42*(2^64) = 774763251095801167872 > > Let's face it - they're going to have to come up with much more creative > $200/hour chucklehead consultants to burn through that much anytime soon. > Anybody feel like starting a pool for when we'll see a posting to NANOG > about somebody who's managed to burn through a /32? two of them will separately just assign fc00::/7 to a network instead of following the instructions. From sethm at rollernet.us Mon Feb 9 01:32:49 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Feb 2009 23:32:49 -0800 Subject: Automatic Switches? Message-ID: <498FDC21.2080502@rollernet.us> I hate to interrupt the IPv6 and RFC 1918 mega-threads... Does anyone know of a company that makes 208v (3-wire line-line ground, no neutral, 208v loads only, single phase) 30-60 amp automatic transfer switches with sub-30ms switching time? APC used to make the SU045X163 30A model, but it seems to have been discontinued and it's hard to find products that support 208v single phase. ~Seth From joelja at bogus.com Mon Feb 9 01:42:18 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 08 Feb 2009 23:42:18 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> Message-ID: <498FDE5A.5000105@bogus.com> Skeeve Stevens wrote: > Owned by an ISP? It isn't much different than it is now. > > As long as you are multi-homed you can get a small allocation (/48), > APNIC and ARIN have procedures for this. > > Yes, you have to pay for it, but the addresses will be yours, unlike > the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share > and hope we never interconnect/overlap. > > I can't find a RFC1918 equivalent for v6 with the exception of > 2001:0DB8::/32# which is the ranges that has been assigned for > documentation use and is considered to NEVER be routable. In that > /32 are 65536 /48's... way more than the RFC1918 we have now. FD00::/8 ula-l rfc 4139 > If I was going to build a v6 network right now, that was purely > private and never* going to hit the internet, and I could not afford > to be a NIC member or pay the fees... then I would be using the > ranges above.... I wonder if that will start a flame war *puts on > fire suit*. From sethm at rollernet.us Mon Feb 9 01:58:18 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Feb 2009 23:58:18 -0800 Subject: Automatic Switches? In-Reply-To: <498FDC21.2080502@rollernet.us> References: <498FDC21.2080502@rollernet.us> Message-ID: <498FE21A.2000605@rollernet.us> Seth Mattinen wrote: > I hate to interrupt the IPv6 and RFC 1918 mega-threads... > > Does anyone know of a company that makes 208v (3-wire line-line ground, > no neutral, 208v loads only, single phase) 30-60 amp automatic transfer > switches with sub-30ms switching time? APC used to make the SU045X163 > 30A model, but it seems to have been discontinued and it's hard to find > products that support 208v single phase. > Ugh, of course I come across something (TwinSource DCC-II RM-ITSTS, 50A in a 4U case using SCRs) mere minutes after posting. Any other recommendations are still welcome. The TwinSource unit looks quite fascinating, although I'm guessing quite expensive. ~Seth From pekkas at netcore.fi Mon Feb 9 02:05:25 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 9 Feb 2009 10:05:25 +0200 (EET) Subject: IPv6 delivery model to end customers In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> Message-ID: On Sat, 7 Feb 2009, Mikael Abrahamsson wrote: > But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. > Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 > or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels > is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but > I don't like tunnels. I like native). Most of the ETTH ports are 10/10, > 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. > L2TPv3/PPPoE is not an option. I may be missing something. "only have ethernet and IP". Why is plain-ethernet with each subscriber provisioned in a separate router's vlan subinterface insufficient? There is no security issue because each subscriber only sees its own traffic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nonobvious at gmail.com Mon Feb 9 02:08:50 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 9 Feb 2009 00:08:50 -0800 Subject: Private use of non-RFC1918 IP space In-Reply-To: <498FDE5A.5000105@bogus.com> References: <16474135.451233684880488.JavaMail.zaid@turing-2.local> <10812089.471233685164238.JavaMail.zaid@turing-2.local> <483E6B0272B0284BA86D7596C40D29F984E82B67C3@PUR-EXCH07.ox.com> <498FDE5A.5000105@bogus.com> Message-ID: <18a5e7cb0902090008i380aad07p8ec8a5d15ccf6ff1@mail.gmail.com> On Sun, Feb 8, 2009 at 11:42 PM, Joel Jaeggli wrote: > FD00::/8 > > ula-l rfc 4139 s/4139/4193/ -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From swmike at swm.pp.se Mon Feb 9 02:20:41 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 9 Feb 2009 09:20:41 +0100 (CET) Subject: IPv6 delivery model to end customers In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> Message-ID: On Mon, 9 Feb 2009, Pekka Savola wrote: > I may be missing something. "only have ethernet and IP". Why is > plain-ethernet with each subscriber provisioned in a separate router's > vlan subinterface insufficient? There is no security issue because each > subscriber only sees its own traffic. It's rare that this is the way it's done. Most ETTH deployments I know use one of these deployment scenarios: 1. One vlan per customer (not so often) plus uRPF like behaviour. 2. Shared broadcast domain with L2 devices doing one or several of: 2.1 Forced forwarding towards router. 2.2 ARP inspection 2.3 DHCP server protection (stops customers from running DHCP server) 2.4 Spoofing filters by means of DHCP snooping (both L2 and L3) 2.5 STP root guard 2.6 MAC rewrite 2.7 Ethertype filtering Plus more I can't think of right now. It's scenario 2 I'm worried about, all those machanisms haven't been implemented for IPv6 as far as I know and if you're only doing 2.2-2.5 then you're open to the IPv6 security issue I described. -- Mikael Abrahamsson email: swmike at swm.pp.se From andy at nosignal.org Mon Feb 9 02:40:36 2009 From: andy at nosignal.org (Andy Davidson) Date: Mon, 9 Feb 2009 08:40:36 +0000 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <016f01c987f0$98865110$c992f330$@edu> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <20090205220614.GA18219@jeeves.rigozsaurus.com> <016f01c987f0$98865110$c992f330$@edu> Message-ID: <20090209084036.GB15596@chilli.nosignal.org> On Thu, Feb 05, 2009 at 07:19:37PM -0500, Robert D. Scott wrote: > Wii should not even consider developing " a cool new protocol for the Wii" > that is not NAT compliant via V4 or V6. And if they do, we should elect a > NANOG regular to go "POSTAL" and handle the problem. The solution to many of > these networking conundrums should rest with the application people, and NOT > the network people. You are wrong, there are lots of new ... and not so new ... protocols that *can* work via ALGs or other NAT traversal systems, but tend to work worse than if they'd had end to end visibility. The various VoIP protocols are the perfect example. The end to end principal is the lifeblood of innovation on the internet and we need to do everything we can to allow anyone who wants it to have it. Kind regards, Andy Davidson From andris at hpl.hp.com Mon Feb 9 02:44:06 2009 From: andris at hpl.hp.com (Andris Kalnozols) Date: Mon, 09 Feb 2009 0:44:06 PST Subject: Packet Loss between Qwest and Global Crossing In-Reply-To: <200902090659.WAA20506@nasdaq.hpl.hp.com>; from "Andris Kalnozols" at Feb 8, 109 11:01 pm Message-ID: <200902090844.AAA20659@nasdaq.hpl.hp.com> > This post to the NANOG list in the hope that an interested > engineer from either Qwest or GBLX will act on the problem > I have observed. > > I've identified a packet loss problem (10-15%) between Qwest > and Global Crossing. Thanks to whomever has fixed the problem. Packet loss is now zero and latency time is very much improved. ------ Andris From mohacsi at niif.hu Mon Feb 9 05:39:33 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 9 Feb 2009 12:39:33 +0100 (CET) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <20090209084036.GB15596@chilli.nosignal.org> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <20090205220614.GA18219@jeeves.rigozsaurus.com> <016f01c987f0$98865110$c992f330$@edu> <20090209084036.GB15596@chilli.nosignal.org> Message-ID: On Mon, 9 Feb 2009, Andy Davidson wrote: > On Thu, Feb 05, 2009 at 07:19:37PM -0500, Robert D. Scott wrote: >> Wii should not even consider developing " a cool new protocol for the Wii" >> that is not NAT compliant via V4 or V6. And if they do, we should elect a >> NANOG regular to go "POSTAL" and handle the problem. The solution to many of >> these networking conundrums should rest with the application people, and NOT >> the network people. > > You are wrong, there are lots of new ... and not so new ... protocols that > *can* work via ALGs or other NAT traversal systems, but tend to work worse > than if they'd had end to end visibility. The various VoIP protocols are > the perfect example. Example please! Kind Regards, Janos Mohacsi> From trejrco at gmail.com Mon Feb 9 07:54:00 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 08:54:00 -0500 Subject: v6 & DSL / Cable modems In-Reply-To: <20090207185134.GK5164@isc.org> References: <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <20090205235516.GD8174@isc.org> <76717384-CF2C-4B73-90EB-5FA0EC20D2B6@muada.com> <20090206.182230.74716370.sthaug@nethelp.no> <498C787F.1060007@brightok.net> <20090206181545.GE5164@isc.org> <498C9F6C.7050109@brightok.net> <20090206212954.GG5164@isc.org> <07EE8177-9A56-4C46-95D0-D718C85906E1@daork.net> <20090207185134.GK5164@isc.org> Message-ID: <001601c98abd$dd61b570$98252050$@com> >So far as I am aware, this is default behaviour only on certain versions of >Mac OSX, and must be explicitly enabled on all others. >Manually, on the console. RA does not dynamically distribute this >behaviour; the client has to choose it. Usually it is a sysctl or a >registry variable or the like. NIT: Add any IPv6 capable Windows "workstation" to that list (workstation meaning "not server" OS). Or any USAGI-derived 'nix kernel, AFAIK. (WinXP as described/expected, Vista with a twist (no EUI64 by default)) >The philosophies of design of these two systems are entirely at odds. While I agree with that statement, I disagree just a little bit with your supporting argument. On either case, the host is initiating the discussion and trying to do what it wants (either appending randomized IIDs or asking the DHCPv6 server to supply it with randomly generated IIDs, and using the results as "(a) temporary/privacy address(es)") ... in either case, if the hosts doesn't support it or doesn't ask, it doesn't happen. /TJ From rays at maine.edu Mon Feb 9 08:21:24 2009 From: rays at maine.edu (Soucy, Ray) Date: Mon, 9 Feb 2009 09:21:24 -0500 Subject: IPv6 delivery model to end customers In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> Message-ID: <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> > It's scenario 2 I'm worried about, all those machanisms haven't been > implemented for IPv6 as far as I know and if you're only doing 2.2-2.5 > then you're open to the IPv6 security issue I described. We've been seeing problems with this for the last year or so (since Vista started showing up). Since we run an academic network, we don't have as much control over hosts as you would see in a corporate setting. We've started poking Cisco about some key IPv6 support that we really need to move forward. A big one is a solution to address the security concerns with IPv6 RA (Router Advertisement) and rogue DHCPv6. On IPv4 networks we have the option of using DHCP snooping to suppress unauthorized DHCP servers from handing out address information. With IPv6, any host can announce itself as a router (using RA) and make network traffic suddenly start making use of it as the router for a network. This makes it possible for hosts to inadvertently disrupt network service (Vista) or even be used maliciously to perform a man-in-the-middle attack to intercept your traffic. Similarly with DHCPv6 there is nothing stopping a host from trying to hand out stateful IPv6 address configuration. Even worse is that since modern hosts give traffic priority to IPv6, it becomes easy for a rogue host (Vista) to advertise itself as an IPv6 router on IPv4-only networks. So there are security concerns even for networks that do not run IPv6 here. I think it goes without saying that this needs to be addressed before IPv6 can be deployed on most campus networks where users manage their own PC's. So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping). As far as IPv6 deployment to residential customers... I say most things these days are moving to Metro Ethernet. Give ea. customer a VLAN, that will save you a lot of headache and ultimately provide a better experience for the customer. Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From mailvortex at gmail.com Mon Feb 9 08:30:29 2009 From: mailvortex at gmail.com (Ben Scott) Date: Mon, 9 Feb 2009 09:30:29 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <1234059870.17985.294.camel@guardian.inconcepts.net> References: <1234059870.17985.294.camel@guardian.inconcepts.net> Message-ID: <59f980d60902090630l21e25748sd33f702617f7df8@mail.gmail.com> On Sat, Feb 7, 2009 at 9:24 PM, Jeff S Wheeler wrote: > Sure, smart phones are becoming more popular. My ancient and crufty Nextel iDEN i530 phone, manufactured circa 2003, with a monochrome 4-line text display, and about as "dumb" as they get, gets assigned an IP address. Now, that IP address is in 10/8, but the point is that not just "smart phones" get IP addresses. As to whether VZW needs public IP space for every phone -- I'll let others handle the rampant speculation on that front. -- Ben From mtinka at globaltransit.net Mon Feb 9 09:13:36 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 9 Feb 2009 23:13:36 +0800 Subject: IPv6 delivery model to end customers In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> References: <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> Message-ID: <200902092313.43688.mtinka@globaltransit.net> On Monday 09 February 2009 10:21:24 pm Soucy, Ray wrote: > So Cisco (and other vendors) needs to introduce two > things for LAN switching. DHCPv6 snooping, and more > importantly, RA suppression (or RA snooping). For IOS, have you tried the command: int gi0/1 ipv6 nd ra suppress Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From martin at theicelandguy.com Mon Feb 9 09:40:47 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Mon, 9 Feb 2009 10:40:47 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <200902090007.n1907qY2069724@drugs.dv.isc.org> References: <1234128761.17985.352.camel@guardian.inconcepts.net> <200902090007.n1907qY2069724@drugs.dv.isc.org> Message-ID: On Sun, Feb 8, 2009 at 7:07 PM, Mark Andrews wrote: > > In message <1234128761.17985.352.camel at guardian.inconcepts.net>, Jeff S > Wheeler > writes: > > On Sun, 2009-02-08 at 14:37 -0800, Aaron Glenn wrote: > > > NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? > > > there should be a FOIA-like method to see large > > > allocation justifications > > Realistically, I suppose Verizon Wireless is big enough to dictate to > > the manufacturers of handsets and infrastructure, "you must support IPv6 > > by X date or we will no longer buy / sell your product." I wonder if > > any wireless carriers are doing this today? > > > > What services require an IP, whether they can be supplied via NAT, how > > soon "smart phone" adoption will bring IP to every handset ... all these > > are good and valid points. However, they all distract from the glaring > > and obvious reality that there is no current explanation for Verizon > > Wireless needing 27M IPs. > > Well it's a 8M allocation for current population of 2M with > a 25M more potential handsets that will be upgraded soon. > This looks to be consistent with how ARIN hands out other > blocks of address space. Plus the rest of their space, at least the easily identifiable portions. It's extremely difficult to speculate what people are doing with large amounts of addresses. I trust that ARIN has done the right thing in accordance with community standards. V6 addresses included. They may want to not recycle that template containing the comment again. It showed up on the last two allocations. Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-66-174-0-0-1 ) 66.174.0.0 - 66.174.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-69-82-0-0-1 ) 69.82.0.0 - 69.83.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-69-96-0-0-1 ) 69.96.0.0 - 69.103.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-70-192-0-0-1 ) 70.192.0.0 - 70.223.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET6-2001-4888-1 ) 2001:4888:0000:0000:0000:0000:0000:0000 - 2001:4888:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-97-128-0-0-1 ) 97.128.0.0 - 97.255.255.255 Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK (NET-174-192-0-0-1 ) 174.192.0.0 - 174.255.255.255 Best, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From rays at maine.edu Mon Feb 9 09:54:41 2009 From: rays at maine.edu (Soucy, Ray) Date: Mon, 9 Feb 2009 10:54:41 -0500 Subject: FW: IPv6 delivery model to end customers Message-ID: <36243D984F88BA4ABD1E0EFC1E61B989652612@fudd.ad.maine.edu> > For IOS, have you tried the command: > > int gi0/1 > ipv6 nd ra suppress I think this only applies to RA originating from the L3 interface in question... not an L2 interface. I could be mistaken. I'll have to poke at it. From mtinka at globaltransit.net Mon Feb 9 10:08:50 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 10 Feb 2009 00:08:50 +0800 Subject: FW: IPv6 delivery model to end customers In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B989652612@fudd.ad.maine.edu> References: <36243D984F88BA4ABD1E0EFC1E61B989652612@fudd.ad.maine.edu> Message-ID: <200902100008.57671.mtinka@globaltransit.net> On Monday 09 February 2009 11:54:41 pm Soucy, Ray wrote: > I think this only applies to RA originating from the L3 > interface in question... not an L2 interface. Quite right, indeed. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From dholmes at mwdh2o.com Mon Feb 9 11:31:53 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 9 Feb 2009 09:31:53 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <498FCF71.9030807@he.net> References: <1234128761.17985.352.camel@guardian.inconcepts.net> <200902090007.n1907qY2069724@drugs.dv.isc.org> <18f601940902081937u7e71244ai430612b4044a5fdf@mail.gmail.com><886FB5BA-FAF7-40FE-BF2E-C8E81E7AD853@virtualized.org> <498FCF71.9030807@he.net> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E085D1E10@usmsxt104.mwd.h2o> We're not a big verizon wireless customer, (we have been allocated a /25 for remote data access devices). We run multi-homed BGP with vw. vw says that they must advertise 48 summarized prefixes to us, instead of just the /25. The 48 prefixes are apparently advertised to all of the de-aggregated users contained in the summarized 48 prefixes. Is this a common practice? If so is it a best practice? -----Original Message----- From: Mike Leber [mailto:mleber at he.net] Sent: Sunday, February 08, 2009 10:39 PM To: David Conrad Cc: nanog at nanog.org Subject: Re: 97.128.0.0/9 allocation to verizon wireless David Conrad wrote: > On Feb 8, 2009, at 7:37 PM, Aaron Glenn wrote: >> so if they don't deploy IPv6 then ('extremely high growth period'), >> when will they? > > Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled? haha, I went insane for a moment and though you said Freenix top 1000, and so I just checked that. Here is the answer to the question you didn't ask: Top 1000 Usenet Servers in the World list here: http://news.anthologeek.net/top1000.current.txt details here: http://news.anthologeek.net 1000 usenet server names 913 are potentially valid hostnames (in usenet news a server name does necessarily correspond directly to a hostname) 722 have ipv4 address records (A) 67 have ipv6 address records (AAAA) 9.2% of the top 1000 usenet servers have added support for ipv6 I'm sure there are more this took exactly 183 seconds of work. ;) Here they are: feeder.erje.net 2001:470:992a::3e19:561 feeder4.cambrium.nl 2a02:58:3:119::4:1 news.dal.ca 2001:410:a010:1:214:5eff:fe0a:4a4e news.nonexiste.net 2002:6009:93d5::1 nrc-news.nrc.ca 2001:410:9000:2::2 news.z74.net 2001:610:637:4::211 news.kjsl.com 2001:1868:204::104 npeer.de.kpn-eurorings.net 2001:680:0:26::2 feeder6.cambrium.nl 2a02:58:3:119::6:1 feeder3.cambrium.nl 2a02:58:3:119::3:1 news.belnet.be 2001:6a8:3c80::38 feeder2.cambrium.nl 2a02:58:3:119::2:1 feeder5.cambrium.nl 2a02:58:3:119::5:1 syros.belnet.be 2001:6a8:3c80::17 vlad-tepes.bofh.it 2001:1418:13:1::5 news.stack.nl 2001:610:1108:5011:230:48ff:fe12:2794 ikarus.belnet.be 2001:6a8:3c80::38 news.space.net 2001:608::1000:7 feed.news.tnib.de 2001:1b18:f:4::4 newsfeed.velia.net 2a01:7a0:3::254 news.isoc.lu 2001:a18:0:405:0:a0:456:1 ikaria.belnet.be 2001:6a8:3c80::39 newsfeed.teleport-iabg.de 2001:1b10:100::119:1 news.tnib.de 2001:1b18:f:4::2 kanaga.switch.ch 2001:620:0:8::119:2 erode.bofh.it 2001:1418:13:1::3 irazu.switch.ch 2001:620:0:8::119:3 bofh.it 2001:1418:13::42 newsfeed.atman.pl 2001:1a68:0:4::2 news.mb-net.net 2a01:198:292:0:210:dcff:fe67:6b03 news.gnuher.de 2a01:198:293::2 switch.ch 2001:620:0:1b::b news.k-dsl.de 2a02:7a0:1::5 news.task.gda.pl 2001:4070:1::fafe news1.tnib.de 2001:1b18:f:4::2 aspen.stu.neva.ru 2001:b08:2:100::96 novso.com 2001:1668:2102:4::4 citadel.nobulus.com 2001:6f8:892:6ff::11:133 feeder.news.heanet.ie 2001:770:18:2::c101:db29 news-zh.switch.ch 2001:620:0:3::119:1 news.szn.dk 2001:1448:89::10:d85d news.litech.org 2001:440:fff9:100:202:b3ff:fea4:a44e news.weisnix.org 2001:6f8:892:6ff:213:8fff:febb:bec3 news.panservice.it 2001:40d0:0:4000::e nntp.eutelia.it 2001:750:2:3::20 bolzen.all.de 2001:bf0::60 newsfeed.esat.net 2001:7c8:3:1::3 news.snarked.org 2607:f350:1::1:4 feed1.news.be.easynet.net 2001:6f8:200:2::5:46 aotearoa.belnet.be 2001:6a8:3c80::58 news.babsi.de 2a01:198:292:0:230:48ff:fe51:a68c news.muc.de 2001:608:1000::2 newsfeed.carnet.hr 2001:b68:e160::3 news.nask.pl 2001:a10:1:ffff::3:c9a2 news.linuxfan.it 2001:4c90:2::6 texta.sil.at 2001:858:2:1::2 news.stupi.se 2001:440:1880:5::10 news.supermedia.pl 2001:4c30:0:3::12 news.trigofacile.com 2001:41d0:1:6d44::1 nuzba.szn.dk 2001:6f8:1232::263:8546 geiz-ist-geil.priv.at 2001:858:666:f001::57 newsfeed.sunet.se 2001:6b0:7:88::101 news.pimp.lart.info 2001:6f8:9ed::1 glou.fr.eu.org 2001:838:30b::1 news.germany.com 2001:4068:101:119:1::77 feeder.z74.net 2001:610:637:4::211 news.nask.org.pl 2001:a10:1:ffff::3:c9a2 Mike. -- +---------------- H U R R I C A N E - E L E C T R I C ----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric AS6939 | | mleber at he.net Internet Backbone & Colocation http://he.net | +---------------------------------------------------------------------+ From andy at nosignal.org Mon Feb 9 11:46:05 2009 From: andy at nosignal.org (Andy Davidson) Date: Mon, 9 Feb 2009 17:46:05 +0000 Subject: One /22 Two ISP no BGP In-Reply-To: <498C7DBA.5040607@ttec.com> References: <2E2FECEBAE57CC4BAACDE67638305F10482E5B4F66@ROCH-EXCH1.corp.pvt> <498C7DBA.5040607@ttec.com> Message-ID: <20090209174605.GB10445@chilli.nosignal.org> On Fri, Feb 06, 2009 at 01:13:14PM -0500, Joe Maimon wrote: > Perhaps ebgp-multihop with this ISP's upstream provider might offer you > an advantage combined with this approach. This is quite neat, but the ISP may be multihomed and support BGP at one edge (several transits, several peers), but not at their customer facing edge. Andy From davet1 at gmail.com Mon Feb 9 11:49:18 2009 From: davet1 at gmail.com (Dave Temkin) Date: Mon, 09 Feb 2009 09:49:18 -0800 Subject: Packet Loss between Qwest and Global Crossing In-Reply-To: <200902090844.AAA20659@nasdaq.hpl.hp.com> References: <200902090844.AAA20659@nasdaq.hpl.hp.com> Message-ID: <49906C9E.8030803@gmail.com> This has been a recurring problem, especially in the Bay Area - and it seems as though neither side really cares all that much. -Dave Andris Kalnozols wrote: >> This post to the NANOG list in the hope that an interested >> engineer from either Qwest or GBLX will act on the problem >> I have observed. >> >> I've identified a packet loss problem (10-15%) between Qwest >> and Global Crossing. >> > > Thanks to whomever has fixed the problem. Packet loss is now > zero and latency time is very much improved. > > ------ > Andris > > From mormis at caro.net Mon Feb 9 12:37:17 2009 From: mormis at caro.net (Morgan Miskell) Date: Mon, 09 Feb 2009 13:37:17 -0500 Subject: Packet Loss between Qwest and Global Crossing In-Reply-To: <49906C9E.8030803@gmail.com> References: <200902090844.AAA20659@nasdaq.hpl.hp.com> <49906C9E.8030803@gmail.com> Message-ID: <1234204637.10351.22.camel@mormis.caro.net> Oddly enough, we've got a few customers that are on Qwest network on the east coast and we see packet loss in the same range to them, we've tested origination packets from 6-7 networks. The customer has reported it and the issue has been ongoing for at least a week or two, but so far nothing has been done... On Mon, 2009-02-09 at 09:49 -0800, Dave Temkin wrote: > This has been a recurring problem, especially in the Bay Area - and it > seems as though neither side really cares all that much. > > -Dave > > Andris Kalnozols wrote: > >> This post to the NANOG list in the hope that an interested > >> engineer from either Qwest or GBLX will act on the problem > >> I have observed. > >> > >> I've identified a packet loss problem (10-15%) between Qwest > >> and Global Crossing. > >> > > > > Thanks to whomever has fixed the problem. Packet loss is now > > zero and latency time is very much improved. > > > > ------ > > Andris > > > > > -- Morgan A. Miskell Carolina Internet 704-643-8330 x206 ---------------------------------------------------------------------------- The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ---------------------------------------------------------------------------- From trejrco at gmail.com Mon Feb 9 12:58:43 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 13:58:43 -0500 Subject: IPv6 delivery model to end customers In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> Message-ID: <00d801c98ae8$6e4214c0$4ac63e40$@com> >A big one is a solution to address the security concerns with IPv6 RA >(Router Advertisement) and rogue DHCPv6. On IPv4 networks we have the option >of using DHCP snooping to suppress unauthorized DHCP servers from handing >out address information. With IPv6, any host can announce itself as a router >(using RA) and make network traffic suddenly start making use of it as the >router for a network. This makes it possible for hosts to inadvertently >disrupt network service (Vista) or even be used maliciously to perform a >man-in-the-middle attack to intercept your traffic. Similarly with DHCPv6 >there is nothing stopping a host from trying to hand out stateful IPv6 >address configuration. > >Even worse is that since modern hosts give traffic priority to IPv6, it >becomes easy for a rogue host (Vista) to advertise itself as an IPv6 router >on IPv4-only networks. So there are security concerns even for networks that >do not run IPv6 here. > >I think it goes without saying that this needs to be addressed before >IPv6 can be deployed on most campus networks where users manage their own >PC's. > >So Cisco (and other vendors) needs to introduce two things for LAN >switching. DHCPv6 snooping, and more importantly, RA suppression (or RA >snooping). Indeed, this is a problem. RA Guard is a very straight-forward, hopefully soon-to-be-widely-supported, defense. http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 A "pure layer 3" solution is, of course, SEND/CGA ... where deployment concerns/problems abound ... http://tools.ietf.org/html/rfc3971 & http://tools.ietf.org/html/rfc3972 And as I may have said once or thrice already, YES - I agree these solutions should have been developed / made deployable long before now. >As far as IPv6 deployment to residential customers... I say most things >these days are moving to Metro Ethernet. Give ea. customer a VLAN, that >will save you a lot of headache and ultimately provide a better experience >for the customer. Amen to that ... From trejrco at gmail.com Mon Feb 9 12:59:52 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 13:59:52 -0500 Subject: IPv6 delivery model to end customers In-Reply-To: <200902092313.43688.mtinka@globaltransit.net> References: <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> <200902092313.43688.mtinka@globaltransit.net> Message-ID: <00dc01c98ae8$97787730$c6696590$@com> >> So Cisco (and other vendors) needs to introduce two things for LAN >> switching. DHCPv6 snooping, and more importantly, RA suppression (or >> RA snooping). > >For IOS, have you tried the command: > >int gi0/1 > ipv6 nd ra suppress > That stops your router from sending any RAs. Does nothing to prevent someone else from sending them, and becoming the default gateway for every IPv6 capable host on that link ... From rays at maine.edu Mon Feb 9 13:29:09 2009 From: rays at maine.edu (Soucy, Ray) Date: Mon, 9 Feb 2009 14:29:09 -0500 Subject: IPv6 delivery model to end customers In-Reply-To: <00d801c98ae8$6e4214c0$4ac63e40$@com> References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> <00d801c98ae8$6e4214c0$4ac63e40$@com> Message-ID: <36243D984F88BA4ABD1E0EFC1E61B98965263E@fudd.ad.maine.edu> > Indeed, this is a problem. > RA Guard is a very straight-forward, hopefully soon-to-be-widely-supported, > defense. > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 Thanks for pointing us to this. It's encouraging to know that it is being worked on. Ray From jfbeam at gmail.com Mon Feb 9 16:01:25 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 09 Feb 2009 17:01:25 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> Message-ID: On Fri, 06 Feb 2009 22:32:10 -0500, Owen DeLong wrote: > IPTables is decent firewall code. Not really. It's quite complicated for a non-engineer type to manage. Think of all the unpatched windows xp/vista users of the world. > It's free. ... > Further, since more and more CPE is being built on embedded linux, > there's no reason > that IPTables isn't a perfectly valid approach to the underlying > firewall code. No. It's not. While you might not be paying anyone for the software, it does come with some significant costs... a moderately powerful processor and a lot of memory. Ah, "but both are cheap these days, and getting cheaper", you say. Tell me where I can get 500MHz+ processors and 16+ MB of ram for "pennies". Case in point... (in case you missed it) Linksys stopped using Linux on their popular WRT54G line years ago in favor of vxWorks because it took less resources and therefor meant they could use less memory (flash and ram) and save money despite paying a license fee for vxWorks. (They still use vxWorks on the 54g, but have used linux on their newer (much more expensive) hardware.) DSL and cable modems are extremely simple devices. I'm amazed they have any amount of "router" in them at all. And I've yet to see one running Linux. (the 2 popular brands around here -- westell and motorola -- run vxworks.) --Ricky From jfbeam at gmail.com Mon Feb 9 16:11:25 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 09 Feb 2009 17:11:25 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <498DE1AD.1000807@sprunk.org> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> Message-ID: On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk wrote: > Non-NAT firewalls do have some appeal, because they don't need to mangle > the packets, just passively observe them and open pinholes when > appropriate. This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null. In the case of NAT, the "helper" has to understand the protocol to know what traffic to map. In the case of a stateful firewalling ("non-NAT"), the "helper" has to understand the protocol to know what traffic to allow. Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.) --Ricky From jbates at brightok.net Mon Feb 9 16:32:56 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 09 Feb 2009 16:32:56 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> Message-ID: <4990AF18.1020101@brightok.net> Ricky Beam wrote: > On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk > wrote: >> Non-NAT firewalls do have some appeal, because they don't need to mangle >> the packets, just passively observe them and open pinholes when >> appropriate. > > This is exactly the same with NAT and non-NAT -- making any anti-NAT > arguments null. Actually, it's worlds different. > In the case of a stateful firewalling ("non-NAT"), the "helper" has to > understand the protocol to know what traffic to allow. This is not completely true. Technologies such as uPNP can quickly open up a pinhole for traffic which needs to be initiated from the far end, but no address rewriting is necessary by the software (embedded in the protocol) or the firewall. For non-UDP/TCP packets, ports have no meaning, which is the biggest failing of NAT (since we are talking about overloading on one IP here, and not 1 to 1 translations). Firewall rules for packets that are not UDP/TCP usually allow the return traffic based on source and destination IP and IP protocol number. NAT, on the other hand can't do it. We have to make udp/tcp tunnels to carry the traffic through NAT instead. > Subtle difference, but in the end, the same thing... if your gateway > doesn't know what you are doing, odds are it will interfere with it. In > all cases, end-to-end transparency doesn't exist. (as has been the case > for well over a decade.) End-to-end addressing does exist, though. There are cases that are straight forward that NAT breaks without adding extra tunneling layers, or without either NAT or the software having to rewrite an embedded IP address in a packet to the public address. Sure, stateful firewalls can still block traffic and break certain scenarios without the assistance of uPNP(or application layer analysis). They will be simpler, and break less (we'd hope simpler means less). It's one thing to communicate with your firewall to dynamically open up ports for your address. It's another to start rewriting packets, analyzing specific protocols so that you can alter them. Feel free to disagree with me on all except non-TCP/UDP breakage. I've had too many support calls on that one, and NAT-T isn't always available, and even when available, it's not necessarily configurable. Jack From scott at doc.net.au Mon Feb 9 16:35:10 2009 From: scott at doc.net.au (Scott Howard) Date: Mon, 9 Feb 2009 14:35:10 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] Message-ID: On Sat, Feb 7, 2009 at 5:56 PM, Matthew Moyle-Croft wrote: > My issue is that customers have indicated that they feel statics are a > given for IPv6 and this would be a problem if I went from tens of thousands > of statics to hundreds of thousands of static routes (ie. from a minority to > all). Even injecting statics into But is this a general requirement, or just one from the types of people that are likely to be early adopters for IPv6? Go and ask those people who "feel statics are a given for IPv6" if they would prefer static or dynamic IPv4 addresses, and I suspect most/all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I don't see static for IPv6 as any more (or less?) of an operational requirement than for IPv4. Certain users will definitely require static address, just as they do for IPv4, and IMHO these should be handled in exactly the same way - the exact mechanism for which will vary from ISP to ISP. Scott. From nanog at daork.net Mon Feb 9 16:39:54 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 10 Feb 2009 11:39:54 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: Message-ID: On 10/02/2009, at 11:35 AM, Scott Howard wrote: > Go and ask those people who "feel statics are a given for IPv6" if > they > would prefer static or dynamic IPv4 addresses, and I suspect most/ > all of > them will want the static there too. Now ask your average user the > same > question and see if you get the same answer. I imagine there will be a difference - in my experience few people understand the automatic renumbering that you can do with IPv6, so think that static addressing is the only way forward. With IPv4 this is not an issue, as they do not re-number internal interfaces when their external IPv4 address changes. -- Nathan Ward From owen at delong.com Mon Feb 9 16:44:45 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Feb 2009 14:44:45 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> Message-ID: <5256BCAD-A670-4D40-9074-FABCBA6CE3EF@delong.com> On Feb 9, 2009, at 2:11 PM, Ricky Beam wrote: > On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk > wrote: >> Non-NAT firewalls do have some appeal, because they don't need to >> mangle >> the packets, just passively observe them and open pinholes when >> appropriate. > > This is exactly the same with NAT and non-NAT -- making any anti-NAT > arguments null. > And making the PRO-NAT arguments in this respect equally NULL. This was being touted as a benefit of NAT, not a reason not to do NAT. Your statement proves my point... It is NOT a reason to do NAT or a benefit derived from NAT. > In the case of NAT, the "helper" has to understand the protocol to > know what traffic to map. > > In the case of a stateful firewalling ("non-NAT"), the "helper" has > to understand the protocol to know what traffic to allow. > > Subtle difference, but in the end, the same thing... if your gateway > doesn't know what you are doing, odds are it will interfere with > it. In all cases, end-to-end transparency doesn't exist. (as has > been the case for well over a decade.) Right. This is the counterpoint to the argument that NAT is needed. You have now agreed that it is not. Owen From jfbeam at gmail.com Mon Feb 9 17:16:28 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 09 Feb 2009 18:16:28 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> Message-ID: On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum wrote: >> If you want the machine to always have the same address, either enter >> it manually or set your DHCP server to always give it the same address. > > Manual configuration doesn't scale. With IPv4, it's quite hard to make > this work with DHCP, but mostly because of a lack of IPv4 addresses. > With IPv6 it's easier, but you're still limiting the uptime of your > system to that of the DHCPv6 server. Router advertisements is much more > robust. As I read it, you don't want to use DHCP because "it's an other service to fail." Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task. My point is simply, this whole mess with RA's should never have been on the table. DHCP has been around and used for years to provide IPv4 hosts with an address, gateway, and MANY other configuration options. It exists because (in many cases) hosts need more than just an address. Yet the protocol designers, staunch haters of DHCP, refused to see any value in DHCP for IPv6 and rolled back the clock 3 decades dooming us ALL to repeating the same bull. DHCPv6 can do everything SLAAC can plus infintely more. And an "it just works" configurationless setup could have been part of the standard instead; yet here we are... nobody 100% happy and a considerable amount of work being poured into reinventing the DHCP wheel. Manual static configuration is indeed a pain. That's why we have DHCP... set aside a range of addresses for machines that can move around (client workstations, etc.) and a pool of persistant addresses for servers, printers, etc. that you want to stay in one place -- some applications record addresses instead of names, *sigh*. Everything is in one, easy to manage location. For an ISP where a lot necessarily has to be manually configured, it can be more work, but is still simple -- even in the days of the "NOC NOTEBOOK" where only one person could be assigning addresses at a time. (we've had web based stuff for years now; feed rwhois directly, 'tho not automatic.) > Isn't remembering stuff what we have computers for? If you aren't accessing machines by number, why do you care if it always has the same number? As long as the name always maps to the right number, it doesn't matter. > I have a lot of problems with DHCP and most people don't _need_ it. > Still, very many people _want_ it and some people do in fact need it. I > have no problem with that, as long as it doesn't lead to the situation > where I have to run it. And I, likewise, don't want the utterly useless "RA" forced on my networks. Hosts need much more than just a unique address. And I don't want to have to walk around to every one of them to change anything. --Ricky From mike at mtcc.com Mon Feb 9 17:18:14 2009 From: mike at mtcc.com (Michael Thomas) Date: Mon, 09 Feb 2009 15:18:14 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: Message-ID: <4990B9B6.7060706@mtcc.com> Nathan Ward wrote: > On 10/02/2009, at 11:35 AM, Scott Howard wrote: > >> Go and ask those people who "feel statics are a given for IPv6" if they >> would prefer static or dynamic IPv4 addresses, and I suspect most/all of >> them will want the static there too. Now ask your average user the same >> question and see if you get the same answer. > > > I imagine there will be a difference - in my experience few people > understand the automatic renumbering that you can do with IPv6, so think > that static addressing is the only way forward. > > With IPv4 this is not an issue, as they do not re-number internal > interfaces when their external IPv4 address changes. I wonder how much this is all going to change as there's an inevitable shift from "my computer" being The Client, to "my computer" being one of many "servers" that my cell phone uses, and is generally tethered to. Or just the situation that you have more than one place of residence and there is a somewhat indeterminate concept of what "my computer" really is. This is somewhat reminiscent of the pop/imap days, but there's just so much more stuff these days and broadband is still way too slow to really have a completely viable network/server solution. Fast servers in the network are great, but there are is a fairly large set of things that it just doesn't handle well; manifestly given the still huge split between local and network storage. (what percentage of "stuff" is in the cloud? 1%?) To me, that says that more and more people are going to want to access their "home computer" as if it were a server... which in fact it really is in the case of an iPhone wanting to suck down the latest dross from iTunes. And server means non-client accessiblity however you accomplish that. Mike From stephen at sprunk.org Mon Feb 9 17:24:51 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 09 Feb 2009 17:24:51 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> Message-ID: <4990BB43.8020909@sprunk.org> Ricky Beam wrote: > On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk > wrote: >> Non-NAT firewalls do have some appeal, because they don't need to >> mangle the packets, just passively observe them and open pinholes >> when appropriate. > > This is exactly the same with NAT and non-NAT -- making any anti-NAT > arguments null. > > In the case of NAT, the "helper" has to understand the protocol to > know what traffic to map. > > In the case of a stateful firewalling ("non-NAT"), the "helper" has to > understand the protocol to know what traffic to allow. > > Subtle difference, but in the end, the same thing... if your gateway > doesn't know what you are doing, odds are it will interfere with it. > In all cases, end-to-end transparency doesn't exist. (as has been the > case for well over a decade.) Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. This mangling can be a serious source of problems. With UDP, it can introduce checksum errors. With TCP, not only do you have possible checksum errors, you also have to mangle the sequence numbers in both directions if the length of the payload changes. The mangling will inherently break standard IPsec and other "shim" layers like HIP. And let's not forget that NAT makes widespread deployment of any L4 alternative to TCP and UDP (e.g. SCTP) virtually impossible, forcing every new transport or shim protocol to inefficiently ride on top of TCP or UDP... Some protocols, e.g. SIP/RTP, also work fine through a stateful firewall even without an ALG in most cases -- but not when you add in NAT. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From newton at internode.com.au Mon Feb 9 17:33:41 2009 From: newton at internode.com.au (Mark Newton) Date: Tue, 10 Feb 2009 10:03:41 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <4990BB43.8020909@sprunk.org> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> <4990BB43.8020909@sprunk.org> Message-ID: On 10/02/2009, at 9:54 AM, Stephen Sprunk wrote: > > Yes, an ALG needs to understand the packet format to open pinholes > -- but with NAT, it also needs to mangle the packets. A non-NAT > firewall just examines the packets and then passes them on unmangled. Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the "inside" and "outside" addresses happen to be the same. If I was a commodity consumer hardware manufacturer, that's how I'd handle the IPv6 firewalling problem, because that'd let me pass non-NAT'ed v6 packets and NAT'ed v4 packets through the same code paths, thereby enabling me to avoid reinventing the entire wheel (and an entire new set of bugs) to do v6 firewalling. DSL/Cable CPE is already full of v4 ALGs, and it's reasonable to expect that the only difference between those and the equivalent v6 ALGs will be the lack of v6 NAT. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From owen at delong.com Mon Feb 9 17:47:11 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Feb 2009 15:47:11 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> <4990BB43.8020909@sprunk.org> Message-ID: <1BCDE3F8-440B-4D2B-9BF1-D4AE5DBF7952@delong.com> On Feb 9, 2009, at 3:33 PM, Mark Newton wrote: > > On 10/02/2009, at 9:54 AM, Stephen Sprunk wrote: >> >> Yes, an ALG needs to understand the packet format to open pinholes >> -- but with NAT, it also needs to mangle the packets. A non-NAT >> firewall just examines the packets and then passes them on unmangled. > > Sure, but at the end of the day a non-NAT firewall is just a special > case > of NAT firewall where the "inside" and "outside" addresses happen to > be the same. Uh, that's a pretty twisted view. I would say that NAT is a special additional capability of the firewall which mangles the address(es) in the packet. I would not regard passing the address unmangled as a "special case" of mangling. In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. Owen From newton at internode.com.au Mon Feb 9 17:58:47 2009 From: newton at internode.com.au (Mark Newton) Date: Tue, 10 Feb 2009 10:28:47 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <1BCDE3F8-440B-4D2B-9BF1-D4AE5DBF7952@delong.com> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> <4990BB43.8020909@sprunk.org> <1BCDE3F8-440B-4D2B-9BF1-D4AE5DBF7952@delong.com> Message-ID: On 10/02/2009, at 10:17 AM, Owen DeLong wrote: >> >> Sure, but at the end of the day a non-NAT firewall is just a >> special case >> of NAT firewall where the "inside" and "outside" addresses happen to >> be the same. > > Uh, that's a pretty twisted view. I would say that NAT is a special > additional capability of the firewall which mangles the address(es) > in the packet. I would not regard passing the address unmangled > as a "special case" of mangling. You're passing a value judgement on NAT, using loaded terms like "mangling" and "twisted". Fine, you don't like rewriting L3 addresses and L4 port numbers. Yep, I get that. Relevance? > In terms of implementing the code, sure, the result is about the same, > but, the key point here is that there really isn't a benefit to > having that > packet mangling code in IPv6. There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From matthew at eeph.com Mon Feb 9 18:00:12 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Mon, 09 Feb 2009 16:00:12 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <1BCDE3F8-440B-4D2B-9BF1-D4AE5DBF7952@delong.com> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> <4990BB43.8020909@sprunk.org> <1BCDE3F8-440B-4D2B-9BF1-D4AE5DBF7952@delong.com> Message-ID: <4990C38C.8060007@eeph.com> Owen DeLong wrote: > In terms of implementing the code, sure, the result is about the same, > but, the key point here is that there really isn't a benefit to having that > packet mangling code in IPv6. Unless your SOX auditor requires it in order to give you a non-qualified audit of your infrastructure. The real problem with IPv6 deployment is not that it can't be done, but that there are so many still-to-be-answered questions between here and there... Matthew Kaufman From Mark_Andrews at isc.org Mon Feb 9 18:22:58 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue, 10 Feb 2009 11:22:58 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Mon, 09 Feb 2009 16:00:12 -0800." <4990C38C.8060007@eeph.com> Message-ID: <200902100022.n1A0MwTc027903@drugs.dv.isc.org> In message <4990C38C.8060007 at eeph.com>, Matthew Kaufman writes: > Owen DeLong wrote: > > In terms of implementing the code, sure, the result is about the same, > > but, the key point here is that there really isn't a benefit to having that > > packet mangling code in IPv6. > > Unless your SOX auditor requires it in order to give you a non-qualified > audit of your infrastructure. The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. > The real problem with IPv6 deployment is not that it can't be done, but > that there are so many still-to-be-answered questions between here and > there... And the only way to answer them is to go ahead and find the gaps. Waiting and waiting won't find the problems and will just put you under more time presure. Mark > Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From jbates at brightok.net Mon Feb 9 18:33:54 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 09 Feb 2009 18:33:54 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> <4990BB43.8020909@sprunk.org> <1BCDE3F8-440B-4D2B-9BF1-D4AE5DBF7952@delong.com> Message-ID: <4990CB72.6090205@brightok.net> Mark Newton wrote: > Fine, you don't like rewriting L3 addresses and L4 port numbers. Yep, > I get that. Relevance? > Just out of what I like and might use, GRE (no port), ESP (no port), AH (no port), SCTP (would probably work fine with NAT, but I haven't seen it supported yet and because every box doing address rewrites MUST understand the protocol to perform NAT, it's likely to be back shelved despite it's cool features. Without NAT, it can be treated like GRE, ESP, and AH by a firewall, though improved security if the firewall does understand the protocol). And my favorite, 6-to-4, broken. > There is if you have a dual-stack device, your L4-and-above protocols > are the same under v4 and v6, and you don't want to reinvent the ALG wheel. ALG only fixes some problems, and it's not required for as much when address translations are not being performed. In addition, the bugs caused from address rewrites (and there have been some really poor implementations at the cheap home router level) will naturally disappear (to be replaced with new bugs concerning ALG/uPNP I'm sure). Jack From newton at internode.com.au Mon Feb 9 18:39:52 2009 From: newton at internode.com.au (Mark Newton) Date: Tue, 10 Feb 2009 11:09:52 +1030 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <4990CB72.6090205@brightok.net> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> <4990BB43.8020909@sprunk.org> <1BCDE3F8-440B-4D2B-9BF1-D4AE5DBF7952@delong.com> <4990CB72.6090205@brightok.net> Message-ID: <0619DF3C-5FD7-439A-8EB6-1A481A967411@internode.com.au> On 10/02/2009, at 11:03 AM, Jack Bates wrote: >> >> There is if you have a dual-stack device, your L4-and-above protocols >> are the same under v4 and v6, and you don't want to reinvent the >> ALG wheel. > > ALG only fixes some problems, and it's not required for as much when > address translations are not being performed. On a commodity consumer CPE device, the ALG code doubles as a stateful inspection engine. So it _is_ required when address translations are not being performed. Is security something that gets thought about now, or post-deployment? - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From jbates at brightok.net Mon Feb 9 19:00:17 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 09 Feb 2009 19:00:17 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <0619DF3C-5FD7-439A-8EB6-1A481A967411@internode.com.au> References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> <4990BB43.8020909@sprunk.org> <1BCDE3F8-440B-4D2B-9BF1-D4AE5DBF7952@delong.com> <4990CB72.6090205@brightok.net> <0619DF3C-5FD7-439A-8EB6-1A481A967411@internode.com.au> Message-ID: <4990D1A1.9080309@brightok.net> Mark Newton wrote: > On a commodity consumer CPE device, the ALG code doubles as a > stateful inspection engine. > > So it _is_ required when address translations are not being performed. > Hmmmm, the code may be there, but I suspect that not all of it will apply to v6 and be used. > Is security something that gets thought about now, or post-deployment? I suspect that depends on who you ask. Security is always the top of my list. That being said, what security is there in removing NAT from v4 because it broke what the customer wanted to do? Then they are back to their host based stateful firewall; which apparently everyone believes is not good enough. Might as well throw in v6 and trash the NAT. Jack From lionair at samsung.com Mon Feb 9 19:29:44 2009 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Tue, 10 Feb 2009 01:29:44 +0000 (GMT) Subject: Network equipments process utilization Message-ID: <10715296.143051234229384202.JavaMail.weblogic@epml04> Hi everyone, I wonder which percentage is good level of CPU and Memory util of network equipment ? In my case, I try to keep under 30% cpu util and 70% memory util. My most equipment are Cisco product. I have no technical reference about that, it is just a rule of mine or my predecessor. Could you tell me how other operators are doing ? what is your operation baseline ? or is there any guideline about process utilization ? Best regards, Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= From trejrco at gmail.com Mon Feb 9 20:11:50 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 21:11:50 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> Message-ID: <00cf01c98b24$efe42680$cfac7380$@com> >As I read it, you don't want to use DHCP because "it's an other service to >fail." Well, what do you think is broadcasting RA's? My DHCP servers have >proven far more stable than my routers. (and one of them is a windows server >:-)) Most dhcp clients that keep any state will continue using the >previously assigned address if the server is unavailable (and nothing else >is using it.) Configuring a static address in a DHCP server is a pretty >trivial task. Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router? ... which would work the same way in an IPv6 scenario ... with the host knowing it's address for a period of time (Valid timer), and learning a new gateway in fairly short order (even sans FHRP). >My point is simply, this whole mess with RA's should never have been on the >table. DHCP has been around and used for years to provide IPv4 hosts with >an address, gateway, and MANY other configuration options. It exists >because (in many cases) hosts need more than just an address. Yet the >protocol designers, staunch haters of DHCP, refused to see any value in DHCP >for IPv6 and rolled back the clock 3 decades dooming us ALL to repeating the >same bull. DHCPv6 can do everything SLAAC can plus infintely more. And an >"it just works" configurationless setup could have been part of the standard >instead; yet here we are... nobody 100% happy and a considerable amount of >work being poured into reinventing the DHCP wheel. Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6? >Manual static configuration is indeed a pain. That's why we have DHCP... >set aside a range of addresses for machines that can move around (client >workstations, etc.) and a pool of persistant addresses for servers, >printers, etc. that you want to stay in one place -- some applications >record addresses instead of names, *sigh*. Everything is in one, easy to >manage location. For an ISP where a lot necessarily has to be manually >configured, it can be more work, but is still simple -- even in the days of >the "NOC NOTEBOOK" where only one person could be assigning addresses at a >time. (we've had web based stuff for years now; feed rwhois directly, 'tho >not automatic.) > >> Isn't remembering stuff what we have computers for? > >If you aren't accessing machines by number, why do you care if it always has >the same number? As long as the name always maps to the right number, it >doesn't matter. > >> I have a lot of problems with DHCP and most people don't _need_ it. >> Still, very many people _want_ it and some people do in fact need it. >> I have no problem with that, as long as it doesn't lead to the >> situation where I have to run it. > >And I, likewise, don't want the utterly useless "RA" forced on my networks. >Hosts need much more than just a unique address. And I don't want to have >to walk around to every one of them to change anything. Well, as it stands now the RA isn't useless. It, and it alone, provides default gateway information ... from the default gateway itself. (I actually think that this is architecturally superior, but that is just my opinion ... ) ((The rest of the info, (addressing or other) can be obtained via RA/SLAAC or DHCPv6)) Also, it is not true in every case that hosts need a "lot more" than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6). From trejrco at gmail.com Mon Feb 9 20:16:49 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 21:16:49 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <200902100022.n1A0MwTc027903@drugs.dv.isc.org> References: Your message of "Mon, 09 Feb 2009 16:00:12 -0800." <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> Message-ID: <00de01c98b25$a24b8980$e6e29c80$@com> > The SOX auditor ought to know better. Any auditor that > requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ... From Mark_Andrews at isc.org Mon Feb 9 20:19:26 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue, 10 Feb 2009 13:19:26 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: Your message of "Mon, 09 Feb 2009 21:11:50 CDT." <00cf01c98b24$efe42680$cfac7380$@com> Message-ID: <200902100219.n1A2JQpe036495@drugs.dv.isc.org> In message <00cf01c98b24$efe42680$cfac7380$@com>, "TJ" writes: > Also, it is not true in every case that hosts need a "lot more" than an > address. > In many cases all my machine needs is an address, default gateway and DNS > server (cheat off of v4 | RFC5006 | Stateless DHCPv6). address + default gateway. I know where the root servers live :-) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From john-nanog at johnpeach.com Mon Feb 9 20:19:40 2009 From: john-nanog at johnpeach.com (John Peach) Date: Mon, 09 Feb 2009 21:19:40 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <00de01c98b25$a24b8980$e6e29c80$@com> References: <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> <00de01c98b25$a24b8980$e6e29c80$@com> Message-ID: <20090209211940.3f424c30@milhouse.peachfamily.net> On Mon, 9 Feb 2009 21:16:49 -0500 "TJ" wrote: > > The SOX auditor ought to know better. Any auditor that > > requires NAT is incompenent. > > Sadly, there are many audit REQUIREMENTS explicitly naming NAT and > RFC1918 addressing ... SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX......... > > -- John From morrowc.lists at gmail.com Mon Feb 9 20:20:37 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Feb 2009 21:20:37 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> Message-ID: <75cb24520902091820l29f7e7cbm5322225d8ec5ebdb@mail.gmail.com> On Mon, Feb 9, 2009 at 6:16 PM, Ricky Beam wrote: > On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum > wrote: >>> >>> If you want the machine to always have the same address, either enter it >>> manually or set your DHCP server to always give it the same address. >> >> Manual configuration doesn't scale. With IPv4, it's quite hard to make >> this work with DHCP, but mostly because of a lack of IPv4 addresses. With 'quite hard to make this work'?? what?? have you been making a dhcp server from scratch all these years? Iljitsch, what parts of making static mappings in DHCP, or setting the configuration bits required for dns/default-router/tftp-server/root-partition/wins-server/..... is 'hard to do' in a dhcp server with decently wide use today? (isc dhcpd/windows-dhcp-server) >> IPv6 it's easier, but you're still limiting the uptime of your system to >> that of the DHCPv6 server. Router advertisements is much more robust. 'more robust'... except it doesnt' actually get a device into a usable state without admins walking around to each machine and poking at them randomly. if you have 5 machines that's cool, knock yourself out, if you have 5000 or 50000 you are in a completely different ballpark of work. DHCP servers do this today, the servers pass out all the relevant bits require for dynamic-addressed and static-addressed systems, they can be rebooted, moved, re-addressed, re-homed... all without the masses of clients stopping their work. Why are you filling the discussion with FUD about dhcp servers?? > > As I read it, you don't want to use DHCP because "it's an other service to > fail." Well, what do you think is broadcasting RA's? My DHCP servers have > proven far more stable than my routers. (and one of them is a windows server > :-)) Most dhcp clients that keep any state will continue using the > previously assigned address if the server is unavailable (and nothing else > is using it.) Configuring a static address in a DHCP server is a pretty > trivial task. thank you Mr. Beam. >> I have a lot of problems with DHCP and most people don't _need_ it. Still, can you explain how 'most people don't need it'?? is that because most people have an admin to go configure their DNS servers in their resolver config?? Consumer Internet users are a great example of this, if necessary an ISP can pass out new DNS servers, and in 8-10 days easily remove the old DNS servers from the network, or move them to another place in the network seemlessly without having to touch each consumer device. Why would anyone NOT want that?? what replaces that option in current RA deployments? >> very many people _want_ it and some people do in fact need it. I have no >> problem with that, as long as it doesn't lead to the situation where I have >> to run it. no, you don't today have to run it... but why are you arguing against the fact that admins at enterprises and ISP's have been making this very clear argument for equal functionality to what's available today? -Chris From sethm at rollernet.us Mon Feb 9 20:24:13 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Feb 2009 18:24:13 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090209211940.3f424c30@milhouse.peachfamily.net> References: <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> <00de01c98b25$a24b8980$e6e29c80$@com> <20090209211940.3f424c30@milhouse.peachfamily.net> Message-ID: <4990E54D.6030506@rollernet.us> John Peach wrote: > > On Mon, 9 Feb 2009 21:16:49 -0500 > "TJ" wrote: > >>> The SOX auditor ought to know better. Any auditor that >>> requires NAT is incompenent. >> Sadly, there are many audit REQUIREMENTS explicitly naming NAT and >> RFC1918 addressing ... > > SOX auditors are incompetent. I've been asked about anti-virus software > on UNIX servers and then asked to prove that they run UNIX......... Not just SOX. I vaguely remember something in PCI about NAT. It wouldn't surprise me if every auditing thing involving computers said something about requiring NAT. See my earlier comment about NAT=firewall. ~Seth From trejrco at gmail.com Mon Feb 9 20:27:59 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 21:27:59 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090209211940.3f424c30@milhouse.peachfamily.net> References: <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> <00de01c98b25$a24b8980$e6e29c80$@com> <20090209211940.3f424c30@milhouse.peachfamily.net> Message-ID: <00df01c98b27$3181b7e0$948527a0$@com> >> > The SOX auditor ought to know better. Any auditor that >> > requires NAT is incompenent. >> >> Sadly, there are many audit REQUIREMENTS explicitly naming NAT and >> RFC1918 addressing ... > >SOX auditors are incompetent. I've been asked about anti-virus software on >UNIX servers and then asked to prove that they run UNIX......... Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do. From jbates at brightok.net Mon Feb 9 20:38:33 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 09 Feb 2009 20:38:33 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <00df01c98b27$3181b7e0$948527a0$@com> References: <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> <00de01c98b25$a24b8980$e6e29c80$@com> <20090209211940.3f424c30@milhouse.peachfamily.net> <00df01c98b27$3181b7e0$948527a0$@com> Message-ID: <4990E8A9.6040203@brightok.net> TJ wrote: > When the compliance explicitly requires something they are required to check > for it, they don't have the option of ignoring or waving requirements ... > and off the top of my head I don't recall if it is SOX that calls for > RFC1918 explicitly but I know there are some that do. I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty sure the requirements will change as the addressing changes. Of course, I'm sure you will have a lot of NEW requirements. :) Jack From trejrco at gmail.com Mon Feb 9 20:47:15 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 21:47:15 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <75cb24520902091820l29f7e7cbm5322225d8ec5ebdb@mail.gmail.com> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <75cb24520902091820l29f7e7cbm5322225d8ec5ebdb@mail.gmail.com> Message-ID: <00e001c98b29$e29538c0$a7bfaa40$@com> >Why would anyone NOT want that?? what replaces that option in current RA >deployments? One nit - I like to differentiate between the presence of RAs (which should be every user where IPv6 is present) and the use of SLAAC (RA + prefix). Right now - Cheat off of IPv4's config. (Lack of DHCPv6 client-side support, and lack of DNS v6 transport (WinXP), necessitate this) Hopefully soon - RFC5006. Around the same timeframe - DHCPv6 (stateful or stateless, doesn't matter). From trejrco at gmail.com Mon Feb 9 20:53:37 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 21:53:37 -0500 Subject: IPv6 delivery model to end customers In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B98965263E@fudd.ad.maine.edu> References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> <00d801c98ae8$6e4214c0$4ac63e40$@com> <36243D984F88BA4ABD1E0EFC1E61B98965263E@fudd.ad.maine.edu> Message-ID: <00fb01c98b2a$c64f68b0$52ee3a10$@com> >> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 >Thanks for pointing us to this. It's encouraging to know that it is being worked on. My pleasure, now everyone - feel free to ring up your local sales/support rep and "encourage" their product to implement this ... please! /TJ From frnkblk at iname.com Mon Feb 9 20:54:43 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 9 Feb 2009 20:54:43 -0600 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> Message-ID: Comtrend DSL modem use iptables in their code. I discovered this while trying to understood why small-MTU FTP breaks when issuing the PORT command. Frank -----Original Message----- From: Ricky Beam [mailto:jfbeam at gmail.com] Sent: Monday, February 09, 2009 4:01 PM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space DSL and cable modems are extremely simple devices. I'm amazed they have any amount of "router" in them at all. And I've yet to see one running Linux. (the 2 popular brands around here -- westell and motorola -- run vxworks.) --Ricky From Mark_Andrews at isc.org Mon Feb 9 21:16:10 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue, 10 Feb 2009 14:16:10 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Mon, 09 Feb 2009 21:27:59 CDT." <00df01c98b27$3181b7e0$948527a0$@com> Message-ID: <200902100316.n1A3GAIW038167@drugs.dv.isc.org> In message <00df01c98b27$3181b7e0$948527a0$@com>, "TJ" writes: > >> > The SOX auditor ought to know better. Any auditor that > >> > requires NAT is incompenent. > >> > >> Sadly, there are many audit REQUIREMENTS explicitly naming NAT and > >> RFC1918 addressing ... > > > >SOX auditors are incompetent. I've been asked about anti-virus software on > >UNIX servers and then asked to prove that they run UNIX......... > > Fair enough, but my point was that it isn't the auditors' faults in _all_ > cases. > When the compliance explicitly requires something they are required to check > for it, they don't have the option of ignoring or waving requirements ... > and off the top of my head I don't recall if it is SOX that calls for > RFC1918 explicitly but I know there are some that do. Please cite references. I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From jgreco at ns.sol.net Mon Feb 9 21:19:13 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 9 Feb 2009 21:19:13 -0600 (CST) Subject: Automatic Switches? In-Reply-To: <498FE21A.2000605@rollernet.us> from "Seth Mattinen" at Feb 08, 2009 11:58:18 PM Message-ID: <200902100319.n1A3JDxx029612@aurora.sol.net> > Seth Mattinen wrote: > > I hate to interrupt the IPv6 and RFC 1918 mega-threads... > > > > Does anyone know of a company that makes 208v (3-wire line-line ground, > > no neutral, 208v loads only, single phase) 30-60 amp automatic transfer > > switches with sub-30ms switching time? APC used to make the SU045X163 > > 30A model, but it seems to have been discontinued and it's hard to find > > products that support 208v single phase. It's not flagged as discontinued on the APC site, though it seems to have been dropped from the RATS page. Maybe in the process of being discontinued? http://www.apc.com/resource/include/techspec_index.cfm?base_sku=SU045X163 > Ugh, of course I come across something (TwinSource DCC-II RM-ITSTS, 50A > in a 4U case using SCRs) mere minutes after posting. Any other > recommendations are still welcome. The TwinSource unit looks quite > fascinating, although I'm guessing quite expensive. http://shop.ebay.com/?_from=R40&_trksid=m38.l1313&_nkw=SU045X163&_sacat=See-All-Categories The main downside to the SU045 product line seems to be a lack of network manageability. Doesn't mean you can't get 'em. :-) APC doesn't make RATS units larger than 30A, though, so if you need a 50A unit, you'll have to look elsewhere. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From trejrco at gmail.com Mon Feb 9 21:25:17 2009 From: trejrco at gmail.com (TJ) Date: Mon, 9 Feb 2009 22:25:17 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <4990E8A9.6040203@brightok.net> References: <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> <00de01c98b25$a24b8980$e6e29c80$@com> <20090209211940.3f424c30@milhouse.peachfamily.net> <00df01c98b27$3181b7e0$948527a0$@com> <4990E8A9.6040203@brightok.net> Message-ID: <014101c98b2f$32b6e2e0$9824a8a0$@com> >> When the compliance explicitly requires something they are required to >> check for it, they don't have the option of ignoring or waving >requirements ... >> and off the top of my head I don't recall if it is SOX that calls for >> RFC1918 explicitly but I know there are some that do. > >I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty >sure the requirements will change as the addressing changes. Of course, I'm >sure you will have a lot of NEW requirements. :) But that is the problem - it doesn't say "You must use RFC1918 for IPv4" ... it just says "You must use RFC1918". Meaning, you must not run IPv6. And some regulations do not mention/address IPv6 at all. Silence != security. From matthew at eeph.com Mon Feb 9 21:45:55 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Mon, 09 Feb 2009 19:45:55 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <200902100316.n1A3GAIW038167@drugs.dv.isc.org> References: <200902100316.n1A3GAIW038167@drugs.dv.isc.org> Message-ID: <4990F873.2050908@eeph.com> Mark Andrews wrote: > Please cite references. > > I can find plenty of firewall required references but I'm > yet to find a NAT and/or RFC 1918 required. (Skip if you've participated in a SOX audit from the IT department POV) The way it works is that the law doesn't call for specific measures. The law calls for audits. Audits are done by outside firms (like "large accounting firms") using their internally-developed checklists for compliance. Passing the checklist gets you an unqualified audit. Failing a few items gets you a qualified audit. Failing more means you don't have the necessary audit document to present. The exact details of every line item are typically under non-disclosure when presented to the IT department for review, so for instance I can't post the ones from the last audit I participated in. Firms are also free to develop their own internal control guidelines, as long as they can convince the outside auditor that the controls are at least as strong as the ones on the checklist. Other regulations, like HIPPA, also require the same thing. For instance, the top Google hit for HIPPA and "private address space" links to a wustl.edu document regarding how their controls over HIPPA-protected information are implemented (including the use of private address space and the use of multiple layers of NAT). It takes a *lot* longer to get policies changed and auditors to sign off on the revised policies than it does to make a change in a router. That means that the process of updating policies should have started *even sooner* than the process of upgrading and reconfiguring routers for IPv6. But since there's still open questions (like the recent discussion of IPv6 NAT on the BEHAVE list) that have no answers at all, I can imagine why some folks might be putting off revising their policies and asking for external review of those. Matthew Kaufman From morrowc.lists at gmail.com Mon Feb 9 22:35:53 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Feb 2009 23:35:53 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <00e001c98b29$e29538c0$a7bfaa40$@com> References: <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <75cb24520902091820l29f7e7cbm5322225d8ec5ebdb@mail.gmail.com> <00e001c98b29$e29538c0$a7bfaa40$@com> Message-ID: <75cb24520902092035v62f1ad9bs3712b0094c3d8787@mail.gmail.com> On Mon, Feb 9, 2009 at 9:47 PM, TJ wrote: >>Why would anyone NOT want that?? what replaces that option in current RA >>deployments? > > One nit - I like to differentiate between the presence of RAs (which should > be every user where IPv6 is present) and the use of SLAAC (RA + prefix). > Sure, but... RA is necessitated by the initial decision to use it and NOT support something akin to the bootp/dhcp sequence that v4 has. This could, it seems to me, be done... but since RA is there, it's not BAD to use it for prefix/default-route/ip-address it's just not anywhere near complete. > > Right now - Cheat off of IPv4's config. > (Lack of DHCPv6 client-side support, and lack of DNS v6 transport (WinXP), > necessitate this) agreed. -Chris From josmon at rigozsaurus.com Mon Feb 9 23:54:21 2009 From: josmon at rigozsaurus.com (John Osmon) Date: Mon, 9 Feb 2009 22:54:21 -0700 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <200902100316.n1A3GAIW038167@drugs.dv.isc.org> References: <00df01c98b27$3181b7e0$948527a0$@com> <200902100316.n1A3GAIW038167@drugs.dv.isc.org> Message-ID: <20090210055421.GA18346@jeeves.rigozsaurus.com> On Tue, Feb 10, 2009 at 02:16:10PM +1100, Mark Andrews wrote: > > In message <00df01c98b27$3181b7e0$948527a0$@com>, "TJ" writes: [...SOX auditor stuff...] > > When the compliance explicitly requires something they are required to check > > for it, they don't have the option of ignoring or waving requirements ... > > and off the top of my head I don't recall if it is SOX that calls for > > RFC1918 explicitly but I know there are some that do. > > Please cite references. > > I can find plenty of firewall required references but I'm > yet to find a NAT and/or RFC 1918 required. It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) I know that some auditors want to hold people to that standard. I stopped working with the credit card people at that point... From nuno.vieira at nfsi.pt Tue Feb 10 00:11:55 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Tue, 10 Feb 2009 06:11:55 +0000 (WET) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <1198381922.30781234246225230.JavaMail.root@zimbra.nfsi.pt> Message-ID: <33767877.30801234246315455.JavaMail.root@zimbra.nfsi.pt> security by obscurity is not the way, everyone knows it. those guys will figure it out sooner or later (where later, might take ages). in the meanwhile, a lot have pseudo-secured networks thru triple-nat, quadruple-nat, multiple ipsec'd layered and so, and others live with the hammer in their suitcase for fixing things around when the clue is gone. often they forgot the neat webserver box that run's some strange software, which no one updates, and... in the end is the cheese hole around their network... but, in the other end, money talks, and bulls**t walks, so, we might be all wrong, and they might be right, who knows ? who cares anyway ? :-) --nvieira ----- "John Osmon" wrote: > > It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: > Implement IP address masquerading to prevent internal addresses > from > being translated and revealed on the Internet. Use technologies > that > implement RFC 1918 address space, such as port address translation > (PAT) > or network address translation (NAT) > > I know that some auditors want to hold people to that standard. > > I stopped working with the credit card people at that point... From scott at doc.net.au Tue Feb 10 00:24:03 2009 From: scott at doc.net.au (Scott Howard) Date: Mon, 9 Feb 2009 22:24:03 -0800 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space Message-ID: On Mon, Feb 9, 2009 at 9:54 PM, John Osmon wrote: > It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: > Implement IP address masquerading to prevent internal addresses from > being translated and revealed on the Internet. Use technologies that > implement RFC 1918 address space, such as port address translation (PAT) > or network address translation (NAT) It's moved to Requirement 1.3.8 of the current PCI DSS (V1.2, October 2008), and has been reworded slight : *1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies?for example, port address translation (PAT).* However the PCI DSS does contain a "Compensating controls" section, which allows for the use of functionality which "provide[s] a similar level of defense" to the stated requirements, where the stated requirements can not be followed due to "legitimate technical or documented business constraints" Now the fact that RFC1918 addresses don't work with IPv6 is clearly a "legitimate technical ... constraint", so as long as you could successfully argue that a stateful firewall or other measures in place provided equivalent security as NAT you should be fine. Scott. From swmike at swm.pp.se Tue Feb 10 01:02:36 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 10 Feb 2009 08:02:36 +0100 (CET) Subject: IPv6 delivery model to end customers In-Reply-To: <00fb01c98b2a$c64f68b0$52ee3a10$@com> References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> <00d801c98ae8$6e4214c0$4ac63e40$@com> <36243D984F88BA4ABD1E0EFC1E61B98965263E@fudd.ad.maine.edu> <00fb01c98b2a$c64f68b0$52ee3a10$@com> Message-ID: On Mon, 9 Feb 2009, TJ wrote: > My pleasure, now everyone - feel free to ring up your local > sales/support rep and "encourage" their product to implement this ... > please! What about "DHCPv6 / DHCPV6-PD" sniffing (and using that info to create L3 filter rules in L2 devices), is a standard needed or is it obvious to vendors how to implement it? -- Mikael Abrahamsson email: swmike at swm.pp.se From mpalmer at hezmatt.org Tue Feb 10 01:03:40 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Tue, 10 Feb 2009 18:03:40 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <00df01c98b27$3181b7e0$948527a0$@com> References: <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> <00de01c98b25$a24b8980$e6e29c80$@com> <20090209211940.3f424c30@milhouse.peachfamily.net> <00df01c98b27$3181b7e0$948527a0$@com> Message-ID: <20090210070340.GI23813@hezmatt.org> On Mon, Feb 09, 2009 at 09:27:59PM -0500, TJ wrote: > >> > The SOX auditor ought to know better. Any auditor that > >> > requires NAT is incompenent. > >> > >> Sadly, there are many audit REQUIREMENTS explicitly naming NAT and > >> RFC1918 addressing ... > > > >SOX auditors are incompetent. I've been asked about anti-virus software on > >UNIX servers and then asked to prove that they run UNIX......... > > Fair enough, but my point was that it isn't the auditors' faults in _all_ > cases. > When the compliance explicitly requires something they are required to check > for it, they don't have the option of ignoring or waving requirements ... > and off the top of my head I don't recall if it is SOX that calls for > RFC1918 explicitly but I know there are some that do. Considering that RFC1918 says nothing about IPv at all, could that be a blocker for deployment in general? That'd also make for an interesting discussion re: other legacy protocols (IPX, anyone?)... - Matt -- I tend to think of "solution" as just a pretentious term for "thingy". Doing that word substitution in my head makes IT marketing literature somewhat more tolerable. -- lutchann, in http://lwn.net/Articles/124703/ From mohacsi at niif.hu Tue Feb 10 02:21:27 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 10 Feb 2009 09:21:27 +0100 (CET) Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> <498DE1AD.1000807@sprunk.org> Message-ID: On Mon, 9 Feb 2009, Ricky Beam wrote: > On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk > wrote: >> Non-NAT firewalls do have some appeal, because they don't need to mangle >> the packets, just passively observe them and open pinholes when >> appropriate. > > This is exactly the same with NAT and non-NAT -- making any anti-NAT > arguments null. > > In the case of NAT, the "helper" has to understand the protocol to know what > traffic to map. > > In the case of a stateful firewalling ("non-NAT"), the "helper" has to > understand the protocol to know what traffic to allow. > > Subtle difference, but in the end, the same thing... if your gateway doesn't > know what you are doing, odds are it will interfere with it. In all cases, > end-to-end transparency doesn't exist. (as has been the case for well over a > decade.) You arguments making any pro-NAT arguments null. You agree, that NAT and Stateful Packet Inspetion firewall doing similar things. Advantage of the SPI firewall is that you have to maintain only one forwarding/state table. While in NAT you have to maintain two table. Therefore SPI firewall is more scalable.... Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > --Ricky > From elmi at 4ever.de Tue Feb 10 02:39:44 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 10 Feb 2009 09:39:44 +0100 Subject: Network equipments process utilization In-Reply-To: <10715296.143051234229384202.JavaMail.weblogic@epml04> References: <10715296.143051234229384202.JavaMail.weblogic@epml04> Message-ID: <20090210083943.GP91662@ronin.4ever.de> Good morning (from here), lionair at samsung.com (?????) wrote: > I wonder which percentage is good level of CPU and Memory util of network equipment ? > In my case, I try to keep under 30% cpu util and 70% memory util. My most equipment are Cisco product. > I have no technical reference about that, it is just a rule of mine or my predecessor. > Could you tell me how other operators are doing ? what is your operation baseline ? or is there any guideline about process utilization ? I'm trying to keep all Cisco equipment idle, if at all possible, since there may come worse times... Typical exceptions are - software forwarding routers, where CPU load is directly depending on current traffic levels; should the load stay above 15-20% all the time, it's time for an upgrade - slow-CPU boxes like everything Cisco with SUPs, since the CPU load _always_ jumps to 100% for short periods of time - BGP needs something calculated ;-) I get interested whenever CPU load _stays_ high - switches; Cisco switches need like 5% CPU to blink the LEDs ;) It gets more interested with packet filters and load balancers, where CPU loads depend on traffic levels and patterns. I try to keep the baseline between 5 and 10%. HTH, Elmar. From hank at efes.iucc.ac.il Tue Feb 10 02:51:49 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 10 Feb 2009 10:51:49 +0200 Subject: Network equipments process utilization In-Reply-To: <20090210083943.GP91662@ronin.4ever.de> References: <10715296.143051234229384202.JavaMail.weblogic@epml04> <10715296.143051234229384202.JavaMail.weblogic@epml04> Message-ID: <5.1.0.14.2.20090210104955.00b09530@efes.iucc.ac.il> At 09:39 AM 10-02-09 +0100, Elmar K. Bins wrote: > - slow-CPU boxes like everything Cisco with SUPs, since the > CPU load _always_ jumps to 100% for short periods of > time - BGP needs something calculated ;-) I get interested > whenever CPU load _stays_ high Yeah - Cisco would like to know why as well: http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html :-) -Hank From elmi at 4ever.de Tue Feb 10 03:00:58 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 10 Feb 2009 10:00:58 +0100 Subject: Network equipments process utilization In-Reply-To: <5.1.0.14.2.20090210104955.00b09530@efes.iucc.ac.il> References: <10715296.143051234229384202.JavaMail.weblogic@epml04> <10715296.143051234229384202.JavaMail.weblogic@epml04> <5.1.0.14.2.20090210104955.00b09530@efes.iucc.ac.il> Message-ID: <20090210090058.GR91662@ronin.4ever.de> hank at efes.iucc.ac.il (Hank Nussbacher) wrote: > > - slow-CPU boxes like everything Cisco with SUPs, since the > > CPU load _always_ jumps to 100% for short periods of > > time - BGP needs something calculated ;-) I get interested > > whenever CPU load _stays_ high > > Yeah - Cisco would like to know why as well: > http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html I know ;-) But: This is not a churn problem, it's a problem of slow CPUs in allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my 76's, as RP. Still, this is getting off-topic. Elmar. From lists at memetic.org Tue Feb 10 03:51:58 2009 From: lists at memetic.org (Adam Armstrong) Date: Tue, 10 Feb 2009 09:51:58 +0000 Subject: Network equipments process utilization In-Reply-To: <20090210090058.GR91662@ronin.4ever.de> References: <10715296.143051234229384202.JavaMail.weblogic@epml04> <10715296.143051234229384202.JavaMail.weblogic@epml04> <5.1.0.14.2.20090210104955.00b09530@efes.iucc.ac.il> <20090210090058.GR91662@ronin.4ever.de> Message-ID: <49914E3E.3040806@memetic.org> Elmar K. Bins wrote: > hank at efes.iucc.ac.il (Hank Nussbacher) wrote: > > >>> - slow-CPU boxes like everything Cisco with SUPs, since the >>> CPU load _always_ jumps to 100% for short periods of >>> time - BGP needs something calculated ;-) I get interested >>> whenever CPU load _stays_ high >>> >> Yeah - Cisco would like to know why as well: >> http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html >> > > I know ;-) > > But: This is not a churn problem, it's a problem of slow CPUs in > allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my > 76's, as RP. Still, this is getting off-topic. > The MSFC4 in the RSP720 has a 1.2GHz 8548 PPC whereas the NPE-G2 has a 1.67GHz 7448 PPC. I'd guess the performance isn't all that far apart, especially as the MSFC4's processor isn't doing any forwarding. adam. From elmi at 4ever.de Tue Feb 10 03:56:07 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 10 Feb 2009 10:56:07 +0100 Subject: Network equipments process utilization In-Reply-To: <49914E3E.3040806@memetic.org> References: <10715296.143051234229384202.JavaMail.weblogic@epml04> <10715296.143051234229384202.JavaMail.weblogic@epml04> <5.1.0.14.2.20090210104955.00b09530@efes.iucc.ac.il> <20090210090058.GR91662@ronin.4ever.de> <49914E3E.3040806@memetic.org> Message-ID: <20090210095607.GT91662@ronin.4ever.de> lists at memetic.org (Adam Armstrong) wrote: > >>> CPU load _always_ jumps to 100% for short periods of > >>> time - BGP needs something calculated ;-) I get interested > >>> whenever CPU load _stays_ high > >>> > >>Yeah - Cisco would like to know why as well: > >>http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp07026.html > >> > > > >I know ;-) > > > >But: This is not a churn problem, it's a problem of slow CPUs in > >allegedly big-and-fast boxes. I'd like a NPE-G2 blade for my > >76's, as RP. Still, this is getting off-topic. > > > > The MSFC4 in the RSP720 has a 1.2GHz 8548 PPC whereas the NPE-G2 has a > 1.67GHz 7448 PPC. > > I'd guess the performance isn't all that far apart, especially as the > MSFC4's processor isn't doing any forwarding. That's why I wrote "with SUPs" (and not RSPs). RSP is fairly new, and they got it right this time. From Valdis.Kletnieks at vt.edu Tue Feb 10 04:21:46 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 10 Feb 2009 05:21:46 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: Your message of "Tue, 10 Feb 2009 18:03:40 +1100." <20090210070340.GI23813@hezmatt.org> References: <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> <00de01c98b25$a24b8980$e6e29c80$@com> <20090209211940.3f424c30@milhouse.peachfamily.net> <00df01c98b27$3181b7e0$948527a0$@com> <20090210070340.GI23813@hezmatt.org> Message-ID: <98698.1234261306@turing-police.cc.vt.edu> On Tue, 10 Feb 2009 18:03:40 +1100, Matthew Palmer said: > Considering that RFC1918 says nothing about IPv at all, could that be a > blocker for deployment in general? That'd also make for an interesting > discussion re: other legacy protocols (IPX, anyone?)... I was all set to call shenanigans on this one - except I double-checked the dates on the RFCs, and RFC1752 pre-dates 1918 by a year... Not sure what it says about our industry that both RFCs are 13+ years old now, and we still can't collectively do either one right... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From trejrco at gmail.com Tue Feb 10 07:29:38 2009 From: trejrco at gmail.com (TJ) Date: Tue, 10 Feb 2009 08:29:38 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: <20090205043908.1BAA82B21F4@mx5.roble.com> <498CEFF8.6060403@sprunk.org> <498CFACA.1030101@internode.com.au> Message-ID: <000901c98b83$9fcf2820$df6d7860$@com> >> IPTables is decent firewall code. > >Not really. It's quite complicated for a non-engineer type to manage. >Think of all the unpatched windows xp/vista users of the world. > >> It's free. >... >> Further, since more and more CPE is being built on embedded linux, >> there's no reason that IPTables isn't a perfectly valid approach to >> the underlying firewall code. > >No. It's not. While you might not be paying anyone for the software, it >does come with some significant costs... a moderately powerful processor and >a lot of memory. Ah, "but both are cheap these days, and getting cheaper", >you say. Tell me where I can get 500MHz+ processors and 16+ MB of ram for >"pennies". Case in point... (in case you missed it) Linksys stopped using >Linux on their popular WRT54G line years ago in favor of vxWorks because it >took less resources and therefor meant they could use less memory (flash and >ram) and save money despite paying a license fee for vxWorks. (They still >use vxWorks on the 54g, but have used linux on their newer (much more >expensive) hardware.) Well thank goodness that VxWorks 6.x (or with 3rd party hackery) can both do IPv6 and can have firewalling functionality as well (or so Google tells me). Oh, and Linux can be tiny - even with iptables. I suspect Cisco (nee Linksys) chose VxWorks for a number of reasons, "footprint" being but one of them. >DSL and cable modems are extremely simple devices. I'm amazed they have any >amount of "router" in them at all. And I've yet to see one running Linux. >(the 2 popular brands around here -- westell and motorola -- run >vxworks.) Actually, the DOCSIS 3.0 spec may be changing that ... "eRouter" ... From trey at kingfisherops.com Tue Feb 10 07:40:28 2009 From: trey at kingfisherops.com (Trey Darley) Date: Tue, 10 Feb 2009 14:40:28 +0100 (CET) Subject: Private use of non-RFC1918 IP space In-Reply-To: <498FD993.5060604@bogus.com> References: <49555.1233631443@turing-police.cc.vt.edu> <498FD993.5060604@bogus.com> Message-ID: <20853.192.101.252.156.1234273228.squirrel@kingfisherops.com> Just for the record, the original post was in reference to use of non-RFC1918 space on an *air-gapped* network. --Trey >> Let's face it - they're going to have to come up with much more creative >> $200/hour chucklehead consultants to burn through that much anytime soon. >> Anybody feel like starting a pool for when we'll see a posting to NANOG about somebody who's managed to burn through a /32? ++----------------------------------------------------------------------------++ Kingfisher Operations Trey Darley - Principal From trejrco at gmail.com Tue Feb 10 07:52:31 2009 From: trejrco at gmail.com (TJ) Date: Tue, 10 Feb 2009 08:52:31 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <200902100316.n1A3GAIW038167@drugs.dv.isc.org> References: Your message of "Mon, 09 Feb 2009 21:27:59 CDT." <00df01c98b27$3181b7e0$948527a0$@com> <200902100316.n1A3GAIW038167@drugs.dv.isc.org> Message-ID: <000a01c98b86$d40c8a80$7c259f80$@com> >> >> > The SOX auditor ought to know better. Any auditor that >> >> > requires NAT is incompenent. >> >> >> >> Sadly, there are many audit REQUIREMENTS explicitly naming NAT and >> >> RFC1918 addressing ... >> > >> >SOX auditors are incompetent. I've been asked about anti-virus >> >software on UNIX servers and then asked to prove that they run >UNIX......... >> >> Fair enough, but my point was that it isn't the auditors' faults in >> _all_ cases. >> When the compliance explicitly requires something they are required to >> check for it, they don't have the option of ignoring or waving >requirements ... >> and off the top of my head I don't recall if it is SOX that calls for >> RFC1918 explicitly but I know there are some that do. > > Please cite references. > > I can find plenty of firewall required references but I'm > yet to find a NAT and/or RFC 1918 required. > Minor correction (I did say I wasn't sure it was SOX) ... It is PCI that requires RFC1918 and translation. For SOX, what is your assessment of (IPv6) internal controls and risk based on? Has anyone (with the authority to do so) developed and released guidance? Do we have a repository of "current best practices" to rely on (yet)? Interestingly, with SOX, I am curious if lack of IPv6 preparation will play into the risk assessment as well :). Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply tend to omit IPv6 completely, and generally require everything not explicitly called out to be disabled ... thus, no IPv6 on any network that falls under any of these regulations. We are just starting to see finalized product profiles and STIGs for IPv6 configuration - without that guidance Defense networks really couldn't run IPv6 either. (In other words (again, generally speaking) - if you run IPv6, your current C&A (or perhaps your CTO (Certificate To Operate)) is invalid). From trejrco at gmail.com Tue Feb 10 07:57:28 2009 From: trejrco at gmail.com (TJ) Date: Tue, 10 Feb 2009 08:57:28 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: References: Message-ID: <000b01c98b87$835fcfb0$8a1f6f10$@com> >However the PCI DSS does contain a "Compensating controls" section, which >allows for the use of functionality which "provide[s] a similar level of >defense" to the stated requirements, where the stated requirements can not >be followed due to "legitimate technical or documented business constraints" > >Now the fact that RFC1918 addresses don't work with IPv6 is clearly a >"legitimate technical ... constraint", so as long as you could successfully >argue that a stateful firewall or other measures in place provided >equivalent security as NAT you should be fine. Excellent loophole! Although I wonder how many clueful auditors are out there and able to make this fly ... From trejrco at gmail.com Tue Feb 10 08:01:08 2009 From: trejrco at gmail.com (TJ) Date: Tue, 10 Feb 2009 09:01:08 -0500 Subject: IPv6 delivery model to end customers In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> <00d801c98ae8$6e4214c0$4ac63e40$@com> <36243D984F88BA4ABD1E0EFC1E61B98965263E@fudd.ad.maine.edu> <00fb01c98b2a$c64f68b0$52ee3a10$@com> Message-ID: <000f01c98b88$0667aa40$1336fec0$@com> >> My pleasure, now everyone - feel free to ring up your local >> sales/support rep and "encourage" their product to implement this ... >> please! > >What about "DHCPv6 / DHCPV6-PD" sniffing (and using that info to create L3 >filter rules in L2 devices), is a standard needed or is it obvious to >vendors how to implement it? An analogy to "DHCP Guard" - yes, please do encourage them to also do this. (And an RFC might not be a bad idea ... ) While we are at it - MLD Snooping should (IMHO) be a switch's default behavior as well! From trejrco at gmail.com Tue Feb 10 08:06:31 2009 From: trejrco at gmail.com (TJ) Date: Tue, 10 Feb 2009 09:06:31 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <20090210070340.GI23813@hezmatt.org> References: <4990C38C.8060007@eeph.com> <200902100022.n1A0MwTc027903@drugs.dv.isc.org> <00de01c98b25$a24b8980$e6e29c80$@com> <20090209211940.3f424c30@milhouse.peachfamily.net> <00df01c98b27$3181b7e0$948527a0$@com> <20090210070340.GI23813@hezmatt.org> Message-ID: <001001c98b88$c6c39790$544ac6b0$@com> >Considering that RFC1918 says nothing about IPv at all, That may technically be true, but it does explicitly reference IPv4 addresses. Oh, and when RFC1918 (or more correctly, RFC1597) was written, "IP", "TCP/IP", etc. all directly meant IPv4. (RFC1597 @ 03/94 ... RFC1883 @ 12/95) From tme at multicasttech.com Tue Feb 10 08:15:42 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 10 Feb 2009 09:15:42 -0500 Subject: IPv6 delivery model to end customers In-Reply-To: <000f01c98b88$0667aa40$1336fec0$@com> References: <53A6C7E936ED8544B1A2BC990D254F943524A77C90@MEMEXG1.HOST.local> <36243D984F88BA4ABD1E0EFC1E61B989652601@fudd.ad.maine.edu> <00d801c98ae8$6e4214c0$4ac63e40$@com> <36243D984F88BA4ABD1E0EFC1E61B98965263E@fudd.ad.maine.edu> <00fb01c98b2a$c64f68b0$52ee3a10$@com> <000f01c98b88$0667aa40$1336fec0$@com> Message-ID: On Feb 10, 2009, at 9:01 AM, TJ wrote: >>> My pleasure, now everyone - feel free to ring up your local >>> sales/support rep and "encourage" their product to implement >>> this ... >>> please! >> >> What about "DHCPv6 / DHCPV6-PD" sniffing (and using that info to >> create L3 >> filter rules in L2 devices), is a standard needed or is it obvious to >> vendors how to implement it? > > > An analogy to "DHCP Guard" - yes, please do encourage them to also > do this. > (And an RFC might not be a bad idea ... ) > > While we are at it - MLD Snooping should (IMHO) be a switch's default s/MLD/MLD v2/ Marshall > > behavior as well! > > From alexlh at ripe.net Tue Feb 10 10:07:27 2009 From: alexlh at ripe.net (Alex Le Heux) Date: Tue, 10 Feb 2009 17:07:27 +0100 Subject: New IPv4 blocks allocated to RIPE NCC Message-ID: <169ACBFD-99D3-4A07-A435-403A8B9404DE@ripe.net> [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 109/8 and 178/8 from the IANA in January 2009. We will begin allocating from these ranges in the near future. The minimum allocation size from these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Please also note that several "pilot" prefixes are being announced from each /8. These prefixes are: 178.0.0.0/16, pingable 178.0.0.1 178.1.0.0/21, pingable 178.1.0.1 178.1.24.0/24, pingable 178.1.24.1 109.0.0.0/16, pingable 109.0.0.1 109.1.0.0/21, pingable 109.1.0.1 109.1.24.0/24, pingable 109.1.24.1 They all originate in AS12654. More information on this "pilot" activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator From dlc at lampinc.com Tue Feb 10 10:45:03 2009 From: dlc at lampinc.com (Dale Carstensen) Date: Tue, 10 Feb 2009 09:45:03 -0700 Subject: Is whois.apnic.net down? Message-ID: <20090210164456.D72B638D600@lampinc.com> I get "Connection timed out" on whois commands to it. From dlc at lampinc.com Tue Feb 10 10:48:21 2009 From: dlc at lampinc.com (Dale Carstensen) Date: Tue, 10 Feb 2009 09:48:21 -0700 Subject: Is whois.apnic.net down? Message-ID: <20090210164815.192D138D600@lampinc.com> >I get "Connection timed out" on whois commands to it. Sorry to attempt to answer my own question, but maybe it's the fires in Australia, as the last traceroute hop is a Brisbane.telstra.net domain name. From dave at stayonline.com Tue Feb 10 10:49:33 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 10 Feb 2009 11:49:33 -0500 Subject: Is whois.apnic.net down? In-Reply-To: <20090210164456.D72B638D600@lampinc.com> References: <20090210164456.D72B638D600@lampinc.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB434EA7@MERCURY.socrdu.com> Times out for me as well. Last hop in AU. 8 240 ms 238 ms 239 ms 10.14.254.125.unassigned.comindico.com.au [125.254.14.10] -----Original Message----- From: Dale Carstensen [mailto:dlc at lampinc.com] Sent: Tuesday, February 10, 2009 11:45 AM To: nanog at nanog.org Subject: Is whois.apnic.net down? I get "Connection timed out" on whois commands to it. From brandon.galbraith at gmail.com Tue Feb 10 10:52:03 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 10 Feb 2009 10:52:03 -0600 Subject: Is whois.apnic.net down? In-Reply-To: <20090210164815.192D138D600@lampinc.com> References: <20090210164815.192D138D600@lampinc.com> Message-ID: <366100670902100852we5d1c92uf64905760a38ee88@mail.gmail.com> On 2/10/09, Dale Carstensen wrote: > > >I get "Connection timed out" on whois commands to it. > > Sorry to attempt to answer my own question, but maybe it's the fires > in Australia, as the last traceroute hop is a Brisbane.telstra.net > domain name. > > Backhoe fade I'm used to. But now fire fade? Lovely. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From mpalmer at hezmatt.org Tue Feb 10 11:04:12 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 11 Feb 2009 04:04:12 +1100 Subject: Is whois.apnic.net down? In-Reply-To: <20090210164815.192D138D600@lampinc.com> References: <20090210164815.192D138D600@lampinc.com> Message-ID: <20090210170412.GK23813@hezmatt.org> On Tue, Feb 10, 2009 at 09:48:21AM -0700, Dale Carstensen wrote: > >I get "Connection timed out" on whois commands to it. > > Sorry to attempt to answer my own question, but maybe it's the fires > in Australia, as the last traceroute hop is a Brisbane.telstra.net > domain name. Brisbane's about 2000km north of the major fires. Instead, they're recovering from a cyclone. Gotta love this country. - Matt -- Talk about unlucky. D'you know, if I fell in a barrel of tits I'd come out sucking me thumb. -- Seen on the 'net: http://thelawwestofealingbroadway.blogspot.com/2006/01/bang-to-rights.html From scott at doc.net.au Tue Feb 10 11:12:36 2009 From: scott at doc.net.au (Scott Howard) Date: Tue, 10 Feb 2009 09:12:36 -0800 Subject: Is whois.apnic.net down? (IPv6-MW) In-Reply-To: <20090210164815.192D138D600@lampinc.com> References: <20090210164815.192D138D600@lampinc.com> Message-ID: On Tue, Feb 10, 2009 at 8:48 AM, Dale Carstensen wrote: > >I get "Connection timed out" on whois commands to it. > > Sorry to attempt to answer my own question, but maybe it's the fires > in Australia, as the last traceroute hop is a Brisbane.telstra.net > Brisbane (where APNIC is) is close to 1000 miles from Melbourne (where the fires are). Ironically the state Brisbane is in is currently experiencing very bad flooding over most of the state... But I digress. www.apnic.net is also down over IPv4, but reachable over IPv6. whois.apnic.net doesn't seem to have an IPv6 address. Scott. From bburke at merit.edu Tue Feb 10 14:05:57 2009 From: bburke at merit.edu (Betty J. Burke) Date: Tue, 10 Feb 2009 15:05:57 -0500 Subject: [NANOG-announce] NANOG45 Updates Message-ID: Dear Community... One more thank you to Terremark for hosting NANOG45, and to all those in the Dominican Republic who made our stay a bit more enjoyable. However, it sure is nice to be home. Before moving on to our next adventure together, a few pieces of closure information for NANOG45 follows: Survey open until Friday, February 13, be sure you completed yours!! http://nanog.org/meetings/nanog45/agenda.php Now includes the video archive Meeting attendance and survey information will be posted in approximately 2 weeks. Moving forward, we are excited about NANOG46 in Philly! and look forward to seeing everyone there. Sincerely, Betty Merit NANOG Community Project Manager _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jcurran at mail.com Tue Feb 10 14:22:36 2009 From: jcurran at mail.com (John Curran) Date: Tue, 10 Feb 2009 15:22:36 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <000a01c98b86$d40c8a80$7c259f80$@com> References: "Your message of Mon, 09 Feb 2009 21:27:59 CDT." <00df01c98b27$3181b7e0$948527a0$@com> <200902100316.n1A3GAIW038167@drugs.dv.isc.org> <000a01c98b86$d40c8a80$7c259f80$@com> Message-ID: <7D95E111-F755-43DC-AA8C-5F28A35FCE9B@mail.com> On Feb 10, 2009, at 8:52 AM, TJ wrote: > > Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply > tend to > omit IPv6 completely, and generally require everything not > explicitly called > out to be disabled ... thus, no IPv6 on any network that falls under > any of > these regulations. TJ - You attempted to say that for PCI, and then it was shown that there's clear language regarding compensating controls that could easily be considered applicable. I haven't had the honor of running an IPv6-enabled system through a PCI compliance audit, but have little doubt that it will happen shortly and will require auditor education just like every other technology introduction. I run a data center which specializes in secure, compliant managed services, and have been through hundreds of audits in support of our clients which include federal civilian, federal defense, health care, and financial services firms. There are very few IT standards which have precise protocol or address requirements embedded in them, and there is almost always an opportunity to provide compensating controls where necessary. If you've got an example from one of the above compliance frameworks to the contrary that would actually preclude IPv6 deployment, please cite it. > (In other words (again, generally speaking) - if you run IPv6, your > current > C&A (or perhaps your CTO (Certificate To Operate)) is invalid). Sure... change your network, and you need to update your C&A package as part of maintaining your ATO. It's up to your DAA as to whether they want to use IPv6 prior to equipment being certified under the DoD IPv6 Profile. /John John Curran EVP, COO, CTO ServerVault Corp From jay at miscreant.org Tue Feb 10 14:43:00 2009 From: jay at miscreant.org (jay at miscreant.org) Date: Wed, 11 Feb 2009 07:43:00 +1100 Subject: Is whois.apnic.net down? (IPv6-MW) In-Reply-To: References: <20090210164815.192D138D600@lampinc.com> Message-ID: <20090211074300.q9i50jij40wk4wk0@web1.nswh.com.au> Quoting Scott Howard : > On Tue, Feb 10, 2009 at 8:48 AM, Dale Carstensen wrote: > >> >I get "Connection timed out" on whois commands to it. >> >> Sorry to attempt to answer my own question, but maybe it's the fires >> in Australia, as the last traceroute hop is a Brisbane.telstra.net >> > > Brisbane (where APNIC is) is close to 1000 miles from Melbourne (where the > fires are). > Ironically the state Brisbane is in is currently experiencing very bad > flooding over most of the state... > > But I digress. www.apnic.net is also down over IPv4, but reachable over > IPv6. whois.apnic.net doesn't seem to have an IPv6 address. > > Scott. > 9 33 ms 33 ms 33 ms 203.119.76.66 10 36 ms 35 ms 35 ms whois.apnic.net [202.12.29.13] Trace complete. It's reachable from where I'm sitting (NSW) From trejrco at gmail.com Tue Feb 10 15:30:26 2009 From: trejrco at gmail.com (TJ) Date: Tue, 10 Feb 2009 16:30:26 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <7D95E111-F755-43DC-AA8C-5F28A35FCE9B@mail.com> References: "Your message of Mon, 09 Feb 2009 21:27:59 CDT." <00df01c98b27$3181b7e0$948527a0$@com> <200902100316.n1A3GAIW038167@drugs.dv.isc.org> <000a01c98b86$d40c8a80$7c259f80$@com> <7D95E111-F755-43DC-AA8C-5F28A35FCE9B@mail.com> Message-ID: <001b01c98bc6$cba4f220$62eed660$@com> >> Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply >> tend to omit IPv6 completely, and generally require everything not >> explicitly called out to be disabled ... thus, no IPv6 on any network >> that falls under any of these regulations. > >TJ - You attempted to say that for PCI, and then it was shown that there's >clear language regarding compensating controls that could easily be >considered applicable. I haven't had the honor of running an IPv6-enabled >system through a PCI compliance audit, but have little doubt that it will >happen shortly and will require auditor education just like every other >technology introduction. First off - me neither; this is related to my realm, but not within it. Secondly - we largely agree; although I think the level of "auditor education" that will need to occur is more burdensome than might be expected - partially due to lack of underlying guidance. Again, I don't live and breathe compliance, but the best I have seen is that some have started developing these procedures/guidelines. Started. Additionally, I suspect (but do not know that) the compensating control clause is meant to be a special case ... I'd love to hear more ... >I run a data center which specializes in secure, compliant managed services, >and have been through hundreds of audits in support of our clients which >include federal civilian, federal defense, health care, and financial >services firms. There are very few IT standards which have precise protocol >or address requirements embedded in them, and there is almost always an >opportunity to provide compensating controls where necessary. If you've got >an example from one of the above compliance frameworks to the contrary that >would actually preclude IPv6 deployment, please cite it. Sure, general language meant to be semi-technology-independent. Perhaps not outright preclude deployment altogether, but certainly cause (possibly rather expensive) delays or complications. Note - I am merely pseudo-quoting from what auditors and policy people have told me and my colleagues, through the course of several briefings. Allow me to more directly quote one of my colleagues: * Current C&A auditors are not checking for IPv6-based vulnerabilities. They do not understand the process or have the tools to do IPv6 C&A. * IPv6 is already deployed in a surprising number of IT systems, networks, and software - we find it operating in audits of agencies and enterprises that are "not deploying IPv6" * Is your FISMA C&A complete/valid without considering IPv6? Note that the last bullet is a somewhat rhetorical question - the answer is obviously no, but you might be surprised to see the look on some peoples' faces when you tell them that ... Or let's take this - http://72.34.43.90/IPV6/usipv6_reston_2004/thu/Kruger-Schifalacqua.pdf ... and while the goal is to show that/how it is possible to obtain your ATO, I think it makes a strong case in the opposite direction. How can you be assured that you live up to "Do no harm" when the definition of harm, based on the (until very recently) absent standards upon which to make this basis? Or with a staff (local network or auditor) that is not IPv6 savvy at day -1 (meaning prior to the expected deployment of IPv6). (And in fact, after just re-reading it - this presentation seems to make a case for disabling DAD (albeit in a specific case) - something that violates the protocol spec as well as the DoD APL requirements ... so who wins that decision?) To take it a step further (and perhaps be over-simplsitic): The guidance to "disable all unused protocols and services" applies. So, if you aren't using IPv6 today it must be off. If you want to turn it on, you must redo your C&A. That costs money, therefore doesn't happen - atleast not "soon". Therefore, no IPv6. I would love to hear more from those who have done C&A (of any flavor) on an IPv6 enabled network - specifically, was IPv6 actually considered/evaluated and any problems it caused for the process. >> (In other words (again, generally speaking) - if you run IPv6, your >> current C&A (or perhaps your CTO (Certificate To Operate)) is >> invalid). > >Sure... change your network, and you need to update your C&A package as part >of maintaining your ATO. It's up to your DAA as to whether they want to use >IPv6 prior to equipment being certified under the DoD IPv6 Profile. But that is my point - Do any of the compliance frameworks / requirements / audit standards today address IPv6, or detail how it could be implemented in such a fashion as to 'pass' an audit (including the "in-house" / consultant-specific audit guidelines)? If it can be done, but is solely a "you and your (current) auditor figure it out, on a case by case basis, every time" I would argue that that is not good enough for the general case. And while I agree with you, "any change = redo" I would argue that not everyone realizes that all of their C&A work will need to be re-done in order to retain their CTOs/ATOs if they move forward with any sort of IPv6 deployment. I have heard the gasps (I didn't see the faces, that was a coworker of mine did and said it was amusing - in a sad way.) Thanks ... /TJ From jfbeam at gmail.com Tue Feb 10 15:41:41 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 10 Feb 2009 16:41:41 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <00cf01c98b24$efe42680$cfac7380$@com> References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <00cf01c98b24$efe42680$cfac7380$@com> Message-ID: On Mon, 09 Feb 2009 21:11:50 -0500, TJ wrote: > Your routers fail frequently? And does your traffic continue to get > forwarded? Perhaps through another router? More frequently than the DHCP server, but neither are "frequent" events. Cisco's software is not 100% perfect, and when you plug it into moderately unstable things like phone lines (DSL) and cable networks, those little bugs cause reloads -- you'd think they'd have better error handling, but they don't. (I don't buy millions in equipment from Cisco so they don't care about my problems.) While I could use backup links, flip-floping between ISPs with different addresses is not ideal (and that's as true for v6 as v4.) > Why is there a problem with RAs being the first step, possibly including > prefix info or possibly just hinting @ DHCPv6? Because it doesn't fit the needs of *every* network. In fact, it's only "good enough" for very few networks. As such it just adds more useless layers of bloat. > Well, as it stands now the RA isn't useless. ... > Also, it is not true in every case that hosts need a "lot more" than an > address. > In many cases all my machine needs is an address, default gateway and DNS > server (cheat off of v4 | RFC5006 | Stateless DHCPv6). It's useless. It does NOT provide enough information alone for a host to function. In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me. --Ricky From elparis at cisco.com Tue Feb 10 15:43:06 2009 From: elparis at cisco.com (Eloy Paris) Date: Tue, 10 Feb 2009 16:43:06 -0500 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH Message-ID: <20090210214306.GA16029@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rob, Eloy Paris from the Cisco PSIRT here. Please see below (inline) for some comments regarding the issue you brought up in your email to the cisco-nsp and nanog mailing lists this past Jan. 16th: On Fri Jan 16 07:57:52 2009, Rob Shakir wrote: > Strict RFC 4893 (4-byte ASN support) BGP4 implementations are > vulnerable to a session reset by distant (not directly connected) > ASes. This vulnerability is a feature of the standard, and unless > immediate action is taken an increasingly significant number of > networks will be open to attack. Accidental triggering of this > vulnerability has already been seen in the wild, although the limited > number of RFC 4893 deployments has limited its effect. > > Summary: > It is possible to cause BGP sessions to remotely reset by injecting > invalid data into the AS4_PATH attribute provided to store 4-byte ASN > paths. Since AS4_PATH is an optional transitive attribute, the invalid > data will be transited through many intermediate ASes which will not > examine the content. To be vulnerable, an operator does not have to > be actively using 4-byte AS support. This problem was first reported > by Andy Davidson on NANOG in December 2008 [0], furthermore we have > been able to demonstrate that a device running Cisco IOS release > 12.0(32)S12 behaves as per this description. > > Details: [...] Cisco Bug CSCsx10140 was filed for Cisco IOS. Cisco IOS behaves exactly as you described - upon receipt of AS_CONFED_SEQUENCE data in the AS4_PATH attribute IOS will send a NOTIFICATION message to the peer, which causes a termination of the BGP session. After the fix for this bug IOS will ignore AS_CONFED_SEQUENCE data in the AS4_PATH attribute of received BGP UPDATE messages and continue to process the UPDATE. This is the new behavior that the revised RFC 4893 will require. CSCsx18598 was filed for Cisco IOS XR. Cisco IOS XR doesn't reset the session but accepts and forwards the invalid AS4_PATH data, so this bug was filed to change this behavior. CSCsx23179 was filed for Cisco NX-OS (for the Nexus switches.) Cisco NX-OS behaves like IOS (it will reset the BGP session when it sees AS_CONFED_SEQUENCE data in the AS4_PATH attribute), and this bug was filed to change this and have the BGP implementation in Cisco NX-OS follow the revised RFC 4893. The Release Notes for each bug may have some additional information. These are available via the Bug Toolkit on cisco.com (http://tools.cisco.com/Support/BugToolKit) To date, the only version of Cisco IOS that supports 4-byte AS numbers is 12.0(32)S12, released in late December. A fix to the 12.0(32)Sxx branch has been committed so the next 12.0(32)S-based release will have the fix. 12.0(32)SY8 is coming out soon, and it will also have support for 4-byte AS numbers, as well as the fix for the problem. Thanks for bringing attention to this issue and for working with us, specifically with the Cisco TAC, to get to the bottom of it and test the proposed fix. Cheers, - -- Eloy Paris Cisco PSIRT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmR9OoACgkQagjTfAtNY9jv5ACgg3fKuuWKv38h8F8d8QHBML5J CTsAnAnGMB/fBIQhk5z4E922JlhHVU5A =FSOP -----END PGP SIGNATURE----- From zaid at zaidali.com Tue Feb 10 16:07:09 2009 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 10 Feb 2009 14:07:09 -0800 (PST) Subject: unsolicited name transfers from Godaddy In-Reply-To: <11735072.7451234303592457.JavaMail.zaid@turing-2.local> Message-ID: <9633247.7471234303627585.JavaMail.zaid@turing-2.local> I have been receiving a high number of unsolicited domain transfer requests from Godaddy and have also written to Godaddy support about unsolicited domain transfer requests. Since I am not a Godaddy customer I got a standard talk to the hand. I have colleagues confirming that some similar chatter is also happening in the ICANN space with respect to Godaddy. Are folks here experiencing this also? Thanks, Zaid From trejrco at gmail.com Tue Feb 10 16:08:43 2009 From: trejrco at gmail.com (TJ) Date: Tue, 10 Feb 2009 17:08:43 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <00cf01c98b24$efe42680$cfac7380$@com> Message-ID: <002801c98bcc$29145f40$7b3d1dc0$@com> >> Your routers fail frequently? And does your traffic continue to get >> forwarded? Perhaps through another router? > >More frequently than the DHCP server, but neither are "frequent" events. >Cisco's software is not 100% perfect, and when you plug it into moderately >unstable things like phone lines (DSL) and cable networks, those little bugs >cause reloads -- you'd think they'd have better error handling, but they >don't. (I don't buy millions in equipment from Cisco so they don't care >about my problems.) While I could use backup links, flip-floping between >ISPs with different addresses is not ideal (and that's as true for >v6 as v4.) But my real point was if the router is failed, traffic isn't being forwarded regardless of how the host got the information ... correct? And vendor support issues are a layer 8-11 problem ... no layer 3 fix for that! (8-11 == people politics religion money ... in no particular order) >> Why is there a problem with RAs being the first step, possibly >> including prefix info or possibly just hinting @ DHCPv6? > >Because it doesn't fit the needs of *every* network. In fact, it's only >"good enough" for very few networks. As such it just adds more useless >layers of bloat. Obviously we disagree, fundamentally. >> Well, as it stands now the RA isn't useless. >... >> Also, it is not true in every case that hosts need a "lot more" than >> an address. >> In many cases all my machine needs is an address, default gateway and >> DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6). > >It's useless. It does NOT provide enough information alone for a host to >function. In your own words, you need a DNS server. That is NOT provided >by RA thus requires yet another system to get that bit of configuration to >the host -- either entered manually, DHCPv6, or from IPv4 network >configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. >We've had a system to provide *ALL* the information a host needs or wants in >the IPv4 world for years. Why it's not good enough for IPv6 is beyond me. Technically, that is a gap RFC5006 would fill - once supported, which should have been long before now but too late for that, eh? And I think we also disagree on a fundamental aspect, specifically - I see it this way: 1) the RAs are there primarily to allow a router to provide information about itself to the hosts on the link a) which becomes the default gateway from the hosts' perspective 2) Everything after that is a separate thing, namely - host addressing and "other" configuration a) which could be SLAAC, by including a prefix in the RA ... and maybe a DNS server option, someday. -) and maybe Stateless DHCPv6 as well, for the DNS or other missing info b) which could be DHCPv6, providing all of the addressing and config info (but not router info) I think the key factor to our disagreement is that I think it makes great sense for the router to provide information about itself to the hosts, and you'd rather it be centralized. I don't really care either way, to be honest - it just seems to make good sense (to me) the way it works now. If I understand correctly the answer, from your standpoint, would be to author an RFC specifying a default gateway option for DHCPv6 (and maybe a prefix length option as well?). And then get DHCPv6 client functionality itself, and this option, more widely supported (and in fact, "on by default"). As to "why it's not good enough" ... well, suffice it to say this debate has raged for a LOOOONG time and apparently sufficient consensus (for reasons good or ill) was reached at some point for the way it is now. Build consensus to change that (factoring in the pain it would cause to current deployments) ... maybe starting off small, with just defining the option and convincing a major vendor or two to implement it ... if the world agrees, it will migrate to working that way ... isn't that how this whole open standards process is supposed to work? (OK, that last question was a bit rhetorical and was not meant to spark a debate about this being the IETF vs the IVTF vs the ______ etc. etc. Sorry!) Failing that (or while that is ongoing?) ... we have what we have. And it does indeed work, today, for almost all * cases. So let's get deploying, go team! * - as discussed at length on this list and others /TJ "Be conservative in what you send and liberal in what you accept." --Jon Postel "The future belongs to those who see possibilities before they become obvious." --unknown "In essentials, unity; in non-essentials, liberty; in all things, charity" --various "Everyone's a hero in their own way, in their own not that heroic way." --Joss Whedon From nanog at daork.net Tue Feb 10 16:17:01 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 11 Feb 2009 11:17:01 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: <75cb24520902091820l29f7e7cbm5322225d8ec5ebdb@mail.gmail.com> References: <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <75cb24520902091820l29f7e7cbm5322225d8ec5ebdb@mail.gmail.com> Message-ID: On 10/02/2009, at 3:20 PM, Christopher Morrow wrote: >>> IPv6 it's easier, but you're still limiting the uptime of your >>> system to >>> that of the DHCPv6 server. Router advertisements is much more >>> robust. > > 'more robust'... except it doesnt' actually get a device into a usable > state without admins walking around to each machine and poking at them > randomly. if you have 5 machines that's cool, knock yourself out, if > you have 5000 or 50000 you are in a completely different ballpark of > work. DHCP servers do this today, the servers pass out all the > relevant bits require for dynamic-addressed and static-addressed > systems, they can be rebooted, moved, re-addressed, re-homed... all > without the masses of clients stopping their work. I believe you are mis-interpreting Iljitsch's comments. I believe he is talking about SLAAC, you are talking about *no* DHCPv6. The difference is, SLAAC can still use DHCPv6 to get configuration information. If the DHCPv6 server goes away when using SLAAC for addressing, configuration information is already there. >>> I have a lot of problems with DHCP and most people don't _need_ >>> it. Still, > > can you explain how 'most people don't need it'?? is that because most > people have an admin to go configure their DNS servers in their > resolver config?? Consumer Internet users are a great example of this, > if necessary an ISP can pass out new DNS servers, and in 8-10 days > easily remove the old DNS servers from the network, or move them to > another place in the network seemlessly without having to touch each > consumer device. > > Why would anyone NOT want that?? what replaces that option in current > RA deployments? Again, this seems to be confusion with SLAAC vs. "no DHCPv6 what so ever". I could be wrong though - I don't want to be putting words in to Iljitsch's mouth. -- Nathan Ward From matthias at leisi.net Tue Feb 10 16:31:38 2009 From: matthias at leisi.net (Matthias Leisi) Date: Tue, 10 Feb 2009 23:31:38 +0100 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <200902090007.n1907qY2069724@drugs.dv.isc.org> References: <200902090007.n1907qY2069724@drugs.dv.isc.org> Message-ID: <4992004A.9030508@leisi.net> Mark Andrews schrieb: > I don't see any reason to complain based on those numbers. > It's just a extremely high growth period due to technology > change over bring in new functionality. OTOH, Verizon is not the only provider of smartphone connectivity in the world. Most of them try to be "good citizens" and do not waste a scarce resource (IPv4 space). If more providers would act like Verizon, we would have run out of IPv4 addresses a long time ago (whether or not that is a good or bad thing is left as an exercise to the reader). -- Matthias From patrick at ianai.net Tue Feb 10 16:37:46 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 10 Feb 2009 17:37:46 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <4992004A.9030508@leisi.net> References: <200902090007.n1907qY2069724@drugs.dv.isc.org> <4992004A.9030508@leisi.net> Message-ID: <5918C875-E801-4657-8EBF-3A63EED88A0B@ianai.net> On Feb 10, 2009, at 5:31 PM, Matthias Leisi wrote: > Mark Andrews schrieb: > >> I don't see any reason to complain based on those numbers. >> It's just a extremely high growth period due to technology >> change over bring in new functionality. > > OTOH, Verizon is not the only provider of smartphone connectivity in > the > world. Most of them try to be "good citizens" and do not waste a > scarce > resource (IPv4 space). You mean like the 10.x.x.x addresses give to all iPhones in the US? Wait, I thought NAT was bad? So who is the "good citizen"? -- TTFN, patrick > If more providers would act like Verizon, we would have run out of > IPv4 > addresses a long time ago (whether or not that is a good or bad > thing is > left as an exercise to the reader). > > -- Matthias > > From nanog at daork.net Tue Feb 10 16:38:59 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 11 Feb 2009 11:38:59 +1300 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: References: <49555.1233631443@turing-police.cc.vt.edu> <76C8FA39-19A6-4C5B-87DC-9789B39590EC@ianai.net> <498A2DED.5040601@rollernet.us> <9B5CD04C-87BB-497C-867D-FE7A5E3D8B11@muada.com> <4C93BEB8-9583-49F8-8692-828447D0D63C@muada.com> <00cf01c98b24$efe42680$cfac7380$@com> Message-ID: On 11/02/2009, at 10:41 AM, Ricky Beam wrote: > It's useless. It does NOT provide enough information alone for a > host to function. In your own words, you need a DNS server. That > is NOT provided by RA thus requires yet another system to get that > bit of configuration to the host -- either entered manually, DHCPv6, > or from IPv4 network configuration (ie. DHCP!) Forcing this BS on > the world is a colossal waste. We've had a system to provide *ALL* > the information a host needs or wants in the IPv4 world for years. > Why it's not good enough for IPv6 is beyond me. You are correct, alone RA does not provide enough for a host to function. We have two mechanisms of providing addressing information to hosts - SLAAC and DHCPv6. How do you, as a network manager, tell hosts which one to use? RA performs this function. Without RA you need to go around all the machines and manually configure how they will discover what addresses to use. That seems a bit silly, and going around every machine is something you have already indicated you don't want to do. RA has two functions - telling your hosts which of SLAAC and DHCPv6 to use for addressing information, and providing addressing information in the case of SLAAC. Also, in the case of SLAAC, it might hint to the client to get additional information from DHCPv6 - DNS servers and so on - in this case it will not get addressing information. Perhaps you have a problem with SLAAC? That is fine, you might not want to use it. Other people *do* want to use it, and RA is the best place to signal which of SLAAC and DHCPv6 a host should use for addressing. Please do not use blanket comments that RA is bad if you actually mean SLAAC. Yes, if we do not have SLAAC then we don't need RA, because hosts will always know to use DHCPv6. However, many people do want SLAAC, so we need RA. If you have an idea for alternative to RA for indicating whether to use SLAAC or DHCPv6 then I encourage you to get involved in the IETF and get your idea written up. If you would like to deprecate/fix SLAAC because you have a problem with it then again, I encourage you to get involved in the IETF. -- Nathan Ward From cra at WPI.EDU Tue Feb 10 16:39:11 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 10 Feb 2009 17:39:11 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <4992004A.9030508@leisi.net> References: <200902090007.n1907qY2069724@drugs.dv.isc.org> <4992004A.9030508@leisi.net> Message-ID: <20090210223911.GK24542@angus.ind.WPI.EDU> On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote: > Mark Andrews schrieb: > > I don't see any reason to complain based on those numbers. > > It's just a extremely high growth period due to technology > > change over bring in new functionality. > > OTOH, Verizon is not the only provider of smartphone connectivity in the > world. Most of them try to be "good citizens" and do not waste a scarce > resource (IPv4 space). I disagree that using global IPv4 space is a "waste". Every device deserves to have "real" internet connectivity and not this NAT crap. From davet1 at gmail.com Tue Feb 10 16:52:52 2009 From: davet1 at gmail.com (Dave Temkin) Date: Tue, 10 Feb 2009 14:52:52 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <20090210223911.GK24542@angus.ind.WPI.EDU> References: <200902090007.n1907qY2069724@drugs.dv.isc.org> <4992004A.9030508@leisi.net> <20090210223911.GK24542@angus.ind.WPI.EDU> Message-ID: <49920544.6@gmail.com> Chuck Anderson wrote: > On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote: > >> Mark Andrews schrieb: >> >>> I don't see any reason to complain based on those numbers. >>> It's just a extremely high growth period due to technology >>> change over bring in new functionality. >>> >> OTOH, Verizon is not the only provider of smartphone connectivity in the >> world. Most of them try to be "good citizens" and do not waste a scarce >> resource (IPv4 space). >> > > I disagree that using global IPv4 space is a "waste". Every device > deserves to have "real" internet connectivity and not this NAT crap. > > Why must it be always "real" versus NAT? 99% of users don't care one way or another. Would it be so hard for the carrier to provide a switch between NAT and "real" IP if the user needs or wants it? From jcurran at mail.com Tue Feb 10 16:56:15 2009 From: jcurran at mail.com (John Curran) Date: Tue, 10 Feb 2009 17:56:15 -0500 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space In-Reply-To: <001b01c98bc6$cba4f220$62eed660$@com> References: "Your message of Mon, 09 Feb 2009 21:27:59 CDT." <00df01c98b27$3181b7e0$948527a0$@com> <200902100316.n1A3GAIW038167@drugs.dv.isc.org> <000a01c98b86$d40c8a80$7c259f80$@com> <7D95E111-F755-43DC-AA8C-5F28A35FCE9B@mail.com> <001b01c98bc6$cba4f220$62eed660$@com> Message-ID: <92846044-1660-481B-ADCA-808C77749E3E@mail.com> On Feb 10, 2009, at 4:30 PM, TJ wrote: > > But that is my point - Do any of the compliance frameworks / > requirements / > audit standards today address IPv6, or detail how it could be > implemented in > such a fashion as to 'pass' an audit (including the "in-house" / > consultant-specific audit guidelines)? If it can be done, but is > solely a > "you and your (current) auditor figure it out, on a case by case > basis, > every time" I would argue that that is not good enough for the > general case. Compliance frameworks are generally technology agonistic. They tell you "have an information boundary for your system", "manage your user identifiers", etc. Aside from the DoD IA STIGs (and small handful of NIST areas such as encryption), you don't find specifications that particular protocols or technology is required. They don't require major updating for IPv6 because there's very little IPv4 specific contents in them already. That's not to say that moving an application to IPv6 is trivial from a compliance and security perspective, as you've still got a pile of mandatory firewall, load-balancing, and IDS infrastructure that needs to handle IPv6 correctly before you can get started. In organizations that are planning ahead, this is common security control infrastructure, and gets done once centrally rather than each little component. > And while I agree with you, "any change = redo" I would argue that not > everyone realizes that all of their C&A work will need to be re-done > in > order to retain their CTOs/ATOs if they move forward with any sort > of IPv6 > deployment. I have heard the gasps (I didn't see the faces, that > was a > coworker of mine did and said it was amusing - in a sad way.) Look, systems change. Change your database software, and you get to update the corresponding pieces of the C&A package. Add IPv6, you have to update the network portions. This shouldn't be a surprise to anyone, and it certainly doesn't mean "all of their C&A work will need to be re-done". /John From Valdis.Kletnieks at vt.edu Tue Feb 10 16:57:49 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 10 Feb 2009 17:57:49 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: Your message of "Tue, 10 Feb 2009 14:52:52 PST." <49920544.6@gmail.com> References: <200902090007.n1907qY2069724@drugs.dv.isc.org> <4992004A.9030508@leisi.net> <20090210223911.GK24542@angus.ind.WPI.EDU> <49920544.6@gmail.com> Message-ID: <27541.1234306669@turing-police.cc.vt.edu> On Tue, 10 Feb 2009 14:52:52 PST, Dave Temkin said: > Why must it be always "real" versus NAT? 99% of users don't care one > way or another. Would it be so hard for the carrier to provide a switch > between NAT and "real" IP if the user needs or wants it? You're almost always better off not providing a user-accessible switch. Especially not a shiny one labeled "Do not touch unless you know what you are doing". (FWIW, this is exactly the same issue as "block port 25 unless user requests opt-out from the block") -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From patrick at ianai.net Tue Feb 10 17:00:37 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 10 Feb 2009 18:00:37 -0500 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <49920544.6@gmail.com> References: <200902090007.n1907qY2069724@drugs.dv.isc.org> <4992004A.9030508@leisi.net> <20090210223911.GK24542@angus.ind.WPI.EDU> <49920544.6@gmail.com> Message-ID: <8143C0BF-25EB-4E78-A49F-602E637B7D61@ianai.net> On Feb 10, 2009, at 5:52 PM, Dave Temkin wrote: > Chuck Anderson wrote: >> On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote: >> >>> Mark Andrews schrieb: >>> >>>> I don't see any reason to complain based on those numbers. >>>> It's just a extremely high growth period due to technology >>>> change over bring in new functionality. >>>> >>> OTOH, Verizon is not the only provider of smartphone connectivity >>> in the >>> world. Most of them try to be "good citizens" and do not waste a >>> scarce >>> resource (IPv4 space). >>> >> >> I disagree that using global IPv4 space is a "waste". Every device >> deserves to have "real" internet connectivity and not this NAT crap. >> > Why must it be always "real" versus NAT? 99% of users don't care > one way or another. Would it be so hard for the carrier to provide > a switch between NAT and "real" IP if the user needs or wants it? Lots of providers do. Sometimes the choice between static & dynamic is bundled with the choice between NAT & "real" on some broadband providers. I've also seen hotels do it, and even charge extra for it. (Yes, I paid. ;) -- TTFN, patrick From Mark_Andrews at isc.org Tue Feb 10 17:07:39 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 11 Feb 2009 10:07:39 +1100 Subject: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] In-Reply-To: Your message of "Tue, 10 Feb 2009 16:41:41 CDT." Message-ID: <200902102307.n1AN7d15032828@drugs.dv.isc.org> In message , "Ricky Beam" writes: > On Mon, 09 Feb 2009 21:11:50 -0500, TJ wrote: > > Your routers fail frequently? And does your traffic continue to get > > forwarded? Perhaps through another router? > > More frequently than the DHCP server, but neither are "frequent" events. > Cisco's software is not 100% perfect, and when you plug it into moderately > unstable things like phone lines (DSL) and cable networks, those little > bugs cause reloads -- you'd think they'd have better error handling, but > they don't. (I don't buy millions in equipment from Cisco so they don't > care about my problems.) While I could use backup links, flip-floping > between ISPs with different addresses is not ideal (and that's as true for > v6 as v4.) > > > Why is there a problem with RAs being the first step, possibly including > > prefix info or possibly just hinting @ DHCPv6? > > Because it doesn't fit the needs of *every* network. In fact, it's only > "good enough" for very few networks. As such it just adds more useless > layers of bloat. Good. You admit it fits the needs of some networks. > > Well, as it stands now the RA isn't useless. > ... > > Also, it is not true in every case that hosts need a "lot more" than an > > address. > > In many cases all my machine needs is an address, default gateway and DNS > > server (cheat off of v4 | RFC5006 | Stateless DHCPv6). > > It's useless. It does NOT provide enough information alone for a host to > function. Hogwash. The only thing needed for I used from DHCP on my laptop is router, address and netmask. I actually discard anything else that is offered. RA's meet my needs perfectly fine. In fact they do a better job than DHCP for my needs. I don't trust dns servers returned by dhcp. Lots of them don't offer the level of functionality I require. I run my own recursive resolver to get the level of functionality I require. > In your own words, you need a DNS server. That is NOT provided > by RA thus requires yet another system to get that bit of configuration to > the host -- either entered manually, DHCPv6, or from IPv4 network > configuration (ie. DHCP!) Forcing this BS on the world is a colossal > waste. We've had a system to provide *ALL* the information a host needs > or wants in the IPv4 world for years. Why it's not good enough for IPv6 > is beyond me. > > --Ricky > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From davet1 at gmail.com Tue Feb 10 17:29:01 2009 From: davet1 at gmail.com (Dave Temkin) Date: Tue, 10 Feb 2009 15:29:01 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <8143C0BF-25EB-4E78-A49F-602E637B7D61@ianai.net> References: <200902090007.n1907qY2069724@drugs.dv.isc.org> <4992004A.9030508@leisi.net> <20090210223911.GK24542@angus.ind.WPI.EDU> <49920544.6@gmail.com> <8143C0BF-25EB-4E78-A49F-602E637B7D61@ianai.net> Message-ID: <49920DBD.3020907@gmail.com> Patrick W. Gilmore wrote: > On Feb 10, 2009, at 5:52 PM, Dave Temkin wrote: >> Chuck Anderson wrote: >>> On Tue, Feb 10, 2009 at 11:31:38PM +0100, Matthias Leisi wrote: >>> >>>> Mark Andrews schrieb: >>>> >>>>> I don't see any reason to complain based on those numbers. >>>>> It's just a extremely high growth period due to technology >>>>> change over bring in new functionality. >>>>> >>>> OTOH, Verizon is not the only provider of smartphone connectivity >>>> in the >>>> world. Most of them try to be "good citizens" and do not waste a >>>> scarce >>>> resource (IPv4 space). >>>> >>> >>> I disagree that using global IPv4 space is a "waste". Every device >>> deserves to have "real" internet connectivity and not this NAT crap. >>> >> Why must it be always "real" versus NAT? 99% of users don't care one >> way or another. Would it be so hard for the carrier to provide a >> switch between NAT and "real" IP if the user needs or wants it? > > Lots of providers do. Sometimes the choice between static & dynamic > is bundled with the choice between NAT & "real" on some broadband > providers. > > I've also seen hotels do it, and even charge extra for it. (Yes, I > paid. ;) > Exactly. I've seen this as well in both instances but haven't seen it on mobile phones. It's something so obscure that you're going to have to really want it to turn it on. I don't think the Port 25 example holds much water here. -Dave From scott at doc.net.au Tue Feb 10 17:41:53 2009 From: scott at doc.net.au (Scott Howard) Date: Tue, 10 Feb 2009 15:41:53 -0800 Subject: 97.128.0.0/9 allocation to verizon wireless In-Reply-To: <49920DBD.3020907@gmail.com> References: <200902090007.n1907qY2069724@drugs.dv.isc.org> <4992004A.9030508@leisi.net> <20090210223911.GK24542@angus.ind.WPI.EDU> <49920544.6@gmail.com> <8143C0BF-25EB-4E78-A49F-602E637B7D61@ianai.net> <49920DBD.3020907@gmail.com> Message-ID: On Tue, Feb 10, 2009 at 3:29 PM, Dave Temkin wrote: > Exactly. I've seen this as well in both instances but haven't seen it on > mobile phones. It's something so obscure that you're going to have to > really want it to turn it on. I don't think the Port 25 example holds much > water here. Many/most GSM/GPRS/etc operators will have multiple APN's - one which is setup for NAT, and the other which gives a public IP address. By default, most "dumb" phones will use the former. Data cards will use the latter, and smartphones seem to be split between the two - although obviously it will vary between providers. Scott. From ops.lists at gmail.com Tue Feb 10 20:43:28 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Feb 2009 08:13:28 +0530 Subject: Is whois.apnic.net down? (IPv6-MW) In-Reply-To: <20090211074300.q9i50jij40wk4wk0@web1.nswh.com.au> References: <20090210164815.192D138D600@lampinc.com> <20090211074300.q9i50jij40wk4wk0@web1.nswh.com.au> Message-ID: On Wed, Feb 11, 2009 at 2:13 AM, wrote: > 9 33 ms 33 ms 33 ms 203.119.76.66 > 10 36 ms 35 ms 35 ms whois.apnic.net [202.12.29.13] > > Trace complete. > > It's reachable from where I'm sitting (NSW) Reachable just fine (from my dsl box in India, and from my personal colo near los angeles) srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From joe at via.net Tue Feb 10 21:16:39 2009 From: joe at via.net (joe mcguckin) Date: Tue, 10 Feb 2009 19:16:39 -0800 Subject: World famous cabling disasters? Message-ID: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> I'm looking for a couple of pictures of the worst cabling infrastructure ever seem. One Wilshire meet me room comes to mind. Anyone got any links to their photo albums, etc? Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax From streiner at cluebyfour.org Tue Feb 10 21:24:30 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 10 Feb 2009 22:24:30 -0500 (EST) Subject: World famous cabling disasters? In-Reply-To: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> Message-ID: On Tue, 10 Feb 2009, joe mcguckin wrote: > I'm looking for a couple of pictures of the worst cabling infrastructure ever > seem. One Wilshire meet me room comes to mind. > Anyone got any links to their photo albums, etc? You might find some links in the archives. I've seen a few in person that still make me cringe. jms From patrick at ianai.net Tue Feb 10 21:29:44 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 10 Feb 2009 22:29:44 -0500 Subject: World famous cabling disasters? In-Reply-To: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> Message-ID: <54557D5C-6B77-43D3-A3F1-84A3C91B7C20@ianai.net> On Feb 10, 2009, at 10:16 PM, joe mcguckin wrote: > I'm looking for a couple of pictures of the worst cabling > infrastructure ever seem. One Wilshire meet me room comes to mind. > Anyone got any links to their photo albums, etc? I've always considered this the worst: Google shows lots of pictures, such as . -- TTFN, patrick From repstein at chello.at Tue Feb 10 22:33:39 2009 From: repstein at chello.at (Randy Epstein) Date: Tue, 10 Feb 2009 23:33:39 -0500 Subject: World famous cabling disasters? In-Reply-To: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> Message-ID: Joe, >I'm looking for a couple of pictures of the worst cabling >infrastructure ever seem. One Wilshire meet me room comes to mind. >Anyone got any links to their photo albums, etc? The One Wilshire pictures you are referring to were within this Wired article: http://www.wired.com/techbiz/it/multimedia/2008/03/gallery_one_wilshire?slid e=3&slideView=2 Also there are some great photos at http://www.darkroastedblend.com/2007/03/really-bad-wiring-jobs_20.html >Joe McGuckin >ViaNet Communications Regards, Randy From elmi at 4ever.de Wed Feb 11 02:47:02 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 11 Feb 2009 09:47:02 +0100 Subject: World famous cabling disasters? In-Reply-To: <54557D5C-6B77-43D3-A3F1-84A3C91B7C20@ianai.net> References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> <54557D5C-6B77-43D3-A3F1-84A3C91B7C20@ianai.net> Message-ID: <20090211084701.GA91662@ronin.4ever.de> patrick at ianai.net (Patrick W. Gilmore) wrote: > >I'm looking for a couple of pictures of the worst cabling > >infrastructure ever seem. One Wilshire meet me room comes to mind. > >Anyone got any links to their photo albums, etc? > > I've always considered this the worst: > > Still looks like a pasta factory... From Stephen.Bailey at uk.fujitsu.com Wed Feb 11 04:18:03 2009 From: Stephen.Bailey at uk.fujitsu.com (Bailey Stephen) Date: Wed, 11 Feb 2009 10:18:03 -0000 Subject: World famous cabling disasters? In-Reply-To: <54557D5C-6B77-43D3-A3F1-84A3C91B7C20@ianai.net> References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> <54557D5C-6B77-43D3-A3F1-84A3C91B7C20@ianai.net> Message-ID: That's quality engineering Great pic Stephen Bailey - Senior Lead Systems Engineer Network Operations - ISP & DSL FUJITSU + Infinity House, Mallard Way, Crewe Business Park, Crewe, Cheshire, CW1 6ZQ ( Tel: +44 (0) 870 325 3457 or Internally: 7225 3457 ( Fax: +44 (0) 870 325 3622 or Internally: 7225 3622 : E-mail: stephen.bailey at uk.fujitsu.com " Web: http://services.fujitsu.com/ Fujitsu Services Limited, Registered in England no 96056, Registered Office 22 Baker Street, London, W1U 3BW This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free. -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: 11 February 2009 03:30 To: NANOG list Subject: Re: World famous cabling disasters? On Feb 10, 2009, at 10:16 PM, joe mcguckin wrote: > I'm looking for a couple of pictures of the worst cabling > infrastructure ever seem. One Wilshire meet me room comes to mind. > Anyone got any links to their photo albums, etc? I've always considered this the worst: Google shows lots of pictures, such as . -- TTFN, patrick From ggm at apnic.net Wed Feb 11 05:46:11 2009 From: ggm at apnic.net (George Michaelson) Date: Wed, 11 Feb 2009 21:46:11 +1000 Subject: Call for data: IPv6 enabled service logfiles for analysis Message-ID: <02D72143-A7D7-4175-8A5A-7EC7EC68F1D9@apnic.net> Call for data: IPv6 enabled service logfile analysis APNIC is seeking operators of high-traffic webhosts, and other public facing services who can provide logfiles for their IPv6 enabled instances. Our intention is to analyse these for the distribution of IPv4, and the various sub-classes of IPv6 (native, tunnelled, Teredo, 6to4). APNIC will of course respect client privacy and sign an NDA, only abstracted data outcomes would be presented from any participant. -All participants would be acknowledged for their support in any presentations. While our preference is for access to raw logs, there may be people out there who cannot share this due to contractual or other restrictions. If you are willing to filter data according to our example Perlcode, we'd be happy to receive abstracted data if neccessary. Our tools assume the apache 'combined' log format, or things which can be simply converted to a close analogue. If anyone is interested in participating in the data collection exercise, please contract research at apnic.net -George From mathias.wolkert at gmail.com Wed Feb 11 07:06:09 2009 From: mathias.wolkert at gmail.com (Mathias Wolkert) Date: Wed, 11 Feb 2009 14:06:09 +0100 Subject: Network diagram software Message-ID: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> I'd like to know what software people are using to document networks. Visio is obvious but feels like a straight jacket to me. I liked netviz but it seems owned by CA and unsupported nowadays. What do you use? /Tias From karnaugh at karnaugh.za.net Wed Feb 11 07:08:51 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 11 Feb 2009 15:08:51 +0200 Subject: Network diagram software In-Reply-To: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> Message-ID: <4992CDE3.2000907@karnaugh.za.net> Mathias Wolkert wrote: > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. Omnigrafle and Dia are all I can add to your list From hescominsoon at emmanuelcomputerconsulting.com Wed Feb 11 07:10:18 2009 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Wed, 11 Feb 2009 08:10:18 -0500 Subject: Network diagram software In-Reply-To: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> Message-ID: <4992CE3A.1060405@emmanuelcomputerconsulting.com> On 2/11/2009 8:06 AM, Mathias Wolkert wrote: > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. > > What do you use? > > /Tias > > network notepad From mvh at hosteurope.de Wed Feb 11 07:12:04 2009 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 11 Feb 2009 14:12:04 +0100 Subject: Network diagram software In-Reply-To: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> Message-ID: <4992CEA4.8020206@hosteurope.de> Mathias Wolkert wrote: > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. > > What do you use? OmniGraffle is the better Visio. rgds, .m From nanog-post at rsuc.gweep.net Wed Feb 11 07:17:38 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 11 Feb 2009 08:17:38 -0500 Subject: Network diagram software In-Reply-To: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> Message-ID: <20090211131738.GA21066@gweep.net> On Wed, Feb 11, 2009 at 02:06:09PM +0100, Mathias Wolkert wrote: > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. > > What do you use? To what end? The visio or 'presentation software' straightjackets are common for customer-facing presentations. I strongly advise automated solutions for real, day to day use. - dot -> graphviz (http://www.nanog.org/mtg-0210/ppt/stephen.pdf) _ tkined - network-weathermap.com - ...plenty more I don't have at my fingertips on evdo. And just use xpaint/gimp for cleaning up images from those for any internal documentation :-) Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From cmeidinger at sendmail.com Wed Feb 11 08:04:04 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Wed, 11 Feb 2009 15:04:04 +0100 Subject: Network diagram software In-Reply-To: <4992CEA4.8020206@hosteurope.de> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> Message-ID: On 11.02.2009, at 14:12, Malte von dem Hagen wrote: > Mathias Wolkert wrote: >> I'd like to know what software people are using to document networks. >> Visio is obvious but feels like a straight jacket to me. >> I liked netviz but it seems owned by CA and unsupported nowadays. >> What do you use? > > OmniGraffle is the better Visio. Agree fully, I use OmniGraffle extensively and have for a long time. It's worth mentioning that OG can export to Visio-XML format, so you don't lock yourself into the .graffle format forever. Chris From nanog at headcandy.org Wed Feb 11 08:07:47 2009 From: nanog at headcandy.org (Steve Church) Date: Wed, 11 Feb 2009 09:07:47 -0500 Subject: World famous cabling disasters? In-Reply-To: References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> <54557D5C-6B77-43D3-A3F1-84A3C91B7C20@ianai.net> Message-ID: http://images.google.com/images?hl=en&safe=on&q=india+wiring&btnG=Search+Images There are several results for overhead outdoor wiring that just completely boggle the mind and inspire awe. Those pictures are my inspiration whenever I pull cable. Steve On Wed, Feb 11, 2009 at 5:18 AM, Bailey Stephen < Stephen.Bailey at uk.fujitsu.com> wrote: > That's quality engineering > > Great pic > > Stephen Bailey - Senior Lead Systems Engineer > Network Operations - ISP & DSL > > FUJITSU > + Infinity House, Mallard Way, Crewe Business Park, Crewe, Cheshire, CW1 > 6ZQ > ( Tel: +44 (0) 870 325 3457 or Internally: 7225 3457 > ( Fax: +44 (0) 870 325 3622 or Internally: 7225 3622 > : E-mail: stephen.bailey at uk.fujitsu.com > " Web: http://services.fujitsu.com/ > > > Fujitsu Services Limited, Registered in England no 96056, Registered > Office 22 Baker Street, London, W1U 3BW > > This e-mail is only for the use of its intended recipient. Its contents > are subject to a duty of confidence and may be privileged. Fujitsu > Services does not guarantee that this e-mail has not been intercepted > and amended or that it is virus-free. > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: 11 February 2009 03:30 > To: NANOG list > Subject: Re: World famous cabling disasters? > > On Feb 10, 2009, at 10:16 PM, joe mcguckin wrote: > > > I'm looking for a couple of pictures of the worst cabling > > infrastructure ever seem. One Wilshire meet me room comes to mind. > > Anyone got any links to their photo albums, etc? > > I've always considered this the worst: > > > > Google shows lots of pictures, such as p=1836>. > > -- > TTFN, > patrick > > > > From jamie at photon.com Wed Feb 11 08:26:56 2009 From: jamie at photon.com (Jamie Bowden) Date: Wed, 11 Feb 2009 09:26:56 -0500 Subject: World famous cabling disasters? In-Reply-To: References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net><54557D5C-6B77-43D3-A3F1-84A3C91B7C20@ianai.net> Message-ID: <70EC72941042AA48ABE651C40408D9C9C11E40@hal.photon.com> The main telephone room in every commercial tower I've ever had the displeasure of spending any time in was a disaster. I love how the circuits all use the same color wiring between the 100 pair 66 blocks that were so covered in crud that just touching them would turn your fingers black. The closet(s) next to the elevator shafts on any given floor were more of the same on a smaller scale. It's not any particular RBOC, I've seen this same crap in Nynex, Bell Atlantic, GTE, Bell South, and Pac Bell territory. I have no doubt that Southwest Bell, Ameritech and US West sucked just as badly. You don't have to look far or go to exotic places to find this kind of thing. Telco 'techs' are their own special breed of people who will be up against the wall come the day. J -----Original Message----- From: Steve Church [mailto:nanog at headcandy.org] Sent: Wednesday, February 11, 2009 9:08 AM To: NANOG list Subject: Re: World famous cabling disasters? http://images.google.com/images?hl=en&safe=on&q=india+wiring&btnG=Search +Images There are several results for overhead outdoor wiring that just completely boggle the mind and inspire awe. Those pictures are my inspiration whenever I pull cable. Steve On Wed, Feb 11, 2009 at 5:18 AM, Bailey Stephen < Stephen.Bailey at uk.fujitsu.com> wrote: > That's quality engineering > > Great pic > > Stephen Bailey - Senior Lead Systems Engineer > Network Operations - ISP & DSL > > FUJITSU > + Infinity House, Mallard Way, Crewe Business Park, Crewe, Cheshire, CW1 > 6ZQ > ( Tel: +44 (0) 870 325 3457 or Internally: 7225 3457 > ( Fax: +44 (0) 870 325 3622 or Internally: 7225 3622 > : E-mail: stephen.bailey at uk.fujitsu.com > " Web: http://services.fujitsu.com/ > > > Fujitsu Services Limited, Registered in England no 96056, Registered > Office 22 Baker Street, London, W1U 3BW > > This e-mail is only for the use of its intended recipient. Its contents > are subject to a duty of confidence and may be privileged. Fujitsu > Services does not guarantee that this e-mail has not been intercepted > and amended or that it is virus-free. > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: 11 February 2009 03:30 > To: NANOG list > Subject: Re: World famous cabling disasters? > > On Feb 10, 2009, at 10:16 PM, joe mcguckin wrote: > > > I'm looking for a couple of pictures of the worst cabling > > infrastructure ever seem. One Wilshire meet me room comes to mind. > > Anyone got any links to their photo albums, etc? > > I've always considered this the worst: > > > > Google shows lots of pictures, such as p=1836>. > > -- > TTFN, > patrick > > > > From ross at kallisti.us Wed Feb 11 08:42:06 2009 From: ross at kallisti.us (Ross Vandegrift) Date: Wed, 11 Feb 2009 09:42:06 -0500 Subject: Network diagram software In-Reply-To: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> Message-ID: <20090211144206.GA2731@kallisti.us> On Wed, Feb 11, 2009 at 02:06:09PM +0100, Mathias Wolkert wrote: > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. > > What do you use? I'd like to put a second request. I often want to very quickly mock-up a diagram that I'm going to use for myself or for internal purposes. Is there any application that takes some kind of *simple* description and produces a (possibly not so beautiful) picture? For example, I might say something like: Router(rtr1) connects to vlan 100 Router(rtr2) connects to Router(rtr1) via T1 switch(sw1) connects to vlan100 switch(sw2) connects to Router(rtr2) A few hosts connect to Switch(sw1) A few hosts connect to Switch(sw2) -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie From dga at cs.cmu.edu Wed Feb 11 08:48:24 2009 From: dga at cs.cmu.edu (David Andersen) Date: Wed, 11 Feb 2009 09:48:24 -0500 Subject: Network diagram software In-Reply-To: <20090211144206.GA2731@kallisti.us> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> Message-ID: <7ADD6501-0EF8-46E7-A678-F2AE6B4DD564@cs.cmu.edu> On Feb 11, 2009, at 9:42 AM, Ross Vandegrift wrote: > > I'd like to put a second request. I often want to very quickly > mock-up a diagram that I'm going to use for myself or for internal > purposes. > > Is there any application that takes some kind of *simple* description > and produces a (possibly not so beautiful) picture? For example, I > might say something like: > > Router(rtr1) connects to vlan 100 > Router(rtr2) connects to Router(rtr1) via T1 > switch(sw1) connects to vlan100 > switch(sw2) connects to Router(rtr2) > A few hosts connect to Switch(sw1) > A few hosts connect to Switch(sw2) The aforementioned graphviz program "dot" (and friends) will do exactly this. http://www.graphviz.org/ There's a command-line version and a spiffy GUI version for the mac. It's a great way to go. It may be unsurprising that it was an at&t project. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From mvh at hosteurope.de Wed Feb 11 08:51:43 2009 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 11 Feb 2009 15:51:43 +0100 Subject: Network diagram software In-Reply-To: <20090211144206.GA2731@kallisti.us> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> Message-ID: <4992E5FF.6020207@hosteurope.de> Hi, Ross Vandegrift wrote: > Is there any application that takes some kind of *simple* description > and produces a (possibly not so beautiful) picture? yes, Omnigraffle here as well. Can be simple AND beautiful. rgds, .m From bdfleming at kanren.net Wed Feb 11 09:06:20 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Wed, 11 Feb 2009 09:06:20 -0600 Subject: Network diagram software In-Reply-To: <4992E5FF.6020207@hosteurope.de> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> <4992E5FF.6020207@hosteurope.de> Message-ID: <0A9FA37F-C5D3-489B-AC35-DB22DBDFE80E@kanren.net> On Feb 11, 2009, at 8:51 AM, Malte von dem Hagen wrote: > Hi, > > Ross Vandegrift wrote: >> Is there any application that takes some kind of *simple* description >> and produces a (possibly not so beautiful) picture? > > yes, Omnigraffle here as well. Can be simple AND beautiful. > > rgds, > > .m > > Agreed. We use it for all our network and service diagrams.. probably because we're all Mac users! :D -- Brad Fleming Kansas Research and Education Network From mathias.wolkert at gmail.com Wed Feb 11 09:11:38 2009 From: mathias.wolkert at gmail.com (Mathias Wolkert) Date: Wed, 11 Feb 2009 16:11:38 +0100 Subject: Network diagram software In-Reply-To: <7ADD6501-0EF8-46E7-A678-F2AE6B4DD564@cs.cmu.edu> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> <7ADD6501-0EF8-46E7-A678-F2AE6B4DD564@cs.cmu.edu> Message-ID: <3e306c60902110711o5fec5089j8c5288fcfa5324ed@mail.gmail.com> Thanks all for your input. One thing that hits me is how different networks are documented. Are there any best practice communicated (RFC/IETF)? I like the idea of having one physical version showing cables and devices (CDP/EDP/LLDP view pretty much) and one logical view showing IP subnets. Many times I found *documented* networks where this is all combined making it very unclear. The hard part is to visually show what VLANs are active in each switch. Thoughts? /Tias From woody at pch.net Wed Feb 11 09:27:35 2009 From: woody at pch.net (Bill Woodcock) Date: Wed, 11 Feb 2009 07:27:35 -0800 (PST) Subject: Network diagram software In-Reply-To: <4992CEA4.8020206@hosteurope.de> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> Message-ID: > OmniGraffle is the better Visio. Me three. We all use OmniGraffle. And Adobe Illustrator to create new objects. -Bill From Josh.Stephens at solarwinds.com Wed Feb 11 09:28:48 2009 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Wed, 11 Feb 2009 09:28:48 -0600 Subject: Network diagram software In-Reply-To: <0A9FA37F-C5D3-489B-AC35-DB22DBDFE80E@kanren.net> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com><20090211144206.GA2731@kallisti.us><4992E5FF.6020207@hosteurope.de> <0A9FA37F-C5D3-489B-AC35-DB22DBDFE80E@kanren.net> Message-ID: <832C54C8546AD0409AEA7E9FEBBEA1EC95E581@AUS-EXC-01.tul.solarwinds.net> You can also use Lan Surveyor from us here @SolarWinds. There's a light version called "Lan Surveyor Express" that discovers the network (layer 2 and 3) and then draws the topology for you in Visio. You can of course buy it from SolarWinds.Com but there's also a special link that we use to give it away to partners. Feel free to download to download and use that one (free): http://www.solarwinds.com/register/registrationform.aspx?Program=583&c=7 0150000000E50d Josh -----Original Message----- From: Brad Fleming [mailto:bdfleming at kanren.net] Sent: Wednesday, February 11, 2009 9:06 AM To: nanog at nanog.org Subject: Re: Network diagram software On Feb 11, 2009, at 8:51 AM, Malte von dem Hagen wrote: > Hi, > > Ross Vandegrift wrote: >> Is there any application that takes some kind of *simple* description >> and produces a (possibly not so beautiful) picture? > > yes, Omnigraffle here as well. Can be simple AND beautiful. > > rgds, > > .m > > Agreed. We use it for all our network and service diagrams.. probably because we're all Mac users! :D -- Brad Fleming Kansas Research and Education Network From qiu.min98 at gmail.com Wed Feb 11 09:26:25 2009 From: qiu.min98 at gmail.com (Min) Date: Wed, 11 Feb 2009 10:26:25 -0500 Subject: Network diagram software In-Reply-To: <4992E5FF.6020207@hosteurope.de> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> <4992E5FF.6020207@hosteurope.de> Message-ID: <325f8f110902110726h1cb30efbj41432902c121723a@mail.gmail.com> yWorks http://www.yworks.com/en/index.html worth a try, its yEd is free. m On Wed, Feb 11, 2009 at 9:51 AM, Malte von dem Hagen wrote: > Hi, > > Ross Vandegrift wrote: >> >> Is there any application that takes some kind of *simple* description >> and produces a (possibly not so beautiful) picture? > > yes, Omnigraffle here as well. Can be simple AND beautiful. > > rgds, > > .m > > From chucklist at forest.net Wed Feb 11 09:51:19 2009 From: chucklist at forest.net (chuck goolsbee) Date: Wed, 11 Feb 2009 07:51:19 -0800 Subject: Network diagram software In-Reply-To: References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> Message-ID: <20090211075119082015.2688757d@forest.net> On Wed, 11 Feb 2009 07:27:35 -0800 (PST), Bill Woodcock wrote: > > OmniGraffle is the better Visio. > > Me three. We all use OmniGraffle. And Adobe Illustrator to create new > objects. Me four, except I'm too lazy to create new objects and just slurp them from Graffletopia: --chuck From nanog304985 at aquick.org Wed Feb 11 10:00:18 2009 From: nanog304985 at aquick.org (Adam Fields) Date: Wed, 11 Feb 2009 11:00:18 -0500 Subject: Network diagram software In-Reply-To: References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> Message-ID: <20090211160018.GW9915@lola.aquick.org> On Wed, Feb 11, 2009 at 07:27:35AM -0800, Bill Woodcock wrote: > > OmniGraffle is the better Visio. > > Me three. We all use OmniGraffle. And Adobe Illustrator to create new > objects. I use Omnigraffle all the time. Check out graffletopia for new stencils: http://www.graffletopia.com/ (It's also available in the integrated search box in Omnigraffle.) Also of note - OmniGraffle can import OmniOutliner files (among some other things) and make a diagram out of the tree. -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.adamfields.com ] [ http://workstuff.tumblr.com ] ........... Technology Blog [ http://www.aquick.org/blog ] ............ Personal Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.twitter.com/fields ].......... Twitter [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] ................ Founder From hcb at netcases.net Wed Feb 11 10:11:36 2009 From: hcb at netcases.net (Howard C. Berkowitz) Date: Wed, 11 Feb 2009 11:11:36 -0500 Subject: Network diagram software In-Reply-To: <20090211144206.GA2731@kallisti.us> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> Message-ID: <003f01c98c63$6a3c2fb0$020fa8c0@HDESK1> > -----Original Message----- > From: Ross Vandegrift [mailto:ross at kallisti.us] > Sent: Wednesday, February 11, 2009 9:42 AM > To: Mathias Wolkert > Cc: nanog at nanog.org > Subject: Re: Network diagram software > > On Wed, Feb 11, 2009 at 02:06:09PM +0100, Mathias Wolkert wrote: > > I'd like to know what software people are using to document networks. > > Visio is obvious but feels like a straight jacket to me. > > I liked netviz but it seems owned by CA and unsupported nowadays. > > > > What do you use? > > I'd like to put a second request. I often want to very quickly > mock-up a diagram that I'm going to use for myself or for internal > purposes. > > Is there any application that takes some kind of *simple* description > and produces a (possibly not so beautiful) picture? For example, I > might say something like: > > Router(rtr1) connects to vlan 100 > Router(rtr2) connects to Router(rtr1) via T1 > switch(sw1) connects to vlan100 > switch(sw2) connects to Router(rtr2) > A few hosts connect to Switch(sw1) > A few hosts connect to Switch(sw2) > Isn't there something comparable, at the virtual level, that draws pictures from RPSL descriptions? From bsutterfield at theplanet.com Wed Feb 11 10:33:48 2009 From: bsutterfield at theplanet.com (Sutterfield, Brian) Date: Wed, 11 Feb 2009 10:33:48 -0600 Subject: XKL Message-ID: <146B1D40D5C8E74B88AB403DAA28DEAB578BA8@HOUEXCH01.PLANET.LOCAL> Does anyone have any experience using the DXM from XKL for DWDM deployments? Any feedback is appreciated. Thanks, Brian From isabeldias1 at yahoo.com Wed Feb 11 11:05:08 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 11 Feb 2009 09:05:08 -0800 (PST) Subject: XKL In-Reply-To: <146B1D40D5C8E74B88AB403DAA28DEAB578BA8@HOUEXCH01.PLANET.LOCAL> Message-ID: <655877.83033.qm@web52601.mail.re2.yahoo.com> what do you mean? --- On Wed, 2/11/09, Sutterfield, Brian wrote: > From: Sutterfield, Brian > Subject: XKL > To: nanog at nanog.org > Date: Wednesday, February 11, 2009, 5:33 PM > Does anyone have any experience using the DXM from XKL for > DWDM > deployments? > > > > Any feedback is appreciated. > > > > Thanks, > > Brian From bfeeny at mac.com Wed Feb 11 11:07:49 2009 From: bfeeny at mac.com (Brian Feeny) Date: Wed, 11 Feb 2009 12:07:49 -0500 Subject: Network diagram software In-Reply-To: <4992CEA4.8020206@hosteurope.de> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> Message-ID: <1A0FFFC5-29A7-439E-8048-0F40C05C867E@mac.com> OmniGraffle all the way On Feb 11, 2009, at 8:12 AM, Malte von dem Hagen wrote: > Mathias Wolkert wrote: >> I'd like to know what software people are using to document networks. >> Visio is obvious but feels like a straight jacket to me. >> I liked netviz but it seems owned by CA and unsupported nowadays. >> What do you use? > > OmniGraffle is the better Visio. > > rgds, > > .m > From isabeldias1 at yahoo.com Wed Feb 11 11:15:21 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 11 Feb 2009 09:15:21 -0800 (PST) Subject: XKL In-Reply-To: <049d01c98c6b$ca2a7820$5e7f6860$@edu> Message-ID: <471834.70203.qm@web52610.mail.re2.yahoo.com> What do you mean? --- On Wed, 2/11/09, Robert D. Scott wrote: > From: Robert D. Scott > Subject: RE: XKL > To: isabeldias1 at yahoo.com > Date: Wednesday, February 11, 2009, 6:11 PM > http://www.xkl.com/ > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS > Receptionist > University of Florida 352-392-9440 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell > > > -----Original Message----- > From: isabel dias [mailto:isabeldias1 at yahoo.com] > Sent: Wednesday, February 11, 2009 12:05 PM > To: nanog at nanog.org; Sutterfield, Brian > Subject: Re: XKL > > what do you mean? > > > --- On Wed, 2/11/09, Sutterfield, Brian > wrote: > > > From: Sutterfield, Brian > > > Subject: XKL > > To: nanog at nanog.org > > Date: Wednesday, February 11, 2009, 5:33 PM > > Does anyone have any experience using the DXM from XKL > for > > DWDM > > deployments? > > > > > > > > Any feedback is appreciated. > > > > > > > > Thanks, > > > > Brian From jkrejci at usinternet.com Wed Feb 11 11:17:25 2009 From: jkrejci at usinternet.com (Justin Krejci) Date: Wed, 11 Feb 2009 11:17:25 -0600 Subject: Networking performance In-Reply-To: <498C8891.20100@bogus.com> References: <40d8a95a0902061043u4988fc7bm2178cb47c554a43f@mail.gmail.com> <498C8891.20100@bogus.com> Message-ID: <499D8D9F8D9E4FCC9702131DBE45BD4E@usicorp.usinternet.com> STG is a very simple windows real time snmp grapher http://leonidvm.chat.ru/ It is geared at interface throughput but can easily be used for things like CPU utilization, firewall connection counts, temperature, etc. -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Friday, February 06, 2009 12:59 PM To: Deric Kwok Cc: nanog at nanog.org Subject: Re: Networking performance Deric Kwok wrote: > Hi > > I would like to ask your professional experience about switch throughput > > I have Gig Switchs eg: H P3400 /3500, cisco c4 948../ dlink > In their spec, they said that it can handles Gig > So far, I couldn't see their ports are used up over 200M in mrtg graph > when I try to transfer 3G size files to files between computers So, first off there's the question of sample interval vs the actaul time the transfer takes... I'd use an instrument other than mrtg to measure the spead of the transfer for example bytes transfer/wall clock time. Second, you're benchmarking a bunch of components other than the network, like your disks for example, which are likely slower than the 125MB/s you're trying to measure... Switch to ttcp or iperf for your throughput measurement and you'll probably get a lot closer to measuring what you're in fact trying to measure. > ls there any limitation in those switchs? > or I have to do configuration eg: put it full duplex instead of auto autonegotiation on gigabit interfaces should almost always produce the desired result. > Thank you for your help > From ray at oneunified.net Wed Feb 11 11:19:31 2009 From: ray at oneunified.net (Ray Burkholder) Date: Wed, 11 Feb 2009 13:19:31 -0400 Subject: Network diagram software In-Reply-To: References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> Message-ID: <0e0301c98c6c$e7c82520$b7586f60$@net> > > > Mathias Wolkert wrote: > >> I'd like to know what software people are using to document > networks. > >> Visio is obvious but feels like a straight jacket to me. > >> I liked netviz but it seems owned by CA and unsupported nowadays. > >> What do you use? > > > > OmniGraffle is the better Visio. > OmniGraffle appears to be Mac only. Anything for us Mac deficient people? -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean. From akaushal25 at gmail.com Wed Feb 11 11:30:35 2009 From: akaushal25 at gmail.com (Amit Kaushal) Date: Wed, 11 Feb 2009 09:30:35 -0800 Subject: Network diagram software In-Reply-To: <0e0301c98c6c$e7c82520$b7586f60$@net> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> <0e0301c98c6c$e7c82520$b7586f60$@net> Message-ID: Concept Draw is compatible with Windows and Mac. UI is similar to Visio. http://www.conceptdraw.com/en/ On Feb 11, 2009, at 9:19 AM, Ray Burkholder wrote: >> >>> Mathias Wolkert wrote: >>>> I'd like to know what software people are using to document >> networks. >>>> Visio is obvious but feels like a straight jacket to me. >>>> I liked netviz but it seems owned by CA and unsupported nowadays. >>>> What do you use? >>> >>> OmniGraffle is the better Visio. >> > > OmniGraffle appears to be Mac only. Anything for us Mac deficient > people? > > > -- > Scanned for viruses and dangerous content at > http://www.oneunified.net and is believed to be clean. > > From bmanning at vacation.karoshi.com Wed Feb 11 11:43:37 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 11 Feb 2009 17:43:37 +0000 Subject: XKL In-Reply-To: <146B1D40D5C8E74B88AB403DAA28DEAB578BA8@HOUEXCH01.PLANET.LOCAL> References: <146B1D40D5C8E74B88AB403DAA28DEAB578BA8@HOUEXCH01.PLANET.LOCAL> Message-ID: <20090211174337.GA1119@vacation.karoshi.com.> you mean these guys? http://inwap.com/pdp10/td-1b.html --bill (who is almost certainly experiencing Charles Bonet Syndrome) On Wed, Feb 11, 2009 at 10:33:48AM -0600, Sutterfield, Brian wrote: > Does anyone have any experience using the DXM from XKL for DWDM > deployments? > > > > Any feedback is appreciated. > > > > Thanks, > > Brian > From jasondearborn at gmail.com Wed Feb 11 11:51:01 2009 From: jasondearborn at gmail.com (Jason Dearborn) Date: Wed, 11 Feb 2009 09:51:01 -0800 Subject: Network diagram software In-Reply-To: References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> <0e0301c98c6c$e7c82520$b7586f60$@net> Message-ID: <4296d7270902110951m15299219j49d1c708da6ef71c@mail.gmail.com> I use the free basic version of http://www.gliffy.com for mock-ups. It doesn't go as deep as OmniGraffle or Visio, but it's enough to illustrate concepts to NOC guys or executives. From bdfleming at kanren.net Wed Feb 11 11:57:01 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Wed, 11 Feb 2009 11:57:01 -0600 Subject: J-series and Cisco ME3400 L2 Issues Message-ID: Hello all! Recently, KanREN has begun purchasing Ethernet circuits from a new provider who uses a Cisco ME3400 for CPE to provide the link to us. We use primarly Juniper J-2320 and J-4350 routers for our site equipment (running JunOS 9.3 Enhanced Services). We've seen a problem getting Layer2 to function correctly with various speed and duplex settings. We tried every combo of hardcoded settings on both sides but simply couldn't resolve some L2 errors and interface resets. In the end, we found a stable setup with the J-series set to auto/auto and the ME3400 set to 100/full. Has anyone else seen similar problem using either the J-series or an ME3400? If so, did you ever find a complete resolution (or explanation)? Thanks for any insight! -- Brad Fleming Network Engineer Kansas Research and Education Network Office: 785-856-9800 x.222 Moblie: 785-865-7231 NOC: 866-984-3662 From ka at pacific.net Wed Feb 11 12:03:11 2009 From: ka at pacific.net (Ken A) Date: Wed, 11 Feb 2009 12:03:11 -0600 Subject: Network diagram software In-Reply-To: <0e0301c98c6c$e7c82520$b7586f60$@net> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CEA4.8020206@hosteurope.de> <0e0301c98c6c$e7c82520$b7586f60$@net> Message-ID: <499312DF.6070405@pacific.net> Ray Burkholder wrote: >>> Mathias Wolkert wrote: >>>> I'd like to know what software people are using to document >> networks. >>>> Visio is obvious but feels like a straight jacket to me. >>>> I liked netviz but it seems owned by CA and unsupported nowadays. >>>> What do you use? >>> OmniGraffle is the better Visio. > > OmniGraffle appears to be Mac only. Anything for us Mac deficient people? > > Dia is simple, easy to use, general purpose http://www.gnome.org/projects/dia/ From josmon at rigozsaurus.com Wed Feb 11 12:13:34 2009 From: josmon at rigozsaurus.com (John Osmon) Date: Wed, 11 Feb 2009 11:13:34 -0700 Subject: Network diagram software In-Reply-To: <3e306c60902110711o5fec5089j8c5288fcfa5324ed@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> <7ADD6501-0EF8-46E7-A678-F2AE6B4DD564@cs.cmu.edu> <3e306c60902110711o5fec5089j8c5288fcfa5324ed@mail.gmail.com> Message-ID: <20090211181334.GA7268@jeeves.rigozsaurus.com> On Wed, Feb 11, 2009 at 04:11:38PM +0100, Mathias Wolkert wrote: [...] > I like the idea of having one physical version showing cables and devices > (CDP/EDP/LLDP view pretty much) and one logical view showing IP subnets. > Many times I found *documented* networks where this is all combined making > it very unclear. > The hard part is to visually show what VLANs are active in each switch. > > Thoughts? You're hitting the nail on the head. Most people worry about the *tool* being used, and neglect the information. Most networks need at least two diagrams: - a logical map showing network boundaries/collision domains/etc. (This is where VLANs get documented) - a physical map showing *how* things are connected. (This is where equipment and their interconnects are documented) Once you get that into your head, the best tool is the one that most people can use. I've been using PowerPoint for a couple of years and haven't run into anyone that says, "I can't read that." From toasty at dragondata.com Wed Feb 11 13:15:59 2009 From: toasty at dragondata.com (Kevin Day) Date: Wed, 11 Feb 2009 13:15:59 -0600 Subject: Network diagram software In-Reply-To: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> Message-ID: <36DF8B50-AA66-47F2-A902-82232DDA1278@dragondata.com> On Feb 11, 2009, at 7:06 AM, Mathias Wolkert wrote: > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. > > What do you use? > > /Tias Two packages that I'm looking at right now for a project. RackMonkey http://flux.org.uk/projects/rackmonkey/ Simple, AJAX-ified, looks very easy to use for non-nerds. Keeps track of rack space allocations, devices, even does some neat tricks using Dell service tags to let you see warranty/config info. RackTables http://racktables.org/ More advanced, but quite a bit more complex. Keeps track of devices, how they're connected, IP allocations, vlans, "virtual servers", etc. Some tools to let you automatically populate the database. Neither appear to do power management, or much in the way of physical cable routing. Power is becoming a big thing for everyone - a tool that let us track idle/average/max power loads per device, and play 'what-if' with circuit/rack placement would make my life a lot easier. Like others posted, one of the big problems is that you can't put everything into one visualization. For us, we need physical/L1 (rack space planning, power planning, cable routing, asset tracking, etc), network/L2 (switches, vlans, mac addresses), IP/L3 (IP management, subnets, virtual servers, etc), Application/L4+ (what apps/services run on which servers, domain names, etc) I'm not aware of any one tool that does all of that, but there seems to be a lot of appeal in tying all those things together. -- Kevin From hcb at netcases.net Wed Feb 11 13:37:28 2009 From: hcb at netcases.net (Howard C. Berkowitz) Date: Wed, 11 Feb 2009 14:37:28 -0500 Subject: Network diagram software In-Reply-To: <36DF8B50-AA66-47F2-A902-82232DDA1278@dragondata.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <36DF8B50-AA66-47F2-A902-82232DDA1278@dragondata.com> Message-ID: <006701c98c80$2cd09720$020fa8c0@HDESK1> > -----Original Message----- > From: Kevin Day [mailto:toasty at dragondata.com] > Sent: Wednesday, February 11, 2009 2:16 PM > To: Mathias Wolkert > Cc: nanog at nanog.org > Subject: Re: Network diagram software > > > On Feb 11, 2009, at 7:06 AM, Mathias Wolkert wrote: > > > I'd like to know what software people are using to document networks. > > Visio is obvious but feels like a straight jacket to me. > > I liked netviz but it seems owned by CA and unsupported nowadays. > > > > What do you use? > > > > /Tias > > Two packages that I'm looking at right now for a project. > > > RackMonkey http://flux.org.uk/projects/rackmonkey/ > > Simple, AJAX-ified, looks very easy to use for non-nerds. Keeps track > of rack space allocations, devices, even does some neat tricks using > Dell service tags to let you see warranty/config info. > You remind me of a design discussion, well-lubricated with beer, in which my team was trying, in spite of top management, to design great carrier routers. At one point, partially for RFC4098 benchmarking, we wanted to put a GPS card into some prototypes, originally as a time reference. We started thinking what else we could do with it, assuming we could get an enhanced-accuracy GPS (DGPS/WAAS) signal into the machine room. Physical inventory became a possibility. Somewhere, however, it started moving into the silly, including oscillation indicating earthquakes, and then graceful arcs as the rack fell over. From tme at multicasttech.com Wed Feb 11 13:43:16 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 11 Feb 2009 14:43:16 -0500 Subject: Network diagram software In-Reply-To: <006701c98c80$2cd09720$020fa8c0@HDESK1> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <36DF8B50-AA66-47F2-A902-82232DDA1278@dragondata.com> <006701c98c80$2cd09720$020fa8c0@HDESK1> Message-ID: <3E7AD767-9626-4E97-B403-CA167E5444EB@multicasttech.com> On Feb 11, 2009, at 2:37 PM, Howard C. Berkowitz wrote: > > >> -----Original Message----- >> From: Kevin Day [mailto:toasty at dragondata.com] >> Sent: Wednesday, February 11, 2009 2:16 PM >> To: Mathias Wolkert >> Cc: nanog at nanog.org >> Subject: Re: Network diagram software >> >> >> On Feb 11, 2009, at 7:06 AM, Mathias Wolkert wrote: >> >>> I'd like to know what software people are using to document >>> networks. >>> Visio is obvious but feels like a straight jacket to me. >>> I liked netviz but it seems owned by CA and unsupported nowadays. >>> >>> What do you use? >>> >>> /Tias >> >> Two packages that I'm looking at right now for a project. >> >> >> RackMonkey http://flux.org.uk/projects/rackmonkey/ >> >> Simple, AJAX-ified, looks very easy to use for non-nerds. Keeps track >> of rack space allocations, devices, even does some neat tricks using >> Dell service tags to let you see warranty/config info. >> > > You remind me of a design discussion, well-lubricated with beer, in > which > my team was trying, in spite of top management, to design great > carrier > routers. At one point, partially for RFC4098 benchmarking, we wanted > to put > a GPS card into some prototypes, originally as a time reference. > > We started thinking what else we could do with it, assuming we could > get an > enhanced-accuracy GPS (DGPS/WAAS) signal into the machine room. > Physical > inventory became a possibility. Somewhere, however, it started > moving into > the silly, including oscillation indicating earthquakes, and then > graceful > arcs as the rack fell over. > > Maybe not so silly : http://gizmodo.com/383605/laptop-accelerometers-used-to-study-earthquakes-desk-bumping Regards Marshall From seph at directionless.org Wed Feb 11 14:13:04 2009 From: seph at directionless.org (seph) Date: Wed, 11 Feb 2009 15:13:04 -0500 Subject: Network diagram software In-Reply-To: <4992CDE3.2000907@karnaugh.za.net> (Colin Alston's message of "Wed, 11 Feb 2009 15:08:51 +0200") References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <4992CDE3.2000907@karnaugh.za.net> Message-ID: Colin Alston writes: > Mathias Wolkert wrote: >> I'd like to know what software people are using to document networks. >> Visio is obvious but feels like a straight jacket to me. >> I liked netviz but it seems owned by CA and unsupported nowadays. > > Omnigrafle and Dia are all I can add to your list I didn't see it mentioned in the thread, but I've ditched Dia for Inkscape. I find it a bit prettier. Of course, I mostly also just use omnigraffle. seph From grinch at panix.com Wed Feb 11 14:50:32 2009 From: grinch at panix.com (Craig Holland) Date: Wed, 11 Feb 2009 12:50:32 -0800 Subject: Network diagram software In-Reply-To: <0e0301c98c6c$e7c82520$b7586f60$@net> Message-ID: Mathias Wolkert wrote: >>> OmniGraffle is the better Visio. ...except I've not found any good networking/systems stencils for omnigraffle (even on graffletopia). I tried to import the visio ones in 5.0 but that didn't work too well. Someone out there have something for omnigraffle that rivals the visio network stencils? Thanks, craig From azher at hep.caltech.edu Wed Feb 11 15:45:06 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Wed, 11 Feb 2009 13:45:06 -0800 Subject: XKL Message-ID: <499346E2.6060904@hep.caltech.edu> We used DXM10 at Caltech to connect the switches at colo in downtown LA during supercomputing 2008. Configuration is pretty straight forward and box is well stable. No errors / link flaps seen on the ports. Few of the ports were LR for 7606 and some were SR for servers connecting Myricom 10GE NICs. -Azher From isabeldias1 at yahoo.com Wed Feb 11 16:07:05 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 11 Feb 2009 14:07:05 -0800 (PST) Subject: XKL- after a brainstorming session ? In-Reply-To: <04a001c98c6c$78ceb8a0$6a6c29e0$@edu> Message-ID: <798655.35510.qm@web52608.mail.re2.yahoo.com> Rob, Ok. Do you want to share your experience? No point of taking this offline! Are you looking at market share, attributes and functionality on these new appliances? In this competitive world everyone has a say to the well-known Cisco and Juniper product set. What is the ASIC board type across all products? I can't see any 40Gig card support ....or any new OS features like most have available on their roadmap. http://www.geant2.net/upload/pdf/GN2-07-154v7-Deliverable_DJ4_2_2_Feasibility_study_40_100Gbps_optical_trans_and_advanced_Eth.pdf .//ID and yes, looking for a job! --- On Wed, 2/11/09, Robert D. Scott wrote: > From: Robert D. Scott > Subject: RE: XKL > To: isabeldias1 at yahoo.com > Date: Wednesday, February 11, 2009, 6:16 PM > My sent items has the URL in it. ??? > > http://www.xkl.com/ > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS > Receptionist > University of Florida 352-392-9440 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell > > > -----Original Message----- > From: isabel dias [mailto:isabeldias1 at yahoo.com] > Sent: Wednesday, February 11, 2009 12:15 PM > To: Robert D. Scott > Cc: nanog at nanog.org > Subject: RE: XKL > > > What do you mean? > > --- On Wed, 2/11/09, Robert D. Scott > wrote: > > > From: Robert D. Scott > > Subject: RE: XKL > > To: isabeldias1 at yahoo.com > > Date: Wednesday, February 11, 2009, 6:11 PM > > http://www.xkl.com/ > > > > Robert D. Scott Robert at ufl.edu > > Senior Network Engineer 352-273-0113 Phone > > CNS - Network Services 352-392-2061 CNS > > Receptionist > > University of Florida 352-392-9440 FAX > > Florida Lambda Rail 352-294-3571 FLR NOC > > Gainesville, FL 32611 321-663-0421 Cell > > > > > > -----Original Message----- > > From: isabel dias [mailto:isabeldias1 at yahoo.com] > > Sent: Wednesday, February 11, 2009 12:05 PM > > To: nanog at nanog.org; Sutterfield, Brian > > Subject: Re: XKL > > > > what do you mean? > > > > > > --- On Wed, 2/11/09, Sutterfield, Brian > > wrote: > > > > > From: Sutterfield, Brian > > > > > Subject: XKL > > > To: nanog at nanog.org > > > Date: Wednesday, February 11, 2009, 5:33 PM > > > Does anyone have any experience using the DXM > from XKL > > for > > > DWDM > > > deployments? > > > > > > > > > > > > Any feedback is appreciated. > > > > > > > > > > > > Thanks, > > > > > > Brian From mvh at hosteurope.de Wed Feb 11 16:34:38 2009 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 11 Feb 2009 23:34:38 +0100 Subject: Network diagram software In-Reply-To: References: Message-ID: <4993527E.1080207@hosteurope.de> Am 11.02.2009 21:50 Uhr, Craig Holland schrieb: > Mathias Wolkert wrote: Did he? >>>> OmniGraffle is the better Visio. > > ...except I've not found any good networking/systems stencils for > omnigraffle (even on graffletopia). I tried to import the visio ones in 5.0 > but that didn't work too well. Someone out there have something for > omnigraffle that rivals the visio network stencils? Depends on the target audience, but for documentation purposes, there is obviously no need for shiny, eyecandy stencils but only for distinguishable figures. Use circles for routers, rectangles for switches and so on. There are enough geometric stencils available. Regards, .m -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature URL: From m.hallgren at free.fr Wed Feb 11 16:51:40 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 11 Feb 2009 23:51:40 +0100 Subject: Network diagram software In-Reply-To: <4993527E.1080207@hosteurope.de> References: <4993527E.1080207@hosteurope.de> Message-ID: <1234392700.7457.10.camel@home> Le mercredi 11 f?vrier 2009 ? 23:34 +0100, Malte von dem Hagen a ?crit : > > Am 11.02.2009 21:50 Uhr, Craig Holland schrieb: > > Mathias Wolkert wrote: > > Did he? > > >>>> OmniGraffle is the better Visio. > > > > ...except I've not found any good networking/systems stencils for > > omnigraffle (even on graffletopia). I tried to import the visio ones in 5.0 > > but that didn't work too well. Someone out there have something for > > omnigraffle that rivals the visio network stencils? > > Depends on the target audience, but for documentation purposes, there is > obviously no need for shiny, eyecandy stencils but only for > distinguishable figures. Use circles for routers, rectangles for > switches and so on. There are enough geometric stencils available. Or ;)... Unless that you need runtime input, parse your configuration file repository, and build quite nice looking documents using TeX (plus, if you fancy nice graphics, pstricks, metapost, or pgf/TiKz). That's easy with a small few lines of perl (or your parsing language of choice). If you need run-time data, simply script it into the above mentioned "engine." The engineering way of lazily producing "marketing visual quality" documents... IMHO :) Cheers, mh > > Regards, > > .m > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From m.hallgren at free.fr Wed Feb 11 16:56:25 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 11 Feb 2009 23:56:25 +0100 Subject: Network diagram software In-Reply-To: <1234392700.7457.10.camel@home> References: <4993527E.1080207@hosteurope.de> <1234392700.7457.10.camel@home> Message-ID: <1234392985.7457.13.camel@home> Le mercredi 11 f?vrier 2009 ? 23:51 +0100, Michael Hallgren a ?crit : > Le mercredi 11 f?vrier 2009 ? 23:34 +0100, Malte von dem Hagen a ?crit : > > > > Am 11.02.2009 21:50 Uhr, Craig Holland schrieb: > > > Mathias Wolkert wrote: > > > > Did he? > > > > >>>> OmniGraffle is the better Visio. > > > > > > ...except I've not found any good networking/systems stencils for > > > omnigraffle (even on graffletopia). I tried to import the visio ones in 5.0 > > > but that didn't work too well. Someone out there have something for > > > omnigraffle that rivals the visio network stencils? > > > > Depends on the target audience, but for documentation purposes, there is > > obviously no need for shiny, eyecandy stencils but only for > > distinguishable figures. Use circles for routers, rectangles for > > switches and so on. There are enough geometric stencils available. > > Or ;)... Unless that you need runtime input, parse your configuration > file repository, and build quite nice looking documents using TeX (plus, > if you fancy nice graphics, pstricks, metapost, or pgf/TiKz). That's > easy with a small few lines of perl (or your parsing language of > choice). If you need run-time data, simply script it into the above > mentioned "engine." The engineering way of lazily producing "marketing > visual quality" documents... IMHO :) If you're not used to this kind of document authoring, I believe TiKz is your best/first friend. mh > > Cheers, > > mh > > > > > Regards, > > > > .m > > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mvh at hosteurope.de Wed Feb 11 17:11:17 2009 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Thu, 12 Feb 2009 00:11:17 +0100 Subject: Network diagram software In-Reply-To: <20090211181334.GA7268@jeeves.rigozsaurus.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> <7ADD6501-0EF8-46E7-A678-F2AE6B4DD564@cs.cmu.edu> <3e306c60902110711o5fec5089j8c5288fcfa5324ed@mail.gmail.com> <20090211181334.GA7268@jeeves.rigozsaurus.com> Message-ID: <49935B15.2020909@hosteurope.de> Hej, Am 11.02.2009 19:13 Uhr, John Osmon schrieb: > On Wed, Feb 11, 2009 at 04:11:38PM +0100, Mathias Wolkert wrote: >> I like the idea of having one physical version showing cables and devices >> (CDP/EDP/LLDP view pretty much) and one logical view showing IP subnets. >> Many times I found *documented* networks where this is all combined making >> it very unclear. >> The hard part is to visually show what VLANs are active in each switch. > Most networks need at least two diagrams: > - a logical map showing network boundaries/collision domains/etc. > (This is where VLANs get documented) > - a physical map showing *how* things are connected. > (This is where equipment and their interconnects are documented) the actual needs strongly depend on the design of the network. If your network is segemented by many routers, it may even be sufficient to do a dozen or so traceroutes and parse the results ;-) If you run flat, switched networks with hundreds of switches but only few routers and possibly extreme heterogeneous subnetting in a multi-vendor environment, you do not get very far by parsing configs or "autodiscovering" the net. It becomes even more interesting if you run active layer 1 equipment like DWDM boxes or radio connections :-) Personally, I think most important is a clean documentation of Layers 1 and 2 AND the corresponding contact data for 3rd party sites/lines/equipment. These are the things you cannot get easily out of your network, and when experiencing failure on that level, you'll be happy to have this information on one single map. Always remember: Layer 3 is easy. Routing is easy. You have a lot of tools and deterministic protocols. Layers 1/2 are the wild jungle where you may see strange things happen and are partly blind and constrained. Combining the maps for Layers 1 and 2, by the way, is possible. Use colours, line types, and again geometric figures. Regards, .m -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature URL: From jay at miscreant.org Wed Feb 11 17:15:41 2009 From: jay at miscreant.org (jay at miscreant.org) Date: Thu, 12 Feb 2009 10:15:41 +1100 Subject: Network diagram software In-Reply-To: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> Message-ID: <20090212101541.rrwh086q884g8w4w@web1.nswh.com.au> Quoting Mathias Wolkert : > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. > > What do you use? > > /Tias > I know what you mean about the straight jacket, Visio used to almost drive me to the sanitarium. One day I bit the bullet and RTFM (and a book) and now I don't find it so frustrating ;) I have in the past used SmartDraw (http://www.smartdraw.com), it's commercial, but IMHO resonably priced, and I found it quick and easy to whip up network diagrams with it. It's also pretty good at flow charts. Just my $0.05 From gem at rellim.com Wed Feb 11 17:21:37 2009 From: gem at rellim.com (Gary E. Miller) Date: Wed, 11 Feb 2009 15:21:37 -0800 (PST) Subject: Network diagram software In-Reply-To: <20090212101541.rrwh086q884g8w4w@web1.nswh.com.au> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090212101541.rrwh086q884g8w4w@web1.nswh.com.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo All! Quoting Mathias Wolkert : > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. I am surprised no one has mentioned the Draw program in Open Office. It has smart connectors like Vizio. It runs on WinXX, OS X, Linux, etc., and it is free. It uses SVG so you can even generate files with any language you are handy with. The main problem is the very few templates. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFJk12EBmnRqz71OvMRAop5AJ0XvgNU5a/kRESzD9FsW8nJKVIGWQCffDaC 5rxGsAerbq6w4tWSJXr208w= =+W9a -----END PGP SIGNATURE----- From pstewart at nexicomgroup.net Wed Feb 11 17:30:29 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 11 Feb 2009 18:30:29 -0500 Subject: Cogent Question - Increments Question Message-ID: <89D27DE3375BB6428DDCC2927489826A01FDA910@nexus.nexicomgroup.net> Hi there... First off, I want to make it very clear ... I'm NOT looking for a Cogent sales person to call nor am I actually looking for pricing itself. What I'm looking for feedback on is from existing customers and whether or not Cogent sold you the option to step up in 10 meg increments from 10 up to 100 on a FE. Back when we dealt with them as a service provider, the answer was "100 or nothing" but I'm working with a couple of clients on a consulting basis who only need 10 or 20 meg bandwidth requirements and are hung up on using Cogent. On their pricing it shows 10 meg increments - is their enterprise customers different from their service provider customers on product offering? I've only dealt with them on the service provider front and found this information so far confusing.... Just looking for feedback on increments itself... thank you. Paul Stewart ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From chrisgsirhc at yahoo.com Wed Feb 11 17:44:09 2009 From: chrisgsirhc at yahoo.com (Chris Garcia) Date: Wed, 11 Feb 2009 15:44:09 -0800 (PST) Subject: Network diagram software In-Reply-To: Message-ID: <28047.51982.qm@web57004.mail.re3.yahoo.com> ? I'm surprised no one has mentioned NetBrain.? It can automatically (via discovery, or?device configs)?create Network diagrams that can be exported to Visio.?? ? http://www.netbraintech.com/web_08/solutions/na.php ? Chris Quoting Mathias Wolkert : > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. From pstewart at nexicomgroup.net Wed Feb 11 17:48:39 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 11 Feb 2009 18:48:39 -0500 Subject: Cogent Question - Increments Question In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01FDA910@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01FDA910@nexus.nexicomgroup.net> Message-ID: <89D27DE3375BB6428DDCC2927489826A01FDA915@nexus.nexicomgroup.net> Just wanted to say thanks - I already got 5+ replies offline stating that all these folks have ever been offered was either 10 or 100 on FE basis... Cheers, Paul -----Original Message----- From: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: February 11, 2009 6:30 PM To: nanog at nanog.org Subject: Cogent Question - Increments Question Hi there... First off, I want to make it very clear ... I'm NOT looking for a Cogent sales person to call nor am I actually looking for pricing itself. What I'm looking for feedback on is from existing customers and whether or not Cogent sold you the option to step up in 10 meg increments from 10 up to 100 on a FE. Back when we dealt with them as a service provider, the answer was "100 or nothing" but I'm working with a couple of clients on a consulting basis who only need 10 or 20 meg bandwidth requirements and are hung up on using Cogent. On their pricing it shows 10 meg increments - is their enterprise customers different from their service provider customers on product offering? I've only dealt with them on the service provider front and found this information so far confusing.... Just looking for feedback on increments itself... thank you. Paul Stewart ------------------------------------------------------------------------ ---- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From pstewart at nexicomgroup.net Wed Feb 11 18:09:08 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 11 Feb 2009 19:09:08 -0500 Subject: Cogent Question - Increments Question In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01FDA915@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01FDA910@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01FDA915@nexus.nexicomgroup.net> Message-ID: <89D27DE3375BB6428DDCC2927489826A01FDA91D@nexus.nexicomgroup.net> Since everyone is relying offline and I believe in keeping lists updated after asking a question....;) It seems to depend on who you talk to basically - long and short I've heard from numerous folks that were only offered 10 or 100 on FE but I have also heard from many people that more recently were offered 10 meg incremements... Again, appreciate all the input - got a tonne of replies... Paul -----Original Message----- From: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: February 11, 2009 6:49 PM To: nanog at nanog.org Subject: RE: Cogent Question - Increments Question Just wanted to say thanks - I already got 5+ replies offline stating that all these folks have ever been offered was either 10 or 100 on FE basis... Cheers, Paul -----Original Message----- From: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: February 11, 2009 6:30 PM To: nanog at nanog.org Subject: Cogent Question - Increments Question Hi there... First off, I want to make it very clear ... I'm NOT looking for a Cogent sales person to call nor am I actually looking for pricing itself. What I'm looking for feedback on is from existing customers and whether or not Cogent sold you the option to step up in 10 meg increments from 10 up to 100 on a FE. Back when we dealt with them as a service provider, the answer was "100 or nothing" but I'm working with a couple of clients on a consulting basis who only need 10 or 20 meg bandwidth requirements and are hung up on using Cogent. On their pricing it shows 10 meg increments - is their enterprise customers different from their service provider customers on product offering? I've only dealt with them on the service provider front and found this information so far confusing.... Just looking for feedback on increments itself... thank you. Paul Stewart ------------------------------------------------------------------------ ---- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." ------------------------------------------------------------------------ ---- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From jeffrey.lyon at blacklotus.net Wed Feb 11 18:13:59 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 11 Feb 2009 19:13:59 -0500 Subject: Cogent Question - Increments Question In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01FDA91D@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01FDA910@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01FDA915@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01FDA91D@nexus.nexicomgroup.net> Message-ID: <16720fe00902111613i26f3965dldd5a1322428aa4af@mail.gmail.com> Paul, With all due respect i'm not sure Cogent's sales practices are on topic for this list. Perhaps ask the question but most subscribers here, i'd assume, are not incredibly interested in whether or not they can buy a fractional FE from Cogent. My two cents. Best regards, Jeff On Wed, Feb 11, 2009 at 7:09 PM, Paul Stewart wrote: > Since everyone is relying offline and I believe in keeping lists updated > after asking a question....;) > > It seems to depend on who you talk to basically - long and short I've > heard from numerous folks that were only offered 10 or 100 on FE but I > have also heard from many people that more recently were offered 10 meg > incremements... > > Again, appreciate all the input - got a tonne of replies... > > Paul > > > -----Original Message----- > From: Paul Stewart [mailto:pstewart at nexicomgroup.net] > Sent: February 11, 2009 6:49 PM > To: nanog at nanog.org > Subject: RE: Cogent Question - Increments Question > > Just wanted to say thanks - I already got 5+ replies offline stating > that all these folks have ever been offered was either 10 or 100 on FE > basis... > > Cheers, > > Paul > > > -----Original Message----- > From: Paul Stewart [mailto:pstewart at nexicomgroup.net] > Sent: February 11, 2009 6:30 PM > To: nanog at nanog.org > Subject: Cogent Question - Increments Question > > Hi there... > > > > First off, I want to make it very clear ... I'm NOT looking for a Cogent > sales person to call nor am I actually looking for pricing itself. > > > > What I'm looking for feedback on is from existing customers and whether > or not Cogent sold you the option to step up in 10 meg increments from > 10 up to 100 on a FE. > > > > Back when we dealt with them as a service provider, the answer was "100 > or nothing" but I'm working with a couple of clients on a consulting > basis who only need 10 or 20 meg bandwidth requirements and are hung up > on using Cogent. On their pricing it shows 10 meg increments - is their > enterprise customers different from their service provider customers on > product offering? I've only dealt with them on the service provider > front and found this information so far confusing.... > > > > Just looking for feedback on increments itself... thank you. > > > > Paul Stewart > > > > > > > ------------------------------------------------------------------------ > ---- > > "The information transmitted is intended only for the person or entity > to which it is addressed and contains confidential and/or privileged > material. If you received this in error, please contact the sender > immediately and then destroy this transmission, including all > attachments, without copying, distributing or disclosing same. Thank > you." > > > > > ------------------------------------------------------------------------ > ---- > > "The information transmitted is intended only for the person or entity > to which it is addressed and contains confidential and/or privileged > material. If you received this in error, please contact the sender > immediately and then destroy this transmission, including all > attachments, without copying, distributing or disclosing same. Thank > you." > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From pstewart at nexicomgroup.net Wed Feb 11 18:19:23 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 11 Feb 2009 19:19:23 -0500 Subject: Cogent Question - Increments Question In-Reply-To: <16720fe00902111613i26f3965dldd5a1322428aa4af@mail.gmail.com> References: <89D27DE3375BB6428DDCC2927489826A01FDA910@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01FDA915@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01FDA91D@nexus.nexicomgroup.net> <16720fe00902111613i26f3965dldd5a1322428aa4af@mail.gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01FDA920@nexus.nexicomgroup.net> Thank you - and that's fair enough. With more related topics in the past I've had folks blast me for not sharing back to the list regarding offline information. In this case, in hindsight I share your opinion and that would explain why all replies were offline..... Apologies to the list and thank you Jeff for taking the time to respectively share your insight.... Paul -----Original Message----- From: jeffrey.lyon at gmail.com [mailto:jeffrey.lyon at gmail.com] On Behalf Of Jeffrey Lyon Sent: February 11, 2009 7:14 PM To: Paul Stewart Cc: nanog at nanog.org Subject: Re: Cogent Question - Increments Question Paul, With all due respect i'm not sure Cogent's sales practices are on topic for this list. Perhaps ask the question but most subscribers here, i'd assume, are not incredibly interested in whether or not they can buy a fractional FE from Cogent. My two cents. Best regards, Jeff On Wed, Feb 11, 2009 at 7:09 PM, Paul Stewart wrote: > Since everyone is relying offline and I believe in keeping lists updated > after asking a question....;) > > It seems to depend on who you talk to basically - long and short I've > heard from numerous folks that were only offered 10 or 100 on FE but I > have also heard from many people that more recently were offered 10 meg > incremements... > > Again, appreciate all the input - got a tonne of replies... > > Paul > > > -----Original Message----- > From: Paul Stewart [mailto:pstewart at nexicomgroup.net] > Sent: February 11, 2009 6:49 PM > To: nanog at nanog.org > Subject: RE: Cogent Question - Increments Question > > Just wanted to say thanks - I already got 5+ replies offline stating > that all these folks have ever been offered was either 10 or 100 on FE > basis... > > Cheers, > > Paul > > > -----Original Message----- > From: Paul Stewart [mailto:pstewart at nexicomgroup.net] > Sent: February 11, 2009 6:30 PM > To: nanog at nanog.org > Subject: Cogent Question - Increments Question > > Hi there... > > > > First off, I want to make it very clear ... I'm NOT looking for a Cogent > sales person to call nor am I actually looking for pricing itself. > > > > What I'm looking for feedback on is from existing customers and whether > or not Cogent sold you the option to step up in 10 meg increments from > 10 up to 100 on a FE. > > > > Back when we dealt with them as a service provider, the answer was "100 > or nothing" but I'm working with a couple of clients on a consulting > basis who only need 10 or 20 meg bandwidth requirements and are hung up > on using Cogent. On their pricing it shows 10 meg increments - is their > enterprise customers different from their service provider customers on > product offering? I've only dealt with them on the service provider > front and found this information so far confusing.... > > > > Just looking for feedback on increments itself... thank you. > > > > Paul Stewart > > > > > > > ------------------------------------------------------------------------ > ---- > > "The information transmitted is intended only for the person or entity > to which it is addressed and contains confidential and/or privileged > material. If you received this in error, please contact the sender > immediately and then destroy this transmission, including all > attachments, without copying, distributing or disclosing same. Thank > you." > > > > > ------------------------------------------------------------------------ > ---- > > "The information transmitted is intended only for the person or entity > to which it is addressed and contains confidential and/or privileged > material. If you received this in error, please contact the sender > immediately and then destroy this transmission, including all > attachments, without copying, distributing or disclosing same. Thank > you." > > > > > > ------------------------------------------------------------------------ ---- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From Crist.Clark at globalstar.com Wed Feb 11 19:30:17 2009 From: Crist.Clark at globalstar.com (Crist Clark) Date: Wed, 11 Feb 2009 17:30:17 -0800 Subject: Network diagram software In-Reply-To: <20090212101541.rrwh086q884g8w4w@web1.nswh.com.au> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090212101541.rrwh086q884g8w4w@web1.nswh.com.au> Message-ID: <49930B29.33E4.0097.0@globalstar.com> >>> On 2/11/2009 at 3:15 PM, wrote: > Quoting Mathias Wolkert : > >> I'd like to know what software people are using to document networks. >> Visio is obvious but feels like a straight jacket to me. >> I liked netviz but it seems owned by CA and unsupported nowadays. >> >> What do you use? >> >> /Tias >> > > I know what you mean about the straight jacket, Visio used to almost > drive me to the sanitarium. One day I bit the bullet and RTFM (and a > book) and now I don't find it so frustrating ;) > > I have in the past used SmartDraw (http://www.smartdraw.com), it's > commercial, but IMHO resonably priced, and I found it quick and easy > to whip up network diagrams with it. It's also pretty good at flow > charts. Don't touch smartdraw. Spammers. From giulianocm at uol.com.br Wed Feb 11 21:22:52 2009 From: giulianocm at uol.com.br (Giuliano (UOL)) Date: Thu, 12 Feb 2009 01:22:52 -0200 Subject: J-series and Cisco ME3400 L2 Issues In-Reply-To: References: Message-ID: <4993960C.3010307@uol.com.br> Brad, We never had the problem, but, today, Juniper release the 9.4 version of Junos software. Maybe you can check the release notes to see if you find something related to. http://www.juniper.net/techpubs/en_US/junos9.4/information-products/topic-collections/release-notes/9.4/noframes-collapsedTOC.html Att, > Hello all! > > Recently, KanREN has begun purchasing Ethernet circuits from a new > provider who uses a Cisco ME3400 for CPE to provide the link to us. We > use primarly Juniper J-2320 and J-4350 routers for our site equipment > (running JunOS 9.3 Enhanced Services). > > We've seen a problem getting Layer2 to function correctly with various > speed and duplex settings. We tried every combo of hardcoded settings on > both sides but simply couldn't resolve some L2 errors and interface > resets. In the end, we found a stable setup with the J-series set to > auto/auto and the ME3400 set to 100/full. > > Has anyone else seen similar problem using either the J-series or an > ME3400? If so, did you ever find a complete resolution (or explanation)? > > Thanks for any insight! > -- > Brad Fleming > Network Engineer > Kansas Research and Education Network > Office: 785-856-9800 x.222 > Moblie: 785-865-7231 > NOC: 866-984-3662 > > > From derek.morton25 at gmail.com Wed Feb 11 23:47:53 2009 From: derek.morton25 at gmail.com (Derek Morton) Date: Wed, 11 Feb 2009 23:47:53 -0600 Subject: World famous cabling disasters? In-Reply-To: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net> Message-ID: Here's some from the University I formerly worked for.. All this is out of commission now, but it wasn't until fairly recently. http://flickr.com/photos/dcmorton/sets/72157604766108671/ -Derek On Tue, Feb 10, 2009 at 9:16 PM, joe mcguckin wrote: > I'm looking for a couple of pictures of the worst cabling infrastructure > ever seem. One Wilshire meet me room comes to mind. > Anyone got any links to their photo albums, etc? > > > Joe McGuckin > ViaNet Communications > > joe at via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > > > > > -- #11908 Premature optimization is the root of all evil. From tjc at ecs.soton.ac.uk Thu Feb 12 02:40:26 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 12 Feb 2009 08:40:26 +0000 Subject: Network diagram software In-Reply-To: <3e306c60902110711o5fec5089j8c5288fcfa5324ed@mail.gmail.com> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> <7ADD6501-0EF8-46E7-A678-F2AE6B4DD564@cs.cmu.edu> <3e306c60902110711o5fec5089j8c5288fcfa5324ed@mail.gmail.com> <20090212084026.GE17551@login.ecs.soton.ac.uk> Message-ID: On Wed, Feb 11, 2009 at 04:11:38PM +0100, Mathias Wolkert wrote: > Thanks all for your input. > One thing that hits me is how different networks are documented. > Are there any best practice communicated (RFC/IETF)? As an aside, for ASCII network diagrams a la Internet Draft, I found that Email Effects (http://www.sigsoftware.com/emaileffects/) was rather useful. Obviously there's only so much you can do in 80 columns of ASCII :) -- Tim From randy at psg.com Thu Feb 12 03:57:59 2009 From: randy at psg.com (Randy Bush) Date: Thu, 12 Feb 2009 18:57:59 +0900 Subject: Network diagram software In-Reply-To: References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> <7ADD6501-0EF8-46E7-A678-F2AE6B4DD564@cs.cmu.edu> <3e306c60902110711o5fec5089j8c5288fcfa5324ed@mail.gmail.com> <20090212084026.GE17551@login.ecs.soton.ac.uk> Message-ID: > As an aside, for ASCII network diagrams a la Internet Draft, I found that > Email Effects (http://www.sigsoftware.com/emaileffects/) was rather useful. also emacs artist-mode randy From cra at WPI.EDU Thu Feb 12 06:19:27 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 12 Feb 2009 07:19:27 -0500 Subject: J-series and Cisco ME3400 L2 Issues In-Reply-To: References: Message-ID: <20090212121927.GE19065@angus.ind.WPI.EDU> On Wed, Feb 11, 2009 at 11:57:01AM -0600, Brad Fleming wrote: > We've seen a problem getting Layer2 to function correctly with various > speed and duplex settings. We tried every combo of hardcoded settings on > both sides but simply couldn't resolve some L2 errors and interface > resets. In the end, we found a stable setup with the J-series set to > auto/auto and the ME3400 set to 100/full. What were the L2 errors? You might try asking your question on the juniper-nsp [1] and cisco-nsp [2] lists. [1] http://puck.nether.net/mailman/listinfo/juniper-nsp [2] http://puck.nether.net/mailman/listinfo/cisco-nsp From mustafa.golam at gmail.com Thu Feb 12 06:34:57 2009 From: mustafa.golam at gmail.com (Mustafa Golam -) Date: Thu, 12 Feb 2009 15:34:57 +0300 Subject: J-series and Cisco ME3400 L2 Issues In-Reply-To: <20090212121927.GE19065@angus.ind.WPI.EDU> References: <20090212121927.GE19065@angus.ind.WPI.EDU> Message-ID: In multi-vendor environment, being specific with L2 parameters saves a lot of troubleshooting hours and costly CSRs ;) //Mustafa On Thu, Feb 12, 2009 at 3:19 PM, Chuck Anderson wrote: > On Wed, Feb 11, 2009 at 11:57:01AM -0600, Brad Fleming wrote: > > We've seen a problem getting Layer2 to function correctly with various > > speed and duplex settings. We tried every combo of hardcoded settings on > > both sides but simply couldn't resolve some L2 errors and interface > > resets. In the end, we found a stable setup with the J-series set to > > auto/auto and the ME3400 set to 100/full. > > What were the L2 errors? You might try asking your question on the > juniper-nsp [1] and cisco-nsp [2] lists. > > [1] http://puck.nether.net/mailman/listinfo/juniper-nsp > [2] http://puck.nether.net/mailman/listinfo/cisco-nsp > > -- -- *??) ?.???.?*??) ?.?*?) (?.?? (?.?` *Mustafa Golam Fedora Ambassador, Bangladesh -.*.-`,`.*RHCE,CC{D,I,N,S(..),V}P`.CCIE(..)'.'`,. http://fedoraproject.org/wiki/MustafaGolam http://mustafa.golam.googlepages.com/home "Winners never quit------Quiters never win" From chek67 at gmail.com Thu Feb 12 16:00:58 2009 From: chek67 at gmail.com (David Schreiber) Date: Thu, 12 Feb 2009 17:00:58 -0500 Subject: Dark Fiber Message-ID: <6811641885D94B839600499024476C1B@highlandlaptop> I am in need of dark fiber in the Coatesville, PA area. If anyone can help please contact me off list. Many thanks, ? David Schreiber Telsource Corporation dschreiber at telsource.com Tel: +1(862)223-9829? ? From jason at lixfeld.ca Thu Feb 12 16:08:42 2009 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 12 Feb 2009 17:08:42 -0500 Subject: Looking for someone to bounce some Fore questions off of Message-ID: <7B0CD11F-8607-4997-AD1A-2133B8446954@lixfeld.ca> My google ninja foo seems to suck as I'm coming up empty looking for a forum or mailing list for Fore ATM related stuff. I'm pretty green to the Fore ASX line, and I'm in a position at the moment where I need to try to figure out why something seems to be misbehaving. Not sure if it's me or the provider or what, so if someone with some experience with this type of gear has a few cycles and can ping me off list, I'd appreciate it. From frnkblk at iname.com Thu Feb 12 16:36:23 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Thu, 12 Feb 2009 16:36:23 -0600 Subject: World famous cabling disasters? In-Reply-To: <70EC72941042AA48ABE651C40408D9C9C11E40@hal.photon.com> References: <69C2A53C-73ED-4168-83E1-64A9F0946DC9@via.net><54557D5C-6B77-43D3-A3F1-84A3C91B7C20@ianai.net> <70EC72941042AA48ABE651C40408D9C9C11E40@hal.photon.com> Message-ID: I generally find datacom closets looking a lot worse than telecom closets. Frank -----Original Message----- From: Jamie Bowden [mailto:jamie at photon.com] Sent: Wednesday, February 11, 2009 8:27 AM To: Steve Church; NANOG list Subject: RE: World famous cabling disasters? The main telephone room in every commercial tower I've ever had the displeasure of spending any time in was a disaster. I love how the circuits all use the same color wiring between the 100 pair 66 blocks that were so covered in crud that just touching them would turn your fingers black. The closet(s) next to the elevator shafts on any given floor were more of the same on a smaller scale. It's not any particular RBOC, I've seen this same crap in Nynex, Bell Atlantic, GTE, Bell South, and Pac Bell territory. I have no doubt that Southwest Bell, Ameritech and US West sucked just as badly. You don't have to look far or go to exotic places to find this kind of thing. Telco 'techs' are their own special breed of people who will be up against the wall come the day. J -----Original Message----- From: Steve Church [mailto:nanog at headcandy.org] Sent: Wednesday, February 11, 2009 9:08 AM To: NANOG list Subject: Re: World famous cabling disasters? http://images.google.com/images?hl=en&safe=on&q=india+wiring&btnG=Search +Images There are several results for overhead outdoor wiring that just completely boggle the mind and inspire awe. Those pictures are my inspiration whenever I pull cable. Steve On Wed, Feb 11, 2009 at 5:18 AM, Bailey Stephen < Stephen.Bailey at uk.fujitsu.com> wrote: > That's quality engineering > > Great pic > > Stephen Bailey - Senior Lead Systems Engineer > Network Operations - ISP & DSL > > FUJITSU > + Infinity House, Mallard Way, Crewe Business Park, Crewe, Cheshire, CW1 > 6ZQ > ( Tel: +44 (0) 870 325 3457 or Internally: 7225 3457 > ( Fax: +44 (0) 870 325 3622 or Internally: 7225 3622 > : E-mail: stephen.bailey at uk.fujitsu.com > " Web: http://services.fujitsu.com/ > > > Fujitsu Services Limited, Registered in England no 96056, Registered > Office 22 Baker Street, London, W1U 3BW > > This e-mail is only for the use of its intended recipient. Its contents > are subject to a duty of confidence and may be privileged. Fujitsu > Services does not guarantee that this e-mail has not been intercepted > and amended or that it is virus-free. > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: 11 February 2009 03:30 > To: NANOG list > Subject: Re: World famous cabling disasters? > > On Feb 10, 2009, at 10:16 PM, joe mcguckin wrote: > > > I'm looking for a couple of pictures of the worst cabling > > infrastructure ever seem. One Wilshire meet me room comes to mind. > > Anyone got any links to their photo albums, etc? > > I've always considered this the worst: > > > > Google shows lots of pictures, such as p=1836>. > > -- > TTFN, > patrick > > > > From fernando at gont.com.ar Thu Feb 12 17:50:02 2009 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 12 Feb 2009 21:50:02 -0200 Subject: Security Assessment of the Transmission Control Protocol (TCP) Message-ID: <4994B5AA.4080801@gont.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, folks, The United Kingdom's Centre for the Protection of National Infrastructure has just released the document "Security Assessment of the Transmission Control Protocol (TCP)", on which I have had the pleasure to work during the last few years. The motivation to produce this document is explained in the Preface of the document as follows: - ---- cut here ---- The TCP/IP protocol suite was conceived in an environment that was quite different from the hostile environment they currently operate in. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that to some extent, the current world?s economy depends on them. While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications. While the Internet technology evolved since it early inception, the Internet?s building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in some protocol implementations, affecting only a reduced number of systems, while others were based in flaws in the protocols themselves, affecting virtually every existing implementation. Even in the last couple of years, researchers were still working on security problems in the core protocols. The discovery of vulnerabilities in the TCP/IP protocol suite usually led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats and the best mitigations known at the time the reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread among a large number of documents, which are sometimes difficult to identify. For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force). This basically led to a situation in which ?known? security problems have not always been addressed by all vendors. In addition, in many cases vendors have implemented quick ?fixes? to the identified vulnerabilities without a careful analysis of their effectiveness and their impact on interoperability. Producing a secure TCP/IP implementation nowadays is a very difficult task, in part because of the lack of a single document that serves as a security roadmap for the protocols. Implementers are faced with the hard task of identifying relevant documentation and differentiating between that which provides correct advice, and that which provides misleading advice based on inaccurate or wrong assumptions. There is a clear need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the existing vulnerabilities, discusses the possible countermeasures, and analyses their respective effectiveness. This document is the result of a security assessment of the IETF specifications of the Transmission Control Protocol (TCP), from a security point of view. Possible threats are identified and, where possible, countermeasures are proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not aim to be the final word on the security aspects of TCP. On the contrary, it aims to raise awareness about a number of TCP vulnerabilities that have been faced in the past, those that are currently being faced, and some of those that we may still have to deal with in the future. Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new vulnerabilities are discovered. - ---- cut here ---- The document is available at CPNI's web site: http://www.cpni.gov.uk/Products/technicalnotes/Feb-09-security-assessment-TCP.aspx Additionally, I have posted a copy of the document on my personal web site: http://www.gont.com.ar Any comments will be more than welcome. Kind regards, - -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJJlLWeAAoJEJbuqe/Qdv/xRBMIANfq3pfTFauzFacTyjzzdu7+ g0XP76J6qThEjUZzzjEtSAS0hi9u+rODEp5Cujk0y/QK0Wnyoc6ZHOn91q0cuOtA UC+YqfTrW72bJL0+JEHxYSRkASEwtfULyfnyzx3ZMoiN/gMTG/PAQ4WDvNu5ORhf nmbTiRkpdc3S6FmsMnxzwbNJrklAwGuJKIIOmGTGwrI4D1G9lOc0A6xqArIvkwma L6a2YIGOZBePpI8yj4baKk1qvXH9gk+oH5bjJDXyXZNWOIFeM5lDeJaiEQHWCbF+ k+P/plO5TImzQtmKqGGVNoRJa4scw9ZLxYz2zLkJ6dZtUzGriyi0RwvPj1ZKQR4= =sV1Y -----END PGP SIGNATURE----- From raythom at att.com Thu Feb 12 18:33:19 2009 From: raythom at att.com (THOM, RAY, ATTCORP) Date: Thu, 12 Feb 2009 19:33:19 -0500 Subject: ANTI-TERRORIST AND MONITARY CRIMES DIVISION Message-ID: <9BE3F66A003E9B4799791094D2DE90C3011B117C@misout7msgusr7a.ugd.att.com> ANTI-TERRORIST AND MONITARY CRIMES DIVISION FBI HEADQUARTERS IN WASHINGTON, D.C. FEDERAL BUREAU OF INVESTIGATION J. EDGAR HOOVER BUILDING 935 PENNSYLVANIA AVENUE, NW WASHINGTON, D.C. 20535-0001 Date: 012/0 2/2009 ANTI-TERRORIST AND MONITARY CRIMES DIVISION THIS IS AN OFFICIAL ADVICE FROM THE FBI FOREIGN REMITTANCE/TELEGRAPHIC DEPT., IT HAS COME TO OUR NOTICE THAT THE C.B.N BANK NIGERIA DISTRICT HAS RELEASED $10,500,000.00 U.S DOLLARS INTO BANK OF AMERICA IN YOUR NAME AS THE BENEFICIARY, BY INHERITANCE MEANS.THE C.B.N BANK NIGERIA KNOWING FULLY WELL THAT THEY DO NOT HAVE ENOUGH FACILITIES TO EFFECT THIS PAYMENT FROM THE UNITED KINGDOM TO YOUR ACCOUNT, USED WHAT WE KNOW AS A SECRET DIPLOMATIC TRANSIT PAYMENT S.T.D.P TO PAY THIS FUND THROUGH WIRE TRANSFER,THEY USED THIS MEANS TO COMPLETE THE PAYMENT. THEY ARE STILL, WAITING FOR CONFIRMATION FROM YOU ON THE ALREADY TRANSFERRED FUNDS, WHICH WAS MADE IN DIRECT TRANSFER SO THAT THEY CAN DO FINAL CREDITING TO YOUR ACCOUNT. SECRET DIPLOMATIC PAYMENTS ARE NOT MADE UNLESS THE FUNDS ARE RELATED TO TERRORIST ACTIVITIES WHY MUST YOUR PAYMENT BE MADE IN SECRET TRANSFER, IF YOUR TRANSACTION IS LEGITIMATE, IF YOU ARE NOT A TERRORIST, THEN WHY DID YOU NOT RECEIVE THE MONEY DIRECTLY INTO YOUR ACCOUNT, THIS IS A PURE CODED, MEANS OF PAYMENT? RECORDS WHICH WE HAVE HAD WITH THIS METHOD OF PAYMENT IN THE PAST HAS ALWAYS BEEN RELATED TO TERRORIST ACTS, WE DO NOT WANT YOU TO GET INTO TROUBLE AS SOON AS THESE FUNDS REFLECT IN YOUR ACCOUNT IN THE U.S.A, SO IT IS OUR DUTY AS A WORD WIDE COMMISSION TO CORRECT THIS LITTLE PROBLEM BEFORE THIS FUND WILL BE CREDITED INTO YOUR PERSONAL ACCOUNT. DUE TO THE INCREASED DIFFICULTY AND UNNECESSARY SCRUTINY BY THE AMERICANAUTHORITIES WHEN FUNDS COME FROM OUTSIDE OF EUROPE, AND THE MIDDLE EAST, THE FBI BANK COMMISSION FOR EUROPE HAS STOPPED THE TRANSFER ON ITS WAY TO DELIVER PAYMENT OF $8,300,000.00 TO DEBIT YOUR RESERVE ACCOUNT AND PAY YOU THROUGH A SECURED DIPLOMATIC TRANSIT ACCOUNT (S.D.T.A). WE GOVERN AND OVERSEES FUNDS TRANSFER FOR THE WORLD BANK AND THE REST OF THE WORLD. WE ADVICE YOU TO CONTACT US IMMEDIATELY, AS THE FUNDS HAVE BEEN STOPPED AND ARE BEING HELD IN OUR CUSTODY, UNTIL YOU CAN BE ABLE TO PROVIDE US WITH A DIPLOMATIC IMMUNITY SEAL OF TRANSFER (DIST) WITHING 3 DAYS FROM THE WORLD LOCAL BANK THAT AUTHORIZE THE TRANSFER FROM WHERE THE FUNDS WAS TRANSFERRED FROM TO CERTIFY THAT THE FUNDS THAT YOU ARE ABOUT TO RECEIVE FROM NIGERIA ARE ANTI TERRORIST/DRUG FREE OR WE SHALL HAVE CAUSE TO CROSS AND IMPOUND THE PAYMENT,WE SHALL RELEASE THE FUNDS IMMEDIATELY WE RECEIVE THIS LEGAL DOCUMENTS We have decided to contact you directly to acquire the proper verifications and proof from you to show that you are the rightful person to receive this fund, because of the amount involve, we want to make sure is a clean and legal money you are about to receive. Be informed that the fund are now in United State in your name, but right now we have ask the bank not to release the fund to anybody that comes to them, unless we ask them to do so, because we have to carry out our investigations first before releasing the fund to you. Note that the fund is in the BANK OF AMERICA right now, but we have ask them not to credit the fund to you yet, because we need a solid proof and verifications from you before releasing the funds. So to this regards you are to re-assure and proof to us that what you are about to receive is a clean money by sending to us FBI Identification Record and also Diplomatic Immunity Seal Of Transfer (DIST) to satisfy to us that the money you about to receive is legitimate and real money. You are to forward the documents to us immediately if you have it in your possession, if you don't have it let us know so that we will direct and inform you here to obtain the document and send to us so that we will ask the bank holding the funds the Bank Of America to go ahead and Crediting your account immediately. This Documents are to be issued to you from the World Local Bank that Authorized the transfer, so get back to us immediately if you don't have the document so that we will inform you the particular place to obtain the document in Central Bank Of Nigeria because we have come to realize that the fund was Authorized by CBN Bank in Nigeria. An FBI Identification Record and Diplomatic Immunity Seal Of Transfer (DIST) often referred to as a Criminal History Record or Rap Sheet, is a listing of Certain information taken from fingerprint submissions retained by the FBI in Connection with arrests and, in some instances, federal employment, naturalization, or military service. THESE CONDITION IS VALID UNTIL THE OF 19TH September 2008 AFTER WE SHALL TAKE ACTIONS ON CANCELLING THE PAYMENT AND THEN CHARGE YOU FOR ILLEGALLY MOVING FUNDS OUT OF NIGERIA. GUARANTEE: FUNDS WILL BE RELEASED ON CONFIRMATION OF THE DOCUMENT. FINAL INSTRUCTION: 60F CREDIT PAYMENT INSTRUCTION: IRREVOCABLE CREDIT GUARANTEE61E BENEFICIARY HAS FULL POWER WHEN VALIDATION IS CLEARED62 BENEFICIARIES BANK IN U.S.A., CAN ONLY RELEASE FUNDS- 62 UPON CONFIRMATION FROM THE WORLD BANK/UNITED NATIONS.64 BEARERS MUST CLEAR BANK PROTOCOL AND VALIDATION REQUEST NOTE: We have asked for the above documents to make available the most complete and up-to date records possible for the enhancement of public safety, welfare and security of Society while recognizing the importance of individual privacy rights.. If you fail to provide the Documents to us, we will charge you with the FBI and take our proper action against you for not proofing to us the legitimate of the fund you are about to receive. The United States Department of Justice Order 556-73 establishes rules and regulations for the subject of an FBI Identification Record to obtain a copy of his or her own Record for review. The FBI Criminal Justice Information Services (CJIS) Division processes these requests to check illegal activities in U.S.A. An individual may request a copy of his or her own FBI Identification Record for personal review or to challenge information on the Record. Other reasons an individual may request a copy of his or her own Identification Record may include international adoption or to satisfy a requirement to live or work in a foreign country or receive funds from another country (i.e., Diplomatic Immunity Seal Of Transfer, letter of good conduct, criminal history back grounded.) Faithfully Yours, FBI Director Robert S. Mueller, III Email : wwwfbigofusa at googlemail.com -----Original Message----- From: FBI FEDERAL BUREAU [mailto:www.fbi.gov.usa at gmail.com] Sent: Thursday, February 12, 2009 2:05 AM Subject: ANTI-TERRORIST AND MONITARY CRIMES DIVISION From lostinmoscow at gmail.com Thu Feb 12 18:49:16 2009 From: lostinmoscow at gmail.com (Quinn Kuzmich) Date: Thu, 12 Feb 2009 17:49:16 -0700 Subject: ANTI-TERRORIST AND MONITARY CRIMES DIVISION In-Reply-To: <9BE3F66A003E9B4799791094D2DE90C3011B117C@misout7msgusr7a.ugd.att.com> References: <9BE3F66A003E9B4799791094D2DE90C3011B117C@misout7msgusr7a.ugd.att.com> Message-ID: lol WHAT I can honestly say of all the emails I could have imagined to get from NANOG, this was not one of them. Q From ml-nanog09 at elcsplace.com Thu Feb 12 19:00:42 2009 From: ml-nanog09 at elcsplace.com (Ted Cooper) Date: Fri, 13 Feb 2009 12:00:42 +1100 Subject: ANTI-TERRORIST AND MONITARY CRIMES DIVISION In-Reply-To: References: <9BE3F66A003E9B4799791094D2DE90C3011B117C@misout7msgusr7a.ugd.att.com> Message-ID: <4994C63A.8060106@elcsplace.com> Quinn Kuzmich wrote: > lol WHAT > > I can honestly say of all the emails I could have imagined to get from > NANOG, this was not one of them. I'm trying to figure out why the FBI is trying to smuggle $8 million in terrorist funds to me through diplomatic channels? Then again, it looks like the FBI stopped a _debit_ of $8 million from my account :P Do these scams ever make sense? How the hell do people fall for this crap. As for how it ended up on the list ... I'd say that Ray Thom @ ATT may have a compromised computer :P From ops.lists at gmail.com Thu Feb 12 19:01:44 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 13 Feb 2009 06:31:44 +0530 Subject: ANTI-TERRORIST AND MONITARY CRIMES DIVISION In-Reply-To: References: <9BE3F66A003E9B4799791094D2DE90C3011B117C@misout7msgusr7a.ugd.att.com> Message-ID: Sigh. The nigerians love to break into accounts (usually buy big lists of cracked accounts from the russkiy bot mafia) and then spam using them. The other variant of the spam is where poor guy is traveling to nigeria and got robbed there, is being held for ransom so please wire money. --srs On Fri, Feb 13, 2009 at 6:19 AM, Quinn Kuzmich wrote: > > lol WHAT > > I can honestly say of all the emails I could have imagined to get from > NANOG, this was not one of them. > From jimpop at gmail.com Thu Feb 12 19:05:29 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 12 Feb 2009 20:05:29 -0500 Subject: ANTI-TERRORIST AND MONITARY CRIMES DIVISION In-Reply-To: <4994C63A.8060106@elcsplace.com> References: <9BE3F66A003E9B4799791094D2DE90C3011B117C@misout7msgusr7a.ugd.att.com> <4994C63A.8060106@elcsplace.com> Message-ID: On Thu, Feb 12, 2009 at 20:00, Ted Cooper wrote: > As for how it ended up on the list ... I'd say that Ray Thom @ ATT may > have a compromised computer :P FWIW, ATT employees don't use $name at att.com email addresses, and ATT customers have .net addrs. -Jim P. From ops.lists at gmail.com Thu Feb 12 19:08:09 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 13 Feb 2009 06:38:09 +0530 Subject: ANTI-TERRORIST AND MONITARY CRIMES DIVISION In-Reply-To: References: <9BE3F66A003E9B4799791094D2DE90C3011B117C@misout7msgusr7a.ugd.att.com> <4994C63A.8060106@elcsplace.com> Message-ID: On Fri, Feb 13, 2009 at 6:35 AM, Jim Popovitch wrote: > On Thu, Feb 12, 2009 at 20:00, Ted Cooper wrote: >> As for how it ended up on the list ... I'd say that Ray Thom @ ATT may >> have a compromised computer :P > > FWIW, ATT employees don't use $name at att.com email addresses, and ATT > customers have .net addrs. FWIW (and from interacting with ATT employees) .. guess what, you're wrong. From Stefan.Fouant at neustar.biz Thu Feb 12 19:18:49 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Thu, 12 Feb 2009 20:18:49 -0500 Subject: Looking for someone to bounce some Fore questions off of Message-ID: Is anybody still using this stuff? I would have thought most of that gear was relegated to the junk yard, but apparently not. Seriously though it's been a loooong time, but at one point I was pretty good configuring and designing networks with the ASX-1200s and the ASX-4000 devices. I might even be able to pull some PNNI configurations out of my head if I clear out some of the cobwebs first. Feel free to ping me if I might be of service. Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D ----- Original Message ----- From: Jason Lixfeld To: NANOG Sent: Thu Feb 12 17:08:42 2009 Subject: Looking for someone to bounce some Fore questions off of My google ninja foo seems to suck as I'm coming up empty looking for a forum or mailing list for Fore ATM related stuff. I'm pretty green to the Fore ASX line, and I'm in a position at the moment where I need to try to figure out why something seems to be misbehaving. Not sure if it's me or the provider or what, so if someone with some experience with this type of gear has a few cycles and can ping me off list, I'd appreciate it. From jimpop at gmail.com Thu Feb 12 19:32:02 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 12 Feb 2009 20:32:02 -0500 Subject: ANTI-TERRORIST AND MONITARY CRIMES DIVISION In-Reply-To: References: <9BE3F66A003E9B4799791094D2DE90C3011B117C@misout7msgusr7a.ugd.att.com> <4994C63A.8060106@elcsplace.com> Message-ID: On Thu, Feb 12, 2009 at 20:08, Suresh Ramasubramanian wrote: > On Fri, Feb 13, 2009 at 6:35 AM, Jim Popovitch wrote: >> On Thu, Feb 12, 2009 at 20:00, Ted Cooper wrote: >>> As for how it ended up on the list ... I'd say that Ray Thom @ ATT may >>> have a compromised computer :P >> >> FWIW, ATT employees don't use $name at att.com email addresses, and ATT >> customers have .net addrs. > > FWIW (and from interacting with ATT employees) .. guess what, you're wrong. FWIW, the ones I interact with don't ;-) As with every rule, there will always be some exceptions. -Jim P. From eddy+public+spam at noc.everquick.net Thu Feb 12 19:49:12 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Fri, 13 Feb 2009 01:49:12 +0000 (GMT) Subject: Cogent Question - Increments Question In-Reply-To: <16720fe00902111613i26f3965dldd5a1322428aa4af@mail.gmail.com> References: <89D27DE3375BB6428DDCC2927489826A01FDA910@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01FDA915@nexus.nexicomgroup.net> <89D27DE3375BB6428DDCC2927489826A01FDA91D@nexus.nexicomgroup.net> <16720fe00902111613i26f3965dldd5a1322428aa4af@mail.gmail.com> Message-ID: JL> Date: Wed, 11 Feb 2009 19:13:59 -0500 JL> From: Jeffrey Lyon JL> With all due respect i'm not sure Cogent's sales practices are on JL> topic for this list. For those interested in this sort of discussion: Try the isp-bandwidth list instead. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From john at internetassociatesllc.com Thu Feb 12 20:44:16 2009 From: john at internetassociatesllc.com (John Lee) Date: Thu, 12 Feb 2009 20:44:16 -0600 Subject: Looking for someone to bounce some Fore questions off of In-Reply-To: <7B0CD11F-8607-4997-AD1A-2133B8446954@lixfeld.ca> References: <7B0CD11F-8607-4997-AD1A-2133B8446954@lixfeld.ca> Message-ID: <53A6C7E936ED8544B1A2BC990D254F943524A77CB7@MEMEXG1.HOST.local> Jason, Fore was purchased by Marconi who sold me the Fore ASX switches for a broadband access network in 2001. Ericsson still seems to be selling ASX and TNX boxes. Do you have access to an ATM protocol anlyzers with the port type and speeds you are running? John (ISDN) Lee ________________________________________ From: Jason Lixfeld [jason at lixfeld.ca] Sent: Thursday, February 12, 2009 5:08 PM To: NANOG Subject: Looking for someone to bounce some Fore questions off of My google ninja foo seems to suck as I'm coming up empty looking for a forum or mailing list for Fore ATM related stuff. I'm pretty green to the Fore ASX line, and I'm in a position at the moment where I need to try to figure out why something seems to be misbehaving. Not sure if it's me or the provider or what, so if someone with some experience with this type of gear has a few cycles and can ping me off list, I'd appreciate it. From rjoffe at centergate.com Thu Feb 12 20:51:02 2009 From: rjoffe at centergate.com (Rodney Joffe) Date: Thu, 12 Feb 2009 19:51:02 -0700 Subject: ICANN NomCom call for SOIs for Board/Leadership positions Message-ID: <6EC36DD9-6A50-4E4E-A24A-5DB5257301F3@centergate.com> Folks, It's that time again. The 2009 ICANN Nominating Committee is actively soliciting applications, nominations, and/or Statements of Interest for the Board and other key leadership positions: # Three members of the ICANN Board of Directors # Three members of the At Large Advisory Committee (for the African, Asia/Australia/Pacific, and Latin American regions) # Two members of the Council of the Generic Names Supporting Organization (GNSO) # One member of the Council of the Country-Code Names Supporting Organization (ccNSO) This is your opportunity to actually get involved in guiding the direction of ICANN, rather than standing on the sidelines and complaining. More info at: http://nomcom.icann.org/ Step up. Rodney Joffe ICANN 2009 NomCom Member From cidr-report at potaroo.net Fri Feb 13 05:00:04 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Feb 2009 22:00:04 +1100 (EST) Subject: BGP Update Report Message-ID: <200902131100.n1DB042o085320@wattle.apnic.net> BGP Update Report Interval: 12-Jan-09 -to- 12-Feb-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 187305 4.3% 125.8 -- SIFY-AS-IN Sify Limited 2 - AS7643 167261 3.8% 285.9 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 3 - AS6629 49189 1.1% 756.8 -- NOAA-AS - NOAA 4 - AS30890 48137 1.1% 109.2 -- EVOLVA Evolva Telecom 5 - AS35805 41565 0.9% 110.0 -- UTG-AS United Telecom AS 6 - AS14420 31055 0.7% 123.2 -- ANDINATEL S.A. 7 - AS6458 28143 0.6% 58.3 -- Telgua 8 - AS30306 25107 0.6% 6276.8 -- AfOL-Sz-AS 9 - AS5050 24109 0.6% 408.6 -- PSC-EXT - Pittsburgh Supercomputing Center 10 - AS8452 22589 0.5% 14.9 -- TEDATA TEDATA 11 - AS12500 21936 0.5% 5484.0 -- RCS-AS RCS Autonomus System 12 - AS27757 21928 0.5% 160.1 -- ANDINATEL S.A. 13 - AS20115 21136 0.5% 10.2 -- CHARTER-NET-HKY-NC - Charter Communications 14 - AS30969 20102 0.5% 2512.8 -- TAN-NET TransAfrica Networks 15 - AS6389 19952 0.5% 4.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 16 - AS23966 19602 0.5% 53.7 -- LDN-AS-AP LINKdotNET Telecom Limited 17 - AS33783 19399 0.4% 122.8 -- EEPAD 18 - AS8151 19180 0.4% 12.8 -- Uninet S.A. de C.V. 19 - AS21433 18998 0.4% 146.1 -- ACCENTUREFSSC Accenture London Delivery Centre 20 - AS209 18203 0.4% 6.3 -- ASN-QWEST - Qwest Communications Corporation TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30287 7838 0.2% 7838.0 -- ALON-USA - ALON USA, LP 2 - AS30306 25107 0.6% 6276.8 -- AfOL-Sz-AS 3 - AS12500 21936 0.5% 5484.0 -- RCS-AS RCS Autonomus System 4 - AS41382 3264 0.1% 3264.0 -- TELEPORT-AS Teleport LLC Network AS 5 - AS30969 20102 0.5% 2512.8 -- TAN-NET TransAfrica Networks 6 - AS28194 7118 0.2% 2372.7 -- 7 - AS23917 2237 0.1% 2237.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 8 - AS19017 2085 0.1% 2085.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 9 - AS5033 16305 0.4% 1811.7 -- ISW - Internet Specialties West Inc. 10 - AS10806 6266 0.1% 1566.5 -- AFP-NET - AGENCE FRANCE PRESSE 11 - AS16559 15253 0.3% 1525.3 -- REALCONNECT-01 - RealConnect, Inc 12 - AS29427 2706 0.1% 1353.0 -- AZM-AS Mercury Telecom 13 - AS45122 1318 0.0% 1318.0 -- JASPACE-AS-ID-AP PT. JASPACE NET 14 - AS32398 11831 0.3% 1314.6 -- REALNET-ASN-1 15 - AS30095 2584 0.1% 1292.0 -- AS-30095 - Group M Worldwide, Inc. 16 - AS48129 1268 0.0% 1268.0 -- IRBIS-TELECOMMUNICATIONS-AS IRBIS Telecommunications Ltd. 17 - AS25970 7548 0.2% 1258.0 -- IAC - IAC Services LLC 18 - AS44265 13244 0.3% 1204.0 -- SMOLTELECOM-NET Smoltelecom Ltd AS peering 19 - AS29224 2402 0.1% 1201.0 -- HELLMANN Hellmann Worldwide Logistics GmbH & Co KG 20 - AS35335 1123 0.0% 1123.0 -- ESSTU-AS East-Siberian State Technological University AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 23883 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 144.36.245.0/24 16897 0.3% AS21433 -- ACCENTUREFSSC Accenture London Delivery Centre 3 - 192.35.129.0/24 16468 0.3% AS6629 -- NOAA-AS - NOAA 4 - 192.102.88.0/24 16325 0.3% AS6629 -- NOAA-AS - NOAA 5 - 64.162.116.0/24 16281 0.3% AS5033 -- ISW - Internet Specialties West Inc. 6 - 198.77.177.0/24 16198 0.3% AS6629 -- NOAA-AS - NOAA 7 - 221.134.32.0/24 13957 0.3% AS9583 -- SIFY-AS-IN Sify Limited 8 - 221.135.80.0/24 12943 0.3% AS9583 -- SIFY-AS-IN Sify Limited 9 - 190.152.103.0/24 12748 0.3% AS27757 -- ANDINATEL S.A. 10 - 210.214.151.0/24 12729 0.3% AS9583 -- SIFY-AS-IN Sify Limited 11 - 212.85.223.0/24 12392 0.3% AS30306 -- AfOL-Sz-AS 12 - 212.85.220.0/24 12363 0.3% AS30306 -- AfOL-Sz-AS 13 - 41.204.2.0/24 11684 0.2% AS32398 -- REALNET-ASN-1 14 - 124.7.201.0/24 11454 0.2% AS9583 -- SIFY-AS-IN Sify Limited 15 - 222.255.51.64/26 10848 0.2% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - 192.12.120.0/24 10058 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 17 - 196.27.104.0/21 9856 0.2% AS30969 -- TAN-NET TransAfrica Networks 18 - 196.27.108.0/22 9795 0.2% AS30969 -- TAN-NET TransAfrica Networks 19 - 221.135.107.0/24 8910 0.2% AS9583 -- SIFY-AS-IN Sify Limited 20 - 210.214.222.0/24 8839 0.2% AS9583 -- SIFY-AS-IN Sify Limited Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 13 05:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Feb 2009 22:00:01 +1100 (EST) Subject: The Cidr Report Message-ID: <200902131100.n1DB01dC085308@wattle.apnic.net> This report has been generated at Fri Feb 13 21:13:35 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 06-02-09 285832 177824 07-02-09 285798 177687 08-02-09 285807 177487 09-02-09 285105 177994 10-02-09 285977 177992 11-02-09 286165 177022 12-02-09 286477 177950 13-02-09 286337 178268 AS Summary 30645 Number of ASes in routing system 13024 Number of ASes announcing only one prefix 4368 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89824768 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 13Feb09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 286636 178252 108384 37.8% All ASes AS6389 4368 356 4012 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4223 1770 2453 58.1% TWTC - tw telecom holdings, inc. AS209 2830 1260 1570 55.5% ASN-QWEST - Qwest Communications Corporation AS4766 1772 508 1264 71.3% KIXS-AS-KR Korea Telecom AS17488 1523 368 1155 75.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1210 233 977 80.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1007 61 946 93.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1785 903 882 49.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1479 603 876 59.2% Uninet S.A. de C.V. AS8452 1084 255 829 76.5% TEDATA TEDATA AS11492 1212 472 740 61.1% CABLEONE - CABLE ONE, INC. AS19262 953 244 709 74.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1061 466 595 56.1% COVAD - Covad Communications Co. AS18101 753 168 585 77.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1142 559 583 51.1% LEVEL3 Level 3 Communications AS6478 1235 675 560 45.3% ATT-INTERNET3 - AT&T WorldNet Services AS7545 736 187 549 74.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS2706 550 43 507 92.2% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS22047 619 116 503 81.3% VTR BANDA ANCHA S.A. AS17908 604 111 493 81.6% TCISL Tata Communications AS4808 616 156 460 74.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 605 146 459 75.9% CANET-ASN-4 - Bell Aliant AS7018 1439 995 444 30.9% ATT-INTERNET4 - AT&T WorldNet Services AS24560 671 242 429 63.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4134 904 477 427 47.2% CHINANET-BACKBONE No.31,Jin-rong Street AS10620 747 322 425 56.9% TV Cable S.A. AS4668 701 284 417 59.5% LGNET-AS-KR LG CNS AS7011 966 554 412 42.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS9443 504 92 412 81.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 527 116 411 78.0% GIGAINFRA BB TECHNOLOGY Corp. Total 37826 12742 25084 66.3% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.12.96.0/19 AS15834 MENANET-AS MenaNet network Autonomous System 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 68.67.128.0/20 AS29990 ASN-APPNEXUS - AppNexus, Inc 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 72.9.128.0/20 AS3561 SAVVIS - Savvis 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 81.4.0.0/18 AS15834 MENANET-AS MenaNet network Autonomous System 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 155.254.0.0/16 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.2.0.0/16 AS31042 SERBIA-BROADBAND-AS Serbia Broadband Autonomous System 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.8.160.0/19 AS18109 EPOWER-TW E-Test Digital Technology Corp. 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.159.128.0/18 AS18109 EPOWER-TW E-Test Digital Technology Corp. 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.236.64.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 209.236.96.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.128.0/20 AS15834 MENANET-AS MenaNet network Autonomous System 217.29.134.0/24 AS15834 MENANET-AS MenaNet network Autonomous System 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet 220.247.128.0/19 AS18109 EPOWER-TW E-Test Digital Technology Corp. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From j.ott at plusserver.de Fri Feb 13 08:57:32 2009 From: j.ott at plusserver.de (Jens Ott - PlusServer AG) Date: Fri, 13 Feb 2009 15:57:32 +0100 Subject: Global Blackhole Service Message-ID: <49958A5C.2070200@plusserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, in the last 24 hours we received two denial of service attacks with something like 6-8GBit volume. It did not harm us too much, but e.g. one of our upstreams got his Amsix-Port exploded. With our upstreams we have remote-blackhole sessions running where we announce /32 prefixes to blackhole at their edge, but this does not work with our peers. Also our Decix-Port received something like 2Gbit extra-traffic during this DoS. I can imagine, that for some peers, especially for the once having only a thin fiber (e.g. 1GBit) to Decix, it's not to funny having it flooded with a DoS and that they might be interested in dropping such traffic at their edge. Well I could discuss with my peers (at least the once who might get in trouble with such issue) to do some individual config for some blackhole-announcement, but most probably I'm not the only one receiving DoS and who would be interested in such setup. Therefore I had the following idea: Why not taking one of my old routers and set it up as blackhole-service. Then everyone who is interested could set up a session to there and 1.) announce /32 (/128) routes out of his prefixes to blackhole them 2.) receive all the /32 (/128) announcements from the other peers with the IPs they want to have blackholed and rollout the blackhole to their network. My questions to all of you: - - What do you think about such service? - - Would you/your ASN participate in such a service? - - Do you see some kind of usefull feature in such a service? - - Do you have any comments? Thank you for telling me your opinions and best regards - -- =================================================================== Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j.ott at plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstra?e 9-11 50354 H?rth Germany HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschl?ger =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVilwACgkQMf0yjMLKfXpNuQCeKcicthIadISe7I+Xs5ZNHS+1 0qUAnRDkOY9/6kokq3Hf68BRQFfkP3xy =jKUA -----END PGP SIGNATURE----- From ops.lists at gmail.com Fri Feb 13 09:00:10 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 13 Feb 2009 20:30:10 +0530 Subject: Global Blackhole Service In-Reply-To: <49958A5C.2070200@plusserver.de> References: <49958A5C.2070200@plusserver.de> Message-ID: On Fri, Feb 13, 2009 at 8:27 PM, Jens Ott - PlusServer AG wrote: > - - What do you think about such service? > - - Would you/your ASN participate in such a service? > - - Do you see some kind of usefull feature in such a service? > - - Do you have any comments? Ah. rbl.maps.vix.com from about a decade back when it was available as a bgp feed. But only for ddos sources. srs From randy at psg.com Fri Feb 13 09:03:44 2009 From: randy at psg.com (Randy Bush) Date: Sat, 14 Feb 2009 00:03:44 +0900 Subject: Global Blackhole Service In-Reply-To: <49958A5C.2070200@plusserver.de> References: <49958A5C.2070200@plusserver.de> Message-ID: would this itself not be a dos path? randy From nuno.vieira at nfsi.pt Fri Feb 13 09:07:45 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Fri, 13 Feb 2009 15:07:45 +0000 (WET) Subject: Global Blackhole Service In-Reply-To: <49958A5C.2070200@plusserver.de> Message-ID: <1157181881.42841234537665826.JavaMail.root@zimbra.nfsi.pt> Hi Jens, I think we are in the same boat. We suffered the same problem often, on a lower magnitude, but if a project like this exists those DDoS could even be almost near zero. This is somewhat similar to what Spamcop, and other folks do with SPAM today, but applied on a diferent scope, say, BGP Blackhole. This service can span wide after just peers, opening the opportunity to edge-to-edge DDoS mitigation. Say, a network in .pt or .de is beign attacked at large, and dst operators inject the dst attacked source on the blackhole bgp feed... say that 100+ other ops around the world use a cen?rio like this... this might be very useful. concers: the "autohority" or the "responsible" for maintaining this project, must assure that OP A or OP B can *only* annouce chunks that below to him, avoiding any case of hijack. We would be interested in participating in something like this. So, > My questions to all of you: > > - - What do you think about such service? It will be great. We are available to help. > - - Would you/your ASN participate in such a service? Yes. > - - Do you see some kind of usefull feature in such a service? Yes, a few thoughts above, some more might come up. > - - Do you have any comments? For starters, a few above. Regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Jens Ott - PlusServer AG" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > in the last 24 hours we received two denial of service attacks with > something > like 6-8GBit volume. It did not harm us too much, but e.g. one of our > upstreams got his Amsix-Port exploded. > > With our upstreams we have remote-blackhole sessions running where we > announce > /32 prefixes to blackhole at their edge, but this does not work with > our > peers. Also our Decix-Port received something like 2Gbit extra-traffic > during > this DoS. > > I can imagine, that for some peers, especially for the once having > only a thin > fiber (e.g. 1GBit) to Decix, it's not to funny having it flooded with > a DoS > and that they might be interested in dropping such traffic at their > edge. > > Well I could discuss with my peers (at least the once who might get in > trouble > with such issue) to do some individual config for some > blackhole-announcement, > but most probably I'm not the only one receiving DoS and who would be > interested in such setup. > > Therefore I had the following idea: Why not taking one of my old > routers and > set it up as blackhole-service. Then everyone who is interested could > set up a > session to there and > > 1.) announce /32 (/128) routes out of his prefixes to blackhole them > 2.) receive all the /32 (/128) announcements from the other peers with > the IPs > they want to have blackholed and rollout the blackhole to their > network. > > My questions to all of you: > > - - What do you think about such service? > - - Would you/your ASN participate in such a service? > - - Do you see some kind of usefull feature in such a service? > - - Do you have any comments? > > Thank you for telling me your opinions and best regards > > - -- > =================================================================== > > Jens Ott > Leiter Network Management > > Tel: +49 22 33 - 612 - 3501 > Fax: +49 22 33 - 612 - 53501 > > E-Mail: j.ott at plusserver.de > GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A > > PlusServer AG > Daimlerstra?e 9-11 > 50354 H?rth > > Germany > > HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 > Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe > Aufsichtsratsvorsitz: Claudius Schmalschl?ger > > =================================================================== > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmVilwACgkQMf0yjMLKfXpNuQCeKcicthIadISe7I+Xs5ZNHS+1 > 0qUAnRDkOY9/6kokq3Hf68BRQFfkP3xy > =jKUA > -----END PGP SIGNATURE----- From nuno.vieira at nfsi.pt Fri Feb 13 09:10:48 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Fri, 13 Feb 2009 15:10:48 +0000 (WET) Subject: Global Blackhole Service In-Reply-To: Message-ID: <2116981546.42911234537848629.JavaMail.root@zimbra.nfsi.pt> In that way, Spamcop and other folks are DOS'ing for years aswell. And in fact, by denying things around, they are just scrubing and filtering, to make our day happier, avoiding huge masses of spam and useless crap. I don't see it the way you do. A project like this, like also spamcop, are great paths to take out the scum and undesired things from the net. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Randy Bush" wrote: > would this itself not be a dos path? > > randy From nuno.vieira at nfsi.pt Fri Feb 13 09:50:29 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Fri, 13 Feb 2009 15:50:29 +0000 (WET) Subject: Global Blackhole Service In-Reply-To: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> Message-ID: <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> Hi Suresh, But in the meanwhile, a decade later, it does not longer exist. At least, i can't reach that host, and i was unable to find working documentation on google of how about this project works, today. In fact, the first link that google gave out, says that this project is dead at least 2 years ago. http://www.dnsbl.com/2007/02/status-of-rblmapsvixcom-invalid-domain.html I think that we all have a real opportunity here for make something that can be useful to all. And, we are not talk of spam here, but, to mitigate time, money and patience consuming DDoS attacks, which often are easier to mitigate only at the Source and at the Destination, while at Destinatation, sink is the only viable solution that is out there today. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Suresh Ramasubramanian" wrote: > On Fri, Feb 13, 2009 at 8:27 PM, Jens Ott - PlusServer AG > wrote: > > - - What do you think about such service? > > - - Would you/your ASN participate in such a service? > > - - Do you see some kind of usefull feature in such a service? > > - - Do you have any comments? > > Ah. rbl.maps.vix.com from about a decade back when it was available > as > a bgp feed. But only for ddos sources. > > srs From Valdis.Kletnieks at vt.edu Fri Feb 13 10:28:57 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Feb 2009 11:28:57 -0500 Subject: Global Blackhole Service In-Reply-To: Your message of "Fri, 13 Feb 2009 15:57:32 +0100." <49958A5C.2070200@plusserver.de> References: <49958A5C.2070200@plusserver.de> Message-ID: <10790.1234542537@turing-police.cc.vt.edu> On Fri, 13 Feb 2009 15:57:32 +0100, Jens Ott - PlusServer AG said: > Therefore I had the following idea: Why not taking one of my old routers and > set it up as blackhole-service. Then everyone who is interested could set up a > session to there and > > 1.) announce /32 (/128) routes out of his prefixes to blackhole them > 2.) receive all the /32 (/128) announcements from the other peers with the IPs > they want to have blackholed and rollout the blackhole to their network. How do you vet proposed new entries to make sure that some miscreant doesn't DoS a legitimate site by claiming it is in need of black-holing? Note that it's a different problem space than a bogon BGP feed or a spam-source BGP feed - if the Cymru guys take another 6 hours to do a proper paperwork and background check to verify a bogon, or if Paul and company take another day to verify something really *is* a cesspit of spam sources, it doesn't break the basic concept or usability of the feed. You usually don't *have* a similar luxury if you're trying to deal with a DDoS, because those are essentially a real-time issue. Oh, and cleaning up an entry in a timely fashion is also important, otherwise an attacker can launch a DDoS, get the target into the feed, and walk away... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From ops.lists at gmail.com Fri Feb 13 10:34:06 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 13 Feb 2009 22:04:06 +0530 Subject: Global Blackhole Service In-Reply-To: <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> Message-ID: DDoS drones - especially with botnets - can produce a really large zone To start with google "spamhaus drop list". Then look at the cbl and see if you think its worth using as a bgp feed On Fri, Feb 13, 2009 at 9:20 PM, Nuno Vieira - nfsi telecom wrote: > Hi Suresh, > > But in the meanwhile, a decade later, it does not longer exist. > > At least, i can't reach that host, and i was unable to find working documentation on google of how about this project works, today. > > In fact, the first link that google gave out, says that this project is dead at least 2 years ago. > > http://www.dnsbl.com/2007/02/status-of-rblmapsvixcom-invalid-domain.html > > I think that we all have a real opportunity here for make something that can be useful to all. > > And, we are not talk of spam here, but, to mitigate time, money and patience consuming DDoS attacks, which often are easier to mitigate only at the Source and at the Destination, while at Destinatation, sink is the only viable solution that is out there today. > > regards, > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Suresh Ramasubramanian" wrote: > >> On Fri, Feb 13, 2009 at 8:27 PM, Jens Ott - PlusServer AG >> wrote: >> > - - What do you think about such service? >> > - - Would you/your ASN participate in such a service? >> > - - Do you see some kind of usefull feature in such a service? >> > - - Do you have any comments? >> >> Ah. rbl.maps.vix.com from about a decade back when it was available >> as >> a bgp feed. But only for ddos sources. >> >> srs > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jbates at brightok.net Fri Feb 13 10:41:12 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 13 Feb 2009 10:41:12 -0600 Subject: Global Blackhole Service In-Reply-To: <10790.1234542537@turing-police.cc.vt.edu> References: <49958A5C.2070200@plusserver.de> <10790.1234542537@turing-police.cc.vt.edu> Message-ID: <4995A2A8.3000002@brightok.net> Valdis.Kletnieks at vt.edu wrote: > How do you vet proposed new entries to make sure that some miscreant doesn't > DoS a legitimate site by claiming it is in need of black-holing? Note that > it's a different problem space than a bogon BGP feed or a spam-source BGP > feed - if the Cymru guys take another 6 hours to do a proper paperwork and > background check to verify a bogon, or if Paul and company take another day > to verify something really *is* a cesspit of spam sources, it doesn't break the > basic concept or usability of the feed. > Presumably, the route server would have to have the same guidelines as issued by service providers. ie, /32 networks injected should come from authenticated feeds and fall within the netblock range owned by the injector. So one extra set of ACL's for each injector to upkeep. I believe what is being suggested is just one step beyond what many providers give to BGP customers to extend blackholes out. > Oh, and cleaning up an entry in a timely fashion is also important, otherwise > an attacker can launch a DDoS, get the target into the feed, and walk away... This also would be decided by the injecting provider. More of a "Hey, one of my IPs is being DDOS'd, please drop traffic to it to protect the rest of my network." The downside to widespread use, is that it makes tracking the problem on the other side of the blocks near impossible. In all cases, once a blackhole is initiated anywhere, the DDOS has been successful. We use automatic community changes to accept /32 blackholes from customers, verify them, then send them on to peers that also support /32 blackholes with appropriate communities. Jack Jack From nuno.vieira at nfsi.pt Fri Feb 13 10:41:41 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Fri, 13 Feb 2009 16:41:41 +0000 (WET) Subject: Global Blackhole Service In-Reply-To: <10790.1234542537@turing-police.cc.vt.edu> Message-ID: <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> Ok, however, what i am talking about is a competelly diferent thing, and i think that my thoughts are alligned with Jens. We want to have a Sink-BGP-BL, based on Destination. Imagine, i as an ISP, host a particular server that is getting nn Gbps of DDoS attack. I null route it, and start advertising a /32 to my upstream providers with a community attached, for them to null route it at their network. However, the attacks continue going, on and on, often flooding internet exchange connections and so. A solution like this, widelly used, would prevent packets to leave their home network, mitigating with effective any kind of DDoS (or packet flooding). Obviously, we need a few people to build this (A Website, an organization), where when a new ISP connects is added to the system, a prefix list should be implemented, preventing that ISP to announce IP addresses that DON'T belong to him. The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, and those member ISP's, should apply route-maps or whatever they want, but, in the end they want to discard the traffic to those prefixes (ex: Null0 or /dev/null). This is a matter or getting enough people to kick this off, to build a website, to establish one or two route-servers and to give use to. Once again, i am interested on this, if others are aswell, let know. This should be a community-driven project. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Valdis Kletnieks" wrote: > How do you vet proposed new entries to make sure that some miscreant > doesn't > DoS a legitimate site by claiming it is in need of black-holing? Note > that > it's a different problem space than a bogon BGP feed or a spam-source > BGP > feed - if the Cymru guys take another 6 hours to do a proper paperwork > and > background check to verify a bogon, or if Paul and company take > another day > to verify something really *is* a cesspit of spam sources, it doesn't > break the > basic concept or usability of the feed. > > You usually don't *have* a similar luxury if you're trying to deal > with a > DDoS, because those are essentially a real-time issue. > > Oh, and cleaning up an entry in a timely fashion is also important, > otherwise > an attacker can launch a DDoS, get the target into the feed, and walk > away... From vixie at isc.org Fri Feb 13 10:57:24 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 13 Feb 2009 16:57:24 +0000 Subject: Global Blackhole Service In-Reply-To: <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> (Nuno Vieira's message of "Fri\, 13 Feb 2009 15\:50\:29 +0000 \(WET\)") References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> Message-ID: wrote: > > > - - What do you think about such service? > > > - - Would you/your ASN participate in such a service? > > > - - Do you see some kind of usefull feature in such a service? > > > - - Do you have any comments? ----- "Suresh Ramasubramanian" wrote: > > Ah. rbl.maps.vix.com from about a decade back when it was available as > > a bgp feed. But only for ddos sources. Nuno Vieira - nfsi telecom writes: > But in the meanwhile, a decade later, it does not longer exist. it still exists (same ASN, different bgp peer address) as a commercial service now operated by Trend Micro. noncommercial alternatives exist, considering here the Spamhaus and Cymru offerings. (i regret that i was unable to continue the service noncommercially, but lawyers are expensive, and volunteers burn out faster than employees, and so on.) > In fact, the first link that google gave out, says that this project is > dead at least 2 years ago. > > http://www.dnsbl.com/2007/02/status-of-rblmapsvixcom-invalid-domain.html fun. perhaps i'll stop getting 100+ queries per second to the nameservers of rbl.maps.vix.com some day before i die, now that google is on my side. > I think that we all have a real opportunity here for make something that > can be useful to all. i think Spamhaus and Cymru are way ahead of you in implementing such a thing, and it's likely that there are even commercial alternatives to Trend Micro although i have not kept up on those details. -- Paul Vixie From Skywing at valhallalegends.com Fri Feb 13 11:08:29 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 13 Feb 2009 11:08:29 -0600 Subject: Global Blackhole Service Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6C01BB6A2BE@caralain.haven.nynaeve.net> Of course, whomever hosts such a service becomes an attractive DoS target themselves if it were ever to gain real traction in the field. There is also the "reverse-DoS" issue of an innocent party getting into the feed if anyone can peer with it. - S -----Original Message----- From: Nuno Vieira - nfsi telecom Sent: Friday, February 13, 2009 07:13 To: Jens Ott - PlusServer AG Cc: nanog Subject: Re: Global Blackhole Service Hi Jens, I think we are in the same boat. We suffered the same problem often, on a lower magnitude, but if a project like this exists those DDoS could even be almost near zero. This is somewhat similar to what Spamcop, and other folks do with SPAM today, but applied on a diferent scope, say, BGP Blackhole. This service can span wide after just peers, opening the opportunity to edge-to-edge DDoS mitigation. Say, a network in .pt or .de is beign attacked at large, and dst operators inject the dst attacked source on the blackhole bgp feed... say that 100+ other ops around the world use a cen?rio like this... this might be very useful. concers: the "autohority" or the "responsible" for maintaining this project, must assure that OP A or OP B can *only* annouce chunks that below to him, avoiding any case of hijack. We would be interested in participating in something like this. So, > My questions to all of you: > > - - What do you think about such service? It will be great. We are available to help. > - - Would you/your ASN participate in such a service? Yes. > - - Do you see some kind of usefull feature in such a service? Yes, a few thoughts above, some more might come up. > - - Do you have any comments? For starters, a few above. Regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Jens Ott - PlusServer AG" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > in the last 24 hours we received two denial of service attacks with > something > like 6-8GBit volume. It did not harm us too much, but e.g. one of our > upstreams got his Amsix-Port exploded. > > With our upstreams we have remote-blackhole sessions running where we > announce > /32 prefixes to blackhole at their edge, but this does not work with > our > peers. Also our Decix-Port received something like 2Gbit extra-traffic > during > this DoS. > > I can imagine, that for some peers, especially for the once having > only a thin > fiber (e.g. 1GBit) to Decix, it's not to funny having it flooded with > a DoS > and that they might be interested in dropping such traffic at their > edge. > > Well I could discuss with my peers (at least the once who might get in > trouble > with such issue) to do some individual config for some > blackhole-announcement, > but most probably I'm not the only one receiving DoS and who would be > interested in such setup. > > Therefore I had the following idea: Why not taking one of my old > routers and > set it up as blackhole-service. Then everyone who is interested could > set up a > session to there and > > 1.) announce /32 (/128) routes out of his prefixes to blackhole them > 2.) receive all the /32 (/128) announcements from the other peers with > the IPs > they want to have blackholed and rollout the blackhole to their > network. > > My questions to all of you: > > - - What do you think about such service? > - - Would you/your ASN participate in such a service? > - - Do you see some kind of usefull feature in such a service? > - - Do you have any comments? > > Thank you for telling me your opinions and best regards > > - -- > =================================================================== > > Jens Ott > Leiter Network Management > > Tel: +49 22 33 - 612 - 3501 > Fax: +49 22 33 - 612 - 53501 > > E-Mail: j.ott at plusserver.de > GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A > > PlusServer AG > Daimlerstra?e 9-11 > 50354 H?rth > > Germany > > HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 > Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe > Aufsichtsratsvorsitz: Claudius Schmalschl?ger > > =================================================================== > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmVilwACgkQMf0yjMLKfXpNuQCeKcicthIadISe7I+Xs5ZNHS+1 > 0qUAnRDkOY9/6kokq3Hf68BRQFfkP3xy > =jKUA > -----END PGP SIGNATURE----- From smb at cs.columbia.edu Fri Feb 13 11:15:53 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 13 Feb 2009 12:15:53 -0500 Subject: Global Blackhole Service In-Reply-To: <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> Message-ID: <20090213121553.1aea266c@cs.columbia.edu> On Fri, 13 Feb 2009 16:41:41 +0000 (WET) Nuno Vieira - nfsi telecom wrote: > Ok, however, what i am talking about is a competelly diferent thing, > and i think that my thoughts are alligned with Jens. > > We want to have a Sink-BGP-BL, based on Destination. > > Imagine, i as an ISP, host a particular server that is getting nn > Gbps of DDoS attack. I null route it, and start advertising a /32 to > my upstream providers with a community attached, for them to null > route it at their network. However, the attacks continue going, on > and on, often flooding internet exchange connections and so. > > A solution like this, widelly used, would prevent packets to leave > their home network, mitigating with effective any kind of DDoS (or > packet flooding). > > Obviously, we need a few people to build this (A Website, an > organization), where when a new ISP connects is added to the system, > a prefix list should be implemented, preventing that ISP to announce > IP addresses that DON'T belong to him. > > The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, > and those member ISP's, should apply route-maps or whatever they > want, but, in the end they want to discard the traffic to those > prefixes (ex: Null0 or /dev/null). > > This is a matter or getting enough people to kick this off, to build > a website, to establish one or two route-servers and to give use to. > > Once again, i am interested on this, if others are aswell, let know. > This should be a community-driven project. > In other words, a legitimate prefix hijacking service... As Randy and Valdis have pointed out, if this isn't done very carefully it's an open invitation to a new, very effective DoS technique. You can't do this without authoritative knowledge of exactly who owns any prefix; you also have to be able to authenticate the request to blackhole it. Those two points are *hard*. I also note that the scheme as described here is incompatible with more or less any possible secured BGP, since by definition it involves an AS that doesn't own a prefix advertising a route to it. --Steve Bellovin, http://www.cs.columbia.edu/~smb From j.ott at plusserver.de Fri Feb 13 11:16:44 2009 From: j.ott at plusserver.de (Jens Ott - PlusServer AG) Date: Fri, 13 Feb 2009 18:16:44 +0100 Subject: Global Blackhole Service In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6C01BB6A2BE@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6C01BB6A2BE@caralain.haven.nynaeve.net> Message-ID: <4995AAFC.1020907@plusserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Skywing schrieb: > Of course, whomever hosts such a service becomes an attractive DoS target themselves if it were ever to gain real traction in the field. There is also the "reverse-DoS" issue of an innocent party getting into the feed if anyone can peer with it. You are right, and that's also what I am currently thinking about. Well, one solution might be, that all participants blackhole-routers IPs are also announced with some special community and all participants drop all traffic but bgp traffic from IPs listed with that community to the blackhole RR destination(s) everywhere in there network. BR Jens > > - S > > -----Original Message----- > From: Nuno Vieira - nfsi telecom > Sent: Friday, February 13, 2009 07:13 > To: Jens Ott - PlusServer AG > Cc: nanog > Subject: Re: Global Blackhole Service > > > Hi Jens, > > I think we are in the same boat. > > We suffered the same problem often, on a lower magnitude, but if a project like this exists those DDoS could even be almost near zero. > > This is somewhat similar to what Spamcop, and other folks do with SPAM today, but applied on a diferent scope, say, BGP Blackhole. > > This service can span wide after just peers, opening the opportunity to edge-to-edge DDoS mitigation. > > Say, a network in .pt or .de is beign attacked at large, and dst operators inject the dst attacked source on the blackhole bgp feed... say that 100+ other ops around the world use a cen?rio like this... this might be very useful. > concers: the "autohority" or the "responsible" for maintaining this project, must assure that OP A or OP B can *only* annouce chunks that below to him, avoiding any case of hijack. > > We would be interested in participating in something like this. > > So, > >> My questions to all of you: >> >> - - What do you think about such service? > > It will be great. We are available to help. > >> - - Would you/your ASN participate in such a service? > > Yes. > >> - - Do you see some kind of usefull feature in such a service? > > Yes, a few thoughts above, some more might come up. > >> - - Do you have any comments? > > For starters, a few above. > > Regards, > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Jens Ott - PlusServer AG" wrote: > > Hi, > > in the last 24 hours we received two denial of service attacks with > something > like 6-8GBit volume. It did not harm us too much, but e.g. one of our > upstreams got his Amsix-Port exploded. > > With our upstreams we have remote-blackhole sessions running where we > announce > /32 prefixes to blackhole at their edge, but this does not work with > our > peers. Also our Decix-Port received something like 2Gbit extra-traffic > during > this DoS. > > I can imagine, that for some peers, especially for the once having > only a thin > fiber (e.g. 1GBit) to Decix, it's not to funny having it flooded with > a DoS > and that they might be interested in dropping such traffic at their > edge. > > Well I could discuss with my peers (at least the once who might get in > trouble > with such issue) to do some individual config for some > blackhole-announcement, > but most probably I'm not the only one receiving DoS and who would be > interested in such setup. > > Therefore I had the following idea: Why not taking one of my old > routers and > set it up as blackhole-service. Then everyone who is interested could > set up a > session to there and > > 1.) announce /32 (/128) routes out of his prefixes to blackhole them > 2.) receive all the /32 (/128) announcements from the other peers with > the IPs > they want to have blackholed and rollout the blackhole to their > network. > > My questions to all of you: > > - What do you think about such service? > - Would you/your ASN participate in such a service? > - Do you see some kind of usefull feature in such a service? > - Do you have any comments? > > Thank you for telling me your opinions and best regards > - -- =================================================================== Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j.ott at plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstra?e 9-11 50354 H?rth Germany HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschl?ger =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVqvwACgkQMf0yjMLKfXp1OgCfcvTgueonvW4z0dOash9KWUb0 pjMAniZprPAM14H477EHy4I0Ccd9nqy4 =EH0/ -----END PGP SIGNATURE----- From j.ott at plusserver.de Fri Feb 13 11:18:00 2009 From: j.ott at plusserver.de (Jens Ott - PlusServer AG) Date: Fri, 13 Feb 2009 18:18:00 +0100 Subject: Global Blackhole Service In-Reply-To: <4995A2A8.3000002@brightok.net> References: <49958A5C.2070200@plusserver.de> <10790.1234542537@turing-police.cc.vt.edu> <4995A2A8.3000002@brightok.net> Message-ID: <4995AB48.80002@plusserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 @jack: sorry for duplicate ... pressed reply instead of reply-all ;) Jack Bates schrieb: > Valdis.Kletnieks at vt.edu wrote: > Presumably, the route server would have to have the same guidelines as > issued by service providers. ie, /32 networks injected should come from > authenticated feeds and fall within the netblock range owned by the > injector. So one extra set of ACL's for each injector to upkeep. I > believe what is being suggested is just one step beyond what many > providers give to BGP customers to extend blackholes out. Exactly that's the way I intended. I know that it's a not to small thing to maintain such a system, we are running it successfully for years with both, downstream-bgp-customers and upstreams. Even with quiet a small number of downstreams there are several changes each month (new IP-Space, drop-off of PI moved away from the customer ...), but I think it would be a manageable thing to keep it up2date when preparing some automatism. E.g. a automated prefix-list-generator requesting the authorization (e.g. automated mail with link including authorization-hash) for blackholing at the AS-Owner before accepting prefixes ... > >> Oh, and cleaning up an entry in a timely fashion is also important, >> otherwise >> an attacker can launch a DDoS, get the target into the feed, and walk >> away... > > This also would be decided by the injecting provider. More of a "Hey, > one of my IPs is being DDOS'd, please drop traffic to it to protect the > rest of my network." The downside to widespread use, is that it makes > tracking the problem on the other side of the blocks near impossible. In > all cases, once a blackhole is initiated anywhere, the DDOS has been > successful. Well, for that single IP the DDoS was sucessfull, but looking at the issue I had yesterday, it's to protect other customers also getting into trouble due to this DoS. The complete rack had 1GBit-Uplink, which is normally absolutely sufficient for 20 servers. Well one single server was under attack, but 19 other "innocent" customers were not reachable. And, the even bigger problem was, the AMSIX-Port of one of my upstreams was "filled to death" due to this DoS and therefore several thousand customers had enormous packetloss due to one single destination-ip. Therefore it's to decide what to prefer, one single customer dead or thousands of angry customers. And I know that I prefer to protect my own backbone under these circumstances. > We use automatic community changes to accept /32 blackholes > from customers, verify them, then send them on to peers that also > support /32 blackholes with appropriate communities. That's what we currently also do and until now we never had any problem with this. BR Jens > > > Jack > > > Jack > - -- =================================================================== Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j.ott at plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstra?e 9-11 50354 H?rth Germany HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschl?ger =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVq0gACgkQMf0yjMLKfXqq+QCfW7FzEeXE8MsN3DJQcn8B/ezE EIwAoJttNgusWNFu+ebOswIBw0g6734w =5x5v -----END PGP SIGNATURE----- From jbates at brightok.net Fri Feb 13 11:22:30 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 13 Feb 2009 11:22:30 -0600 Subject: Global Blackhole Service In-Reply-To: References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> Message-ID: <4995AC56.2050501@brightok.net> Paul Vixie wrote: > i think Spamhaus and Cymru are way ahead of you in implementing such a thing, > and it's likely that there are even commercial alternatives to Trend Micro > although i have not kept up on those details. I think there's a misunderstanding from what I've read about what is being blackholed. We are not talking about blackholing the senders, but a massive scale method of blackholing the victims at the victim's request to protect infrastructure. Currently this type of service usually doesn't extend beyond one or two ASs and depending on traffic flows can still cause damage, especially through exchange points. With enough support and use, this would allow a larger portion of bad traffic to be null routed closer to the sender origination points. Since the null routing BGP servers would expect a larger routing table from these /32 networks, they would be placed at key points capable of handling the larger tables; compared to just allowing the /32's out into the wild and possibly exceeding route/memory constraints. It can also be used as authoritative information that an IP is undergoing a DOS attack, and large volumes of connections to that IP should be considered suspect. I consider this a much more useful method of detecting DOS traffic leaving your infected users than the emails which are usually sent out by those being hit by DOS. Jack From j.ott at plusserver.de Fri Feb 13 11:29:18 2009 From: j.ott at plusserver.de (Jens Ott - PlusServer AG) Date: Fri, 13 Feb 2009 18:29:18 +0100 Subject: Global Blackhole Service In-Reply-To: <20090213121553.1aea266c@cs.columbia.edu> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> Message-ID: <4995ADEE.6060907@plusserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin schrieb: > On Fri, 13 Feb 2009 16:41:41 +0000 (WET) > Nuno Vieira - nfsi telecom wrote: > >> Ok, however, what i am talking about is a competelly diferent thing, >> and i think that my thoughts are alligned with Jens. >> >> We want to have a Sink-BGP-BL, based on Destination. >> >> Imagine, i as an ISP, host a particular server that is getting nn >> Gbps of DDoS attack. I null route it, and start advertising a /32 to >> my upstream providers with a community attached, for them to null >> route it at their network. However, the attacks continue going, on >> and on, often flooding internet exchange connections and so. >> >> A solution like this, widelly used, would prevent packets to leave >> their home network, mitigating with effective any kind of DDoS (or >> packet flooding). >> >> Obviously, we need a few people to build this (A Website, an >> organization), where when a new ISP connects is added to the system, >> a prefix list should be implemented, preventing that ISP to announce >> IP addresses that DON'T belong to him. >> >> The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, >> and those member ISP's, should apply route-maps or whatever they >> want, but, in the end they want to discard the traffic to those >> prefixes (ex: Null0 or /dev/null). >> >> This is a matter or getting enough people to kick this off, to build >> a website, to establish one or two route-servers and to give use to. >> >> Once again, i am interested on this, if others are aswell, let know. >> This should be a community-driven project. >> > In other words, a legitimate prefix hijacking service... > > As Randy and Valdis have pointed out, if this isn't done very carefully > it's an open invitation to a new, very effective DoS technique. You > can't do this without authoritative knowledge of exactly who owns any > prefix; you also have to be able to authenticate the request to > blackhole it. Those two points are *hard*. As described in my earlier mail, I'd suggest to run a prefix-list generator updating informations from IRR on a regulary basis and, as soon as a new "matching" route-object appears in IRR, an automated mail might be send to the ASN-owner (address also taken from irr-records) with a confirmation-link. That way you'd need to hijack IRR-database and/or tech-c/admin-c mailbox before being able to have a prefix added to the list of prefixes accepted from your peer. > I also note that the > scheme as described here is incompatible with more or less any possible > secured BGP, since by definition it involves an AS that doesn't own a > prefix advertising a route to it. No, the router may work as Route-Reflector, so you see exactly the as-path as is and the route-reflectors own asn isn't visible at all.. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > - -- =================================================================== Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j.ott at plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstra?e 9-11 50354 H?rth Germany HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschl?ger =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVre4ACgkQMf0yjMLKfXp2oQCfS3/zTUAgjN0VegvctemS+NL6 +v0AnivXszJ0extA/mspFakX7MR3w+Y6 =gu7J -----END PGP SIGNATURE----- From tico-nanog at raapid.net Fri Feb 13 11:29:06 2009 From: tico-nanog at raapid.net (Tico) Date: Fri, 13 Feb 2009 11:29:06 -0600 Subject: Global Blackhole Service In-Reply-To: <49958A5C.2070200@plusserver.de> References: <49958A5C.2070200@plusserver.de> Message-ID: <4995ADE2.3020701@raapid.net> Jens, I would be interested in participating with a destination blackhole service, so long as peers were authenticated and only authorized to advertise /32s out of space that they are assigned -- hopefully the same OrgID is used for the ASN as the IP allocations. However, a blackhole service based on sources would be out of the question altogether in my book, unless paired with a number of third parties that could vet the "badness" of those source IPs, as is done with spam zombies. Even then I'd be very nervous about it from a "causes more [potential] problems than it fixes" standpoint, no matter how cool it would be to defang a DDoS. As for the memory requirements / "oh no! too many routes!" issue, that would be a non-issue for me. Feel free to contact me off-list if you're serious about starting this project. I think that it would be worth it to talk to the Team Cymru guys to see if they'd be interested in this. -Tico Jens Ott - PlusServer AG wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > in the last 24 hours we received two denial of service attacks with something > like 6-8GBit volume. It did not harm us too much, but e.g. one of our > upstreams got his Amsix-Port exploded. > > With our upstreams we have remote-blackhole sessions running where we announce > /32 prefixes to blackhole at their edge, but this does not work with our > peers. Also our Decix-Port received something like 2Gbit extra-traffic during > this DoS. > > I can imagine, that for some peers, especially for the once having only a thin > fiber (e.g. 1GBit) to Decix, it's not to funny having it flooded with a DoS > and that they might be interested in dropping such traffic at their edge. > > Well I could discuss with my peers (at least the once who might get in trouble > with such issue) to do some individual config for some blackhole-announcement, > but most probably I'm not the only one receiving DoS and who would be > interested in such setup. > > Therefore I had the following idea: Why not taking one of my old routers and > set it up as blackhole-service. Then everyone who is interested could set up a > session to there and > > 1.) announce /32 (/128) routes out of his prefixes to blackhole them > 2.) receive all the /32 (/128) announcements from the other peers with the IPs > they want to have blackholed and rollout the blackhole to their network. > > My questions to all of you: > > - - What do you think about such service? > - - Would you/your ASN participate in such a service? > - - Do you see some kind of usefull feature in such a service? > - - Do you have any comments? > > Thank you for telling me your opinions and best regards > > - -- > =================================================================== > > Jens Ott > Leiter Network Management > > Tel: +49 22 33 - 612 - 3501 > Fax: +49 22 33 - 612 - 53501 > > E-Mail: j.ott at plusserver.de > GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A > > PlusServer AG > Daimlerstra?e 9-11 > 50354 H?rth > > Germany > > HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 > Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe > Aufsichtsratsvorsitz: Claudius Schmalschl?ger > > =================================================================== > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmVilwACgkQMf0yjMLKfXpNuQCeKcicthIadISe7I+Xs5ZNHS+1 > 0qUAnRDkOY9/6kokq3Hf68BRQFfkP3xy > =jKUA > -----END PGP SIGNATURE----- > > From jbates at brightok.net Fri Feb 13 11:31:16 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 13 Feb 2009 11:31:16 -0600 Subject: Global Blackhole Service In-Reply-To: <20090213121553.1aea266c@cs.columbia.edu> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> Message-ID: <4995AE64.9020404@brightok.net> Steven M. Bellovin wrote: > In other words, a legitimate prefix hijacking service... > Absolutely, NOT. The origin AS will still be the AS that controls the IP space. In fact, I think SBGP would be great for a layout like this to secure down the injections. That being said, prefix lists with md5 auth are probably the best we can hope for. Routing registry macro support or a hashed authorization link sent to whois contacts to automate modification of the prefix lists would be ideal (not much different that a provider is *supposed* to do with their BGP customers). Once the peers is established and limited in scope, they can then start advertising /32 networks into the blockhole server who will pass it on to others. > As Randy and Valdis have pointed out, if this isn't done very carefully > it's an open invitation to a new, very effective DoS technique. You > can't do this without authoritative knowledge of exactly who owns any > prefix; you also have to be able to authenticate the request to > blackhole it. Those two points are *hard*. I also note that the > scheme as described here is incompatible with more or less any possible > secured BGP, since by definition it involves an AS that doesn't own a > prefix advertising a route to it. I would presume that md5 BGP peering with prefix lists developed based on public information (whois/routing registry) is about as good as any of us have it now. Granted, there are places that don't do that, and that is where we see route hijacking. A service like this would have to mandate it, to insure any /32 injected into it came from the peer that is authorized for the network the /32 belongs to. Since the AS_PATH can be maintained, I don't see an issue with secure BGP. Granted, the packets themselves won't be taking any path. Jack Bates From vixie at isc.org Fri Feb 13 11:35:38 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 13 Feb 2009 17:35:38 +0000 Subject: Global Blackhole Service In-Reply-To: Your message of "Fri, 13 Feb 2009 11:22:30 CST." <4995AC56.2050501@brightok.net> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> Message-ID: <90675.1234546538@nsa.vix.com> blackholing victims is an interesting economics proposition. you're saying the attacker must always win but that they must not be allowed to affect the infrastructure. and you're saying victims will request this, since they know they can't withstand the attack and don't want to be held responsible for damage to the infrastructure. where you lose me is where "the attacker must always win". From bgreene at senki.org Fri Feb 13 11:53:17 2009 From: bgreene at senki.org (Barry Raveendran Greene) Date: Fri, 13 Feb 2009 09:53:17 -0800 Subject: Global Blackhole Service In-Reply-To: <4995ADE2.3020701@raapid.net> References: <49958A5C.2070200@plusserver.de> <4995ADE2.3020701@raapid.net> Message-ID: <7D67856950354276A8438309F0D003B3@jnpr.net> Before everyone goes off and re-invents the wheel, please heed the advice already provide by Randy, Steve, and Valdis. Community instigated RTBH is used by a variety of Operational Security Communities. _Experience_ has demonstrated caution. _Experience_ has pointed to the ways you use these tools. _Experience_ has also demonstrated that you DO NOT let the bad guys know about the details of what you do to fight them. The people who DOS your network are most like know - if not already on NANOG! All of you what are getting fired up about a "Global Blackhole Service" ..... 1. Make sure you and your upstream have an agreement on how to work DDOS incidents. 2. Make sure you and your peer have an agreement on how to work DDOS incidents. 3. Establish a procedure for resolving DDOS incidents. 4. Get vetted and join Operational Security Communities. Details for all of this are on the NANOG archives: http://www.nanog.org/presentations/archive/ Keyword search "Security" Get this done first, then consult with your peers in those Operational Security communities. Not on a forum which every bad guy in the world who has a clue about Networking is keeping their eye on. Barry From chris_jester at suavemente.net Fri Feb 13 11:56:50 2009 From: chris_jester at suavemente.net (Chris Jester) Date: Fri, 13 Feb 2009 09:56:50 -0800 Subject: Global Blackhole Service In-Reply-To: <90675.1234546538@nsa.vix.com> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> Message-ID: Listen online to my favorite hip hop radio station http://www.Jellyradio.com On Feb 13, 2009, at 9:35 AM, Paul Vixie wrote: > blackholing victims is an interesting economics proposition. you're > saying > the attacker must always win but that they must not be allowed to > affect the > infrastructure. and you're saying victims will request this, since > they know > they can't withstand the attack and don't want to be held > responsible for > damage to the infrastructure. > > where you lose me is where "the attacker must always win". > Perhaps removing the challenge from the attacker will bore them and they lose interest? However if an attackers goal is to put someone out of business, they will keep it up until the deed is done. Identifying the attacker is important. They must be the one who is in trouble, not the victim. We have seen attackers extorting customers for money with things like "100k wired to Nevis bank account or attack continues". In any case I do not believe a victim should be responsible for infrastructure damage caused by some random criminal attacking them. While I understand that it's that customer receiving the attack; the providers must work with the customer to trace it back to the source. A hacker who thinks the customer is on a security weak provider will return seeking your other customers. However if the hacker feels you are security savvy then he may choose another target. Everyone wins. Also, rather than penalize the victim for damage, you could always unplug them to interdict the damage. By going after the hacker, you could prosecute and perhaps gain some nice press/media about the strength of your orginization as a side dish to the satisfying meal of eating your enemy? From bgreene at senki.org Fri Feb 13 12:03:38 2009 From: bgreene at senki.org (Barry Raveendran Greene) Date: Fri, 13 Feb 2009 10:03:38 -0800 Subject: Global Blackhole Service In-Reply-To: <4995AC56.2050501@brightok.net> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> Message-ID: <5EB22AB1947F44ADB3F0E00022423680@jnpr.net> FYI - I think Paul knows exactly what you are talking about. Hint - review the seminar: http://www.nanog.org/meetings/nanog36/abstracts.php?pt=Mzk5Jm5hbm9nMzY=&nm=n anog36 > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Friday, February 13, 2009 9:23 AM > To: Paul Vixie > Cc: nanog at merit.edu > Subject: Re: Global Blackhole Service > > Paul Vixie wrote: > > i think Spamhaus and Cymru are way ahead of you in > implementing such a > > thing, and it's likely that there are even commercial > alternatives to > > Trend Micro although i have not kept up on those details. > > I think there's a misunderstanding from what I've read about > what is being blackholed. We are not talking about > blackholing the senders, but a massive scale method of > blackholing the victims at the victim's request to protect > infrastructure. Currently this type of service usually > doesn't extend beyond one or two ASs and depending on traffic > flows can still cause damage, especially through exchange points. > > With enough support and use, this would allow a larger > portion of bad traffic to be null routed closer to the sender > origination points. Since the null routing BGP servers would > expect a larger routing table from these /32 networks, they > would be placed at key points capable of handling the larger > tables; compared to just allowing the /32's out into the wild > and possibly exceeding route/memory constraints. > > It can also be used as authoritative information that an IP > is undergoing a DOS attack, and large volumes of connections > to that IP should be considered suspect. I consider this a > much more useful method of detecting DOS traffic leaving your > infected users than the emails which are usually sent out by > those being hit by DOS. > > > Jack > > > From jbates at brightok.net Fri Feb 13 12:04:49 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 13 Feb 2009 12:04:49 -0600 Subject: Global Blackhole Service In-Reply-To: <90675.1234546538@nsa.vix.com> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> Message-ID: <4995B641.7000308@brightok.net> Paul Vixie wrote: > blackholing victims is an interesting economics proposition. you're saying > the attacker must always win but that they must not be allowed to affect the > infrastructure. and you're saying victims will request this, since they know > they can't withstand the attack and don't want to be held responsible for > damage to the infrastructure. Blackholing victims is what is current practice. For each stage of affected infrastructure, the business/provider will make requests to their peers to blackhole the victim IP to protect the bandwidth caps or router throughput caps. Most providers, I imagine, don't ask the victim. The victim is unintentionally in violation of a TOS or AUP in many cases, but just as importantly, the provider can point out that the service to the customer was useless to begin with, and so the provider protected the rest of the customers who were not directly attacked. Sometimes the attack is to something simple, like the IP of a modem bank or router just upstream of the intended victim. Such cases are no-brainers. We didn't need public access to that IP anyways. It'll break a few traceroutes, but otherwise, business goes on. In a few cases, it has been the end target IP of a customer which was dynamic in nature. The IP was blackholed for 3-5 days and the customer was transfered to a new IP and warned not to piss off the attacker. > > where you lose me is where "the attacker must always win". Do you have a miraculous way to stop DDOS? Is there now a way to quickly and efficiently track down forged packets? Is there a remedy to shutting down the *known* botnets, not to mention the unknown ones? The attacker will always win if he has a large enough attack platform/botnet. Attacks aren't random in nature. Someone pissed someone else off that was, or knew someone who was, self proclaimed l33t. How many threads are in nanog archives on using prefix lists, uRPF, etc? Most of the problems that allow DDOS traffic are not technical problems, as much as they are economic and political problems. While all this is worked out, we have one solution we know works. If we null route the victim IP, the traffic stops at the null route. Since most attackers don't care to DOS the ISP, but just to take care of that end point, they usually don't start shifting targets to try and keep the ISP itself out. Jack From cscora at apnic.net Fri Feb 13 12:17:47 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Feb 2009 04:17:47 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200902131817.n1DIHlwS001629@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 14 Feb, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 279513 Prefixes after maximum aggregation: 133074 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 136951 Total ASes present in the Internet Routing Table: 30575 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 26606 Origin ASes announcing only one prefix: 12952 Transit ASes present in the Internet Routing Table: 3969 Transit-only ASes present in the Internet Routing Table: 93 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 530 Unregistered ASNs in the Routing Table: 181 Number of 32-bit ASNs allocated by the RIRs: 100 Prefixes from 32-bit ASNs in the Routing Table: 15 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 229 Number of addresses announced to Internet: 2001869152 Equivalent to 119 /8s, 82 /16s and 25 /24s Percentage of available address space announced: 54.0 Percentage of allocated address space announced: 63.2 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 75.7 Total number of prefixes smaller than registry allocations: 137208 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 64538 Total APNIC prefixes after maximum aggregation: 23028 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 61376 Unique aggregates announced from the APNIC address blocks: 27784 APNIC Region origin ASes present in the Internet Routing Table: 3532 APNIC Prefixes per ASN: 17.38 APNIC Region origin ASes announcing only one prefix: 955 APNIC Region transit ASes present in the Internet Routing Table: 550 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 401272544 Equivalent to 23 /8s, 234 /16s and 238 /24s Percentage of available APNIC address space announced: 79.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123310 Total ARIN prefixes after maximum aggregation: 65208 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 92830 Unique aggregates announced from the ARIN address blocks: 35508 ARIN Region origin ASes present in the Internet Routing Table: 12768 ARIN Prefixes per ASN: 7.27 ARIN Region origin ASes announcing only one prefix: 4910 ARIN Region transit ASes present in the Internet Routing Table: 1219 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 414191136 Equivalent to 24 /8s, 176 /16s and 14 /24s Percentage of available ARIN address space announced: 79.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 63332 Total RIPE prefixes after maximum aggregation: 37311 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 58109 Unique aggregates announced from the RIPE address blocks: 38768 RIPE Region origin ASes present in the Internet Routing Table: 12667 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 6658 RIPE Region transit ASes present in the Internet Routing Table: 1917 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 388763232 Equivalent to 23 /8s, 44 /16s and 14 /24s Percentage of available RIPE address space announced: 82.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23309 Total LACNIC prefixes after maximum aggregation: 5725 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 21464 Unique aggregates announced from the LACNIC address blocks: 11842 LACNIC Region origin ASes present in the Internet Routing Table: 1064 LACNIC Prefixes per ASN: 20.17 LACNIC Region origin ASes announcing only one prefix: 343 LACNIC Region transit ASes present in the Internet Routing Table: 178 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 60696704 Equivalent to 3 /8s, 158 /16s and 40 /24s Percentage of available LACNIC address space announced: 60.3 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4526 Total AfriNIC prefixes after maximum aggregation: 1392 AfriNIC Deaggregation factor: 3.25 Prefixes being announced from the AfriNIC address blocks: 4100 Unique aggregates announced from the AfriNIC address blocks: 1391 AfriNIC Region origin ASes present in the Internet Routing Table: 284 AfriNIC Prefixes per ASN: 14.44 AfriNIC Region origin ASes announcing only one prefix: 86 AfriNIC Region transit ASes present in the Internet Routing Table: 58 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC addresses announced to Internet: 9995264 Equivalent to 0 /8s, 152 /16s and 132 /24s Percentage of available AfriNIC address space announced: 29.8 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1654 6924 381 Korea Telecom (KIX) 17488 1524 110 98 Hathway IP Over Cable Interne 4755 1208 429 178 TATA Communications formerly 9583 1083 107 362 Sify Limited 4134 904 16247 368 CHINANET-BACKBONE 18101 754 190 27 Reliance Infocom Ltd Internet 7545 720 158 97 TPG Internet Pty Ltd 9498 682 297 53 BHARTI BT INTERNET LTD. 24560 671 228 174 Bharti Airtel Ltd. 9829 639 491 19 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4368 3433 344 bellsouth.net, inc. 209 2833 4035 615 Qwest 1785 1786 733 139 PaeTec Communications, Inc. 4323 1638 1081 375 Time Warner Telecom 20115 1592 1417 726 Charter Communications 7018 1439 5877 993 AT&T WorldNet Services 2386 1253 714 895 AT&T Data Communications Serv 6478 1235 293 501 AT&T Worldnet Services 11492 1226 192 12 Cable One 3356 1141 10976 439 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1075 188 7 TEDATA 3292 443 1762 388 TDC Tele Danmark 30890 439 88 201 SC Kappa Invexim SRL 12479 397 578 6 Uni2 Autonomous System 3320 339 7064 290 Deutsche Telekom AG 3301 338 1669 304 TeliaNet Sweden 8866 336 109 22 Bulgarian Telecommunication C 3215 331 2946 103 France Telecom Transpac 29049 331 26 3 AzerSat LLC. 8551 312 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1484 2834 230 UniNet S.A. de C.V. 10620 747 163 92 TVCABLE BOGOTA 11830 694 299 9 Instituto Costarricense de El 22047 619 302 14 VTR PUNTO NET S.A. 7303 511 255 79 Telecom Argentina Stet-France 6471 439 95 42 ENTEL CHILE S.A. 16814 427 27 11 NSS, S.A. 11172 407 118 75 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 371 506 23 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 651 74 39 LINKdotNET AS number 20858 276 34 3 This AS will be used to conne 3741 271 857 229 The Internet Solution 2018 242 215 142 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 128 15 8 Ci Telecom Autonomous system 5536 119 7 20 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 115 523 64 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4368 3433 344 bellsouth.net, inc. 209 2833 4035 615 Qwest 1785 1786 733 139 PaeTec Communications, Inc. 4766 1654 6924 381 Korea Telecom (KIX) 4323 1638 1081 375 Time Warner Telecom 20115 1592 1417 726 Charter Communications 17488 1524 110 98 Hathway IP Over Cable Interne 8151 1484 2834 230 UniNet S.A. de C.V. 7018 1439 5877 993 AT&T WorldNet Services 2386 1253 714 895 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2833 2218 Qwest 1785 1786 1647 PaeTec Communications, Inc. 17488 1524 1426 Hathway IP Over Cable Interne 4766 1654 1273 Korea Telecom (KIX) 4323 1638 1263 Time Warner Telecom 8151 1484 1254 UniNet S.A. de C.V. 11492 1226 1214 Cable One 8452 1075 1068 TEDATA 18566 1061 1051 Covad Communications 4755 1208 1030 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.12.96.0/19 15834 Menanet Communications 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:54 /12:162 /13:311 /14:575 /15:1128 /16:10327 /17:4585 /18:7857 /19:16906 /20:19888 /21:19496 /22:24720 /23:24959 /24:146354 /25:677 /26:830 /27:515 /28:104 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2844 4368 bellsouth.net, inc. 209 1576 2833 Qwest 4766 1379 1654 Korea Telecom (KIX) 17488 1305 1524 Hathway IP Over Cable Interne 1785 1196 1786 PaeTec Communications, Inc. 11492 1188 1226 Cable One 8452 1049 1075 TEDATA 18566 1042 1061 Covad Communications 2386 941 1253 AT&T Data Communications Serv 9583 931 1083 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:181 12:2192 13:2 15:21 16:3 17:5 20:35 24:1108 32:51 38:543 40:96 41:1805 43:1 44:2 47:11 52:3 55:2 56:3 57:25 58:529 59:610 60:460 61:1097 62:1120 63:2008 64:3428 65:2431 66:3539 67:1470 68:652 69:2479 70:507 71:159 72:1612 73:2 74:1420 75:203 76:305 77:777 78:545 79:321 80:968 81:823 82:547 83:397 84:604 85:989 86:400 87:624 88:349 89:1386 90:42 91:1967 92:278 93:1083 94:1097 95:415 96:91 97:179 98:192 99:16 109:1 110:1 111:1 112:79 113:83 114:175 115:221 116:1161 117:477 118:269 119:647 120:137 121:703 122:945 123:514 124:849 125:1279 128:223 129:222 130:134 131:410 132:75 133:9 134:343 135:37 136:224 137:139 138:145 139:78 140:412 141:105 142:377 143:319 144:319 145:38 146:373 147:147 148:535 149:227 150:141 151:198 152:152 153:132 154:10 155:258 156:171 157:294 158:156 159:240 160:282 161:138 162:274 163:142 164:516 165:502 166:274 167:351 168:682 169:161 170:471 171:39 172:10 173:212 174:64 178:1 186:5 187:60 189:305 190:2557 192:5813 193:4198 194:3337 195:2694 196:1068 198:3683 199:3279 200:5513 201:1492 202:7812 203:7985 204:3859 205:2166 206:2354 207:2776 208:3825 209:3477 210:2612 211:1122 212:1509 213:1713 214:68 215:30 216:4560 217:1202 218:372 219:407 220:1209 221:459 222:306 End of report From j.ott at plusserver.de Fri Feb 13 12:44:34 2009 From: j.ott at plusserver.de (Jens Ott - PlusServer AG) Date: Fri, 13 Feb 2009 19:44:34 +0100 Subject: Global Blackhole Service In-Reply-To: <4995B641.7000308@brightok.net> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> <4995B641.7000308@brightok.net> Message-ID: <4995BF92.7020401@plusserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jack Bates schrieb: > Paul Vixie wrote: > > Do you have a miraculous way to stop DDOS? Is there now a way to quickly > and efficiently track down forged packets? Is there a remedy to shutting > down the *known* botnets, not to mention the unknown ones? This is another issue, and _all_ of us are in charge to keep their net clean from outgoing DoS. Most outgoing DoS inside our network are mitigated - ok most of the time the dos'ing server is being disconnected - in less than 10 minutes, as we do not only check what's coming in, but also check what our customers are sending out. And as soon as someone forges IPs, he's disconnected unless we know what was happening (mostly hacked servers) and the issue was fixed. As it is the nature of DoS that there are lots of packets send, they can easily be identified in (s|c|net)flows ... unfortunately there are _lots_ of ISP not having automated mechanism for misuse-detection and mitigation, or if they have some, they don't care about alarms. Therefore I agree, the only practicable way to protect the majority of customers is to blackhole the IP under attack. Even if the DoS is not DDoS, but coming from one single source... 99,9% of any emails to any NOC worldwide is not being answered in less than one hour (especially in "out-shift-hours") and from the 0.1% left I bet 99,9% of the DoS are also not stopped during this hour. And one hour of DoS may make some small ISP loose more money then they earn per month! > > > While all this is worked out, we have one solution we know works. If we > null route the victim IP, the traffic stops at the null route. Since > most attackers don't care to DOS the ISP, but just to take care of that > end point, they usually don't start shifting targets to try and keep the > ISP itself out. ACK! > > Jack > - -- =================================================================== Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j.ott at plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstra?e 9-11 50354 H?rth Germany HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschl?ger =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVv5EACgkQMf0yjMLKfXptpQCeNNgDOxXWoTBHA5W5yCwifcG2 IasAnAh06DE3qry/puXzBs05pBfIMSS/ =boMf -----END PGP SIGNATURE----- From gmartine at ajax.opentransit.net Fri Feb 13 14:00:15 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Fri, 13 Feb 2009 15:00:15 -0500 Subject: TeliaSonera AS1299 Message-ID: <20090213200015.GE17743@ajax.opentransit.net> Hello, If anyone from TeliaSonera is around please contact me off-list Thanks German -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dholmes at mwdh2o.com Fri Feb 13 13:55:03 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Fri, 13 Feb 2009 11:55:03 -0800 Subject: Dark Fiber in Parker Arizona Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E086A214B@usmsxt104.mwd.h2o> I am in need of dark fiber in the Parker, Arizona area. If anyone can help please contact me off list. Thanks, David From morrowc.lists at gmail.com Fri Feb 13 13:59:01 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 13 Feb 2009 14:59:01 -0500 Subject: Global Blackhole Service In-Reply-To: <4995B641.7000308@brightok.net> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> <4995B641.7000308@brightok.net> Message-ID: <75cb24520902131159p186887eau1169aa10de91830@mail.gmail.com> On Fri, Feb 13, 2009 at 1:04 PM, Jack Bates wrote: > Paul Vixie wrote: >> >> blackholing victims is an interesting economics proposition. you're >> saying >> the attacker must always win but that they must not be allowed to affect >> the >> infrastructure. and you're saying victims will request this, since they >> know >> they can't withstand the attack and don't want to be held responsible for >> damage to the infrastructure. > > Blackholing victims is what is current practice. For each stage of affected it is A current practice.. so is filtering, so is scrubbing... there is no one answer for this. > infrastructure, the business/provider will make requests to their peers to > blackhole the victim IP to protect the bandwidth caps or router throughput > caps. or cause no one really cares about: your.mama.wears.combat.boots.tobed.com ... or other silly 95%-of attacked, things. > >> >> where you lose me is where "the attacker must always win". > > Do you have a miraculous way to stop DDOS? Is there now a way to quickly and There are purchasable answers to this problem... 3 (at least) providers in the US (and at least one now offers it globally) offer traffic scrubbing services. I know that one offers it at a very reasonable price even... > efficiently track down forged packets? Is there a remedy to shutting down you can track streams of forged packets, but that's not super important here. Forged packets actually make this part of the problem (stopping the dos) easier, not harder. > the *known* botnets, not to mention the unknown ones? > there are lots of folks tracking and shutting down botnets, it's not horribly effective in stopping this sort of thing. I can vividly recall tracking down 4 nights in a row the same 'botnet' (same controller person, different C&C and mostly different bots) as they were being used to attack a customer of mine at the time. This with the cooperation of 2 other very large ISP's in the US and one vendor security team even. In the end though a simple scrubbing solution was deemed the simplest answer for all involved. > The attacker will always win if he has a large enough attack For extreme cases this is true, but there are quite a lot of things on the spectrum which don't require super human efforts, and don't even require intervention from the ISP if proper precautions are taken at the outset. -chris From jake at nobistech.net Fri Feb 13 14:12:55 2009 From: jake at nobistech.net (Jake Mertel) Date: Fri, 13 Feb 2009 14:12:55 -0600 Subject: Global Blackhole Service In-Reply-To: <75cb24520902131159p186887eau1169aa10de91830@mail.gmail.com> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> <4995B641.7000308@brightok.net> <75cb24520902131159p186887eau1169aa10de91830@mail.gmail.com> Message-ID: <18DCD1A1EB78DF41B564964698425DE201207D3D98@srv372.exchange.nobistech.net> I think this solution addresses a number of issues that the current blackhole process lacks. Generally when a blackhole is sent to your provider, they in turn pass that on to the rest of their routers, dropping the traffic as soon as it hits their network. The traffic is still taking up just as much capacity up to that point. Were a system implemented as discussed, providers are able to prevent traffic that is known to be malicious from even exiting their network, which in the end works out better for everyone. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Friday, February 13, 2009 1:59 PM To: NANOG list Subject: Re: Global Blackhole Service On Fri, Feb 13, 2009 at 1:04 PM, Jack Bates wrote: > Paul Vixie wrote: >> >> blackholing victims is an interesting economics proposition. you're >> saying >> the attacker must always win but that they must not be allowed to affect >> the >> infrastructure. and you're saying victims will request this, since they >> know >> they can't withstand the attack and don't want to be held responsible for >> damage to the infrastructure. > > Blackholing victims is what is current practice. For each stage of affected it is A current practice.. so is filtering, so is scrubbing... there is no one answer for this. > infrastructure, the business/provider will make requests to their peers to > blackhole the victim IP to protect the bandwidth caps or router throughput > caps. or cause no one really cares about: your.mama.wears.combat.boots.tobed.com ... or other silly 95%-of attacked, things. > >> >> where you lose me is where "the attacker must always win". > > Do you have a miraculous way to stop DDOS? Is there now a way to quickly and There are purchasable answers to this problem... 3 (at least) providers in the US (and at least one now offers it globally) offer traffic scrubbing services. I know that one offers it at a very reasonable price even... > efficiently track down forged packets? Is there a remedy to shutting down you can track streams of forged packets, but that's not super important here. Forged packets actually make this part of the problem (stopping the dos) easier, not harder. > the *known* botnets, not to mention the unknown ones? > there are lots of folks tracking and shutting down botnets, it's not horribly effective in stopping this sort of thing. I can vividly recall tracking down 4 nights in a row the same 'botnet' (same controller person, different C&C and mostly different bots) as they were being used to attack a customer of mine at the time. This with the cooperation of 2 other very large ISP's in the US and one vendor security team even. In the end though a simple scrubbing solution was deemed the simplest answer for all involved. > The attacker will always win if he has a large enough attack For extreme cases this is true, but there are quite a lot of things on the spectrum which don't require super human efforts, and don't even require intervention from the ISP if proper precautions are taken at the outset. -chris From charles.regan at gmail.com Fri Feb 13 14:22:56 2009 From: charles.regan at gmail.com (Charles Regan) Date: Fri, 13 Feb 2009 16:22:56 -0400 Subject: One /22 Two ISP no BGP In-Reply-To: References: <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com> <20090207111644.GA91662@ronin.4ever.de> <20090207171656.S77937@psg.com> <20090212002303.M21699@psg.com> Message-ID: Just got final confirmation from ISP1 that they will not do BGP with us. ISP1 is Telebec. http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0&submit=Go My subnet http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0&submit=Go What can we do now ? Any suggestions ? Charles From oiyankok at yahoo.ca Fri Feb 13 14:31:01 2009 From: oiyankok at yahoo.ca (ann kok) Date: Fri, 13 Feb 2009 12:31:01 -0800 (PST) Subject: anyone knows about extreme switch Message-ID: <361300.69476.qm@web111312.mail.gq1.yahoo.com> Hi I have old model extreme switch Anyone knows about hyperterminal setting. ls null modem cable same as HP serial cables? I try both cables in this switch and can see the boot information but keyboard is not responsing ! Thank you __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ From msmith at internap.com Fri Feb 13 14:34:19 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 13 Feb 2009 15:34:19 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: References: <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com><20090207111644.GA91662@ronin.4ever.de><20090207171656.S77937@psg.com><20090212002303.M21699@psg.com> Message-ID: <65C5927BEED3C2428307863DB5C6C6FB021E15F8@cx49.800onemail.com> I see multiple paths to that block all converge at bell.ca. I don't see a route with 35911 (telebec) in the AS_PATH, unless it is start-of-string and followed by _577_ (bell.ca). They seem to be consistent... >-----Original Message----- >From: Charles Regan [mailto:charles.regan at gmail.com] >Sent: Friday, February 13, 2009 3:23 PM >To: nanog at nanog.org >Subject: Re: One /22 Two ISP no BGP > >Just got final confirmation from ISP1 that they will not do BGP with us. > >ISP1 is Telebec. >http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0& s >ubmit=Go > >My subnet >http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0 & >submit=Go > >What can we do now ? Any suggestions ? > >Charles From pstewart at nexicomgroup.net Fri Feb 13 14:50:11 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 13 Feb 2009 15:50:11 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: <65C5927BEED3C2428307863DB5C6C6FB021E15F8@cx49.800onemail.com> References: <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com><20090207111644.GA91662@ronin.4ever.de><20090207171656.S77937@psg.com><20090212002303.M21699@psg.com> <65C5927BEED3C2428307863DB5C6C6FB021E15F8@cx49.800onemail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A0203D4A0@nexus.nexicomgroup.net> Telebec's only upstream is Bell Canada (AS577) hence why you see that...;) Paul -----Original Message----- From: Michael Smith [mailto:msmith at internap.com] Sent: Friday, February 13, 2009 3:34 PM To: Charles Regan; nanog at nanog.org Subject: RE: One /22 Two ISP no BGP I see multiple paths to that block all converge at bell.ca. I don't see a route with 35911 (telebec) in the AS_PATH, unless it is start-of-string and followed by _577_ (bell.ca). They seem to be consistent... >-----Original Message----- >From: Charles Regan [mailto:charles.regan at gmail.com] >Sent: Friday, February 13, 2009 3:23 PM >To: nanog at nanog.org >Subject: Re: One /22 Two ISP no BGP > >Just got final confirmation from ISP1 that they will not do BGP with us. > >ISP1 is Telebec. >http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0& s >ubmit=Go > >My subnet >http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0 & >submit=Go > >What can we do now ? Any suggestions ? > >Charles ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From fw at deneb.enyo.de Fri Feb 13 14:59:48 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 13 Feb 2009 21:59:48 +0100 Subject: Global Blackhole Service In-Reply-To: <10790.1234542537@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Fri, 13 Feb 2009 11:28:57 -0500") References: <49958A5C.2070200@plusserver.de> <10790.1234542537@turing-police.cc.vt.edu> Message-ID: <87iqnecat7.fsf@mid.deneb.enyo.de> * Valdis Kletnieks: > On Fri, 13 Feb 2009 15:57:32 +0100, Jens Ott - PlusServer AG said: >> Therefore I had the following idea: Why not taking one of my old routers and >> set it up as blackhole-service. Then everyone who is interested could set up a >> session to there and >> >> 1.) announce /32 (/128) routes out of his prefixes to blackhole them >> 2.) receive all the /32 (/128) announcements from the other peers with the IPs >> they want to have blackholed and rollout the blackhole to their network. > > How do you vet proposed new entries to make sure that some miscreant doesn't > DoS a legitimate site by claiming it is in need of black-holing? The same way you prevent rogue announcements. 8-/ I guess an IX would be able to perform some validation of blacklisting requests, or at least provide a contractual framework. I don't think a global solution exists (beyond the "use my route server" approach, which is quite global--until there are two of them). From sethm at rollernet.us Fri Feb 13 15:06:57 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 13 Feb 2009 13:06:57 -0800 Subject: One /22 Two ISP no BGP In-Reply-To: References: <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com> <20090207111644.GA91662@ronin.4ever.de> <20090207171656.S77937@psg.com> <20090212002303.M21699@psg.com> Message-ID: <4995E0F1.5090203@rollernet.us> Charles Regan wrote: > Just got final confirmation from ISP1 that they will not do BGP with us. > > ISP1 is Telebec. > http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0&submit=Go > > My subnet > http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0&submit=Go > > What can we do now ? Any suggestions ? > Do you know who is upstream of ISP2? We've established that Telebec is only connected to Bell Canada. If ISP2 also has a connection to Bell then you don't gain anything with Telebec except this huge mess and horrible hacks to work around their lack of BGP. ~Seth From LEdouard at edrnet.com Fri Feb 13 15:11:09 2009 From: LEdouard at edrnet.com (LEdouard Louis) Date: Fri, 13 Feb 2009 16:11:09 -0500 Subject: anyone knows about extreme switch In-Reply-To: <361300.69476.qm@web111312.mail.gq1.yahoo.com> References: <361300.69476.qm@web111312.mail.gq1.yahoo.com> Message-ID: <2039ACC84D552B46A292559F7A45A14602148543@edrmail01.southport.edr.cc> We use Extreme products, but use telnet or SSH behind firewall. Can you use telnet? It provide more flexibility, but SSH is more secure Regardless of the connection the CLI configuration is the same. HyperTerminal setting? Baud rate-9600 Data bits-8 Stop bit-1 Parity-None Flow control-XON/XOFF Cable: Null-Modem RS-232 (9 pin to 25 pin) Good luck! --Louis -----Original Message----- From: ann kok [mailto:oiyankok at yahoo.ca] Sent: Friday, February 13, 2009 3:31 PM To: nanog at nanog.org Subject: anyone knows about extreme switch Hi I have old model extreme switch Anyone knows about hyperterminal setting. ls null modem cable same as HP serial cables? I try both cables in this switch and can see the boot information but keyboard is not responsing ! Thank you __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ From msmith at internap.com Fri Feb 13 15:24:20 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 13 Feb 2009 16:24:20 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0203D4A0@nexus.nexicomgroup.net> References: <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com><20090207111644.GA91662@ronin.4ever.de><20090207171656.S77937@psg.com><20090212002303.M21699@psg.com> <65C5927BEED3C2428307863DB5C6C6FB021E15F8@cx49.800onemail.com> <89D27DE3375BB6428DDCC2927489826A0203D4A0@nexus.nexicomgroup.net> Message-ID: <65C5927BEED3C2428307863DB5C6C6FB021E164C@cx49.800onemail.com> That was my implication... >-----Original Message----- >From: Paul Stewart [mailto:pstewart at nexicomgroup.net] >Sent: Friday, February 13, 2009 3:50 PM >To: Michael Smith; Charles Regan; nanog at nanog.org >Subject: RE: One /22 Two ISP no BGP > >Telebec's only upstream is Bell Canada (AS577) hence why you see >that...;) > >Paul > > >-----Original Message----- >From: Michael Smith [mailto:msmith at internap.com] >Sent: Friday, February 13, 2009 3:34 PM >To: Charles Regan; nanog at nanog.org >Subject: RE: One /22 Two ISP no BGP > >I see multiple paths to that block all converge at bell.ca. > >I don't see a route with 35911 (telebec) in the AS_PATH, unless it is >start-of-string and followed by _577_ (bell.ca). > >They seem to be consistent... > > > >>-----Original Message----- >>From: Charles Regan [mailto:charles.regan at gmail.com] >>Sent: Friday, February 13, 2009 3:23 PM >>To: nanog at nanog.org >>Subject: Re: One /22 Two ISP no BGP >> >>Just got final confirmation from ISP1 that they will not do BGP with >us. >> >>ISP1 is Telebec. >>http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0 & >s >>ubmit=Go >> >>My subnet >>http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60. 0 >& >>submit=Go >> >>What can we do now ? Any suggestions ? >> >>Charles > > > > > > >----------------------------------------------------------------------- - >---- > >"The information transmitted is intended only for the person or entity >to which it is addressed and contains confidential and/or privileged >material. If you received this in error, please contact the sender >immediately and then destroy this transmission, including all >attachments, without copying, distributing or disclosing same. Thank >you." From randy at psg.com Fri Feb 13 15:41:50 2009 From: randy at psg.com (Randy Bush) Date: Sat, 14 Feb 2009 06:41:50 +0900 Subject: Global Blackhole Service In-Reply-To: <87iqnecat7.fsf@mid.deneb.enyo.de> References: <49958A5C.2070200@plusserver.de> <10790.1234542537@turing-police.cc.vt.edu> <87iqnecat7.fsf@mid.deneb.enyo.de> Message-ID: eventually, the rpki will give you the first half, authentication of the owner of the ip space. this leaves, as smb hinted, securing the request path from the black-hole requestor to the service and of the service to the users. smb: > You can't do this without authoritative knowledge of exactly who > owns any prefix; you also have to be able to authenticate the > request to blackhole it. Those two points are *hard*. randy From msmith at internap.com Fri Feb 13 15:40:35 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 13 Feb 2009 16:40:35 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0203D4A0@nexus.nexicomgroup.net> References: <7db2dcf90902060941m41a1d4f2y41fb5b77c45caaa8@mail.gmail.com><20090207111644.GA91662@ronin.4ever.de><20090207171656.S77937@psg.com><20090212002303.M21699@psg.com> <65C5927BEED3C2428307863DB5C6C6FB021E15F8@cx49.800onemail.com> <89D27DE3375BB6428DDCC2927489826A0203D4A0@nexus.nexicomgroup.net> Message-ID: <65C5927BEED3C2428307863DB5C6C6FB021E166A@cx49.800onemail.com> >-----Original Message----- >From: Paul Stewart [mailto:pstewart at nexicomgroup.net] >Sent: Friday, February 13, 2009 3:50 PM >To: Michael Smith; Charles Regan; nanog at nanog.org >Subject: RE: One /22 Two ISP no BGP > >Telebec's only upstream is Bell Canada (AS577) hence why you see >that...;) > >Paul > ..and they are not propagating routes for anyone (no apparent bgp customers)... > >-----Original Message----- >From: Michael Smith [mailto:msmith at internap.com] >Sent: Friday, February 13, 2009 3:34 PM >To: Charles Regan; nanog at nanog.org >Subject: RE: One /22 Two ISP no BGP > >I see multiple paths to that block all converge at bell.ca. > >I don't see a route with 35911 (telebec) in the AS_PATH, unless it is >start-of-string and followed by _577_ (bell.ca). > >They seem to be consistent... > > > >>-----Original Message----- >>From: Charles Regan [mailto:charles.regan at gmail.com] >>Sent: Friday, February 13, 2009 3:23 PM >>To: nanog at nanog.org >>Subject: Re: One /22 Two ISP no BGP >> >>Just got final confirmation from ISP1 that they will not do BGP with >us. >> >>ISP1 is Telebec. >>http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0 & >s >>ubmit=Go >> >>My subnet >>http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60. 0 >& >>submit=Go >> >>What can we do now ? Any suggestions ? >> >>Charles > > > > > > >----------------------------------------------------------------------- - >---- > >"The information transmitted is intended only for the person or entity >to which it is addressed and contains confidential and/or privileged >material. If you received this in error, please contact the sender >immediately and then destroy this transmission, including all >attachments, without copying, distributing or disclosing same. Thank >you." From bzs at world.std.com Fri Feb 13 16:01:21 2009 From: bzs at world.std.com (Barry Shein) Date: Fri, 13 Feb 2009 17:01:21 -0500 Subject: Security Assessment of the Transmission Control Protocol (TCP) In-Reply-To: <4994B5AA.4080801@gont.com.ar> References: <4994B5AA.4080801@gont.com.ar> Message-ID: <18837.60849.852071.770423@world.std.com> From: Fernando Gont >While many textbooks and articles have created the myth that the >Internet protocols were designed for warfare environments, the top level >goal for the DARPA Internet Program was the sharing of large service >machines on the ARPANET. This in itself has become an oft-repeated canard. It is true that an important early rationalization for funding DARPA network research was to allow researchers at different institutions to use expensive (tens of millions of dollars) supercomputers from afar and, thus, not have to buy every worthy researcher their own O($100M) supercomputer center. However, an advantage in choosing a packet protocol (eventually IP) rather than a virtual circuit protocol as was popular around the time of its inception (e.g., IBM's SNA) was that packets could be re-routed around damage, transparently to virtual circuits built on top of the underlying packet protocol (e.g., TCP.) Routing of packets could be done dynamically on a per-packet basis if needed. And it was observed that routing around damage could at least in theory have utility in a situation where circuit facilities were being damaged in warfare so long as some route between two points remained. So these two goals are not mutually exclusive by any means. Merly providing remote access to super-computer facilities could have been accomplished with existing communication (e.g., phones and modems) and networks (e.g., SNA.) There was no need to fund the R&D of a new suite of protocols. Further: >As a result, many protocol specifications focus >only on the operational aspects of the protocols they specify, and >overlook their security implications. This is a non-sequitar and not a result at all. Neither goal implied security, only integrity. This was not an oversight, security was, and to a great extent still is, thought to be a higher-level function than packetizing and packet routing, with a few exceptions where a potential security flaw truly lies in the protocol (e.g., poor choice of packet sequence numbers.) >While the Internet technology evolved since it early inception, the >Internet?s building blocks are basically the same core protocols adopted >by the ARPANET more than two decades ago. Two decades is twenty years which takes me back to 1988. Three decades would be more accurate, e.g., the great NCP changeover which I think was 1978. I suppose arguably three decades is "more than two decades". >For some reason, much of the effort of the security community on the >Internet protocols did not result in official documents (RFCs) being >issued by the IETF (Internet Engineering Task Force). (for some reason?) To the best of my knowledge the reason is quite simple: That is not what RFCs are used for tho occasionally some summary of the state of the art appears in an RFC. The rest seems reasonably stated. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From oiyankok at yahoo.ca Fri Feb 13 16:30:41 2009 From: oiyankok at yahoo.ca (ann kok) Date: Fri, 13 Feb 2009 14:30:41 -0800 (PST) Subject: anyone knows about extreme switch In-Reply-To: <2039ACC84D552B46A292559F7A45A14602148543@edrmail01.southport.edr.cc> Message-ID: <722762.41157.qm@web111313.mail.gq1.yahoo.com> Thank you it works properly Do you know the default pw? Thank you again --- On Fri, 2/13/09, LEdouard Louis wrote: > From: LEdouard Louis > Subject: RE: anyone knows about extreme switch > To: oiyankok at yahoo.ca, nanog at nanog.org > Received: Friday, February 13, 2009, 4:11 PM > We use Extreme products, but use telnet or SSH behind > firewall. > > Can you use telnet? It provide more flexibility, but SSH is > more secure > > Regardless of the connection the CLI configuration is the > same. > > HyperTerminal setting? > > Baud rate-9600 > Data bits-8 > Stop bit-1 > Parity-None > Flow control-XON/XOFF > > Cable: Null-Modem RS-232 (9 pin to 25 pin) > > Good luck! > > --Louis > > > > -----Original Message----- > From: ann kok [mailto:oiyankok at yahoo.ca] > Sent: Friday, February 13, 2009 3:31 PM > To: nanog at nanog.org > Subject: anyone knows about extreme switch > > > Hi > > I have old model extreme switch > > Anyone knows about hyperterminal setting. > > ls null modem cable same as HP serial cables? > > I try both cables in this switch and can see the boot > information > but keyboard is not responsing ! > > Thank you > > > > > __________________________________________________________________ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ __________________________________________________________________ Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/ From LEdouard at edrnet.com Fri Feb 13 16:37:32 2009 From: LEdouard at edrnet.com (LEdouard Louis) Date: Fri, 13 Feb 2009 17:37:32 -0500 Subject: anyone knows about extreme switch In-Reply-To: <722762.41157.qm@web111313.mail.gq1.yahoo.com> References: <2039ACC84D552B46A292559F7A45A14602148543@edrmail01.southport.edr.cc> <722762.41157.qm@web111313.mail.gq1.yahoo.com> Message-ID: <2039ACC84D552B46A292559F7A45A14602148591@edrmail01.southport.edr.cc> The default user name is admin and there is no password. --Louis -----Original Message----- From: ann kok [mailto:oiyankok at yahoo.ca] Sent: Friday, February 13, 2009 5:31 PM To: nanog at nanog.org; LEdouard Louis Subject: RE: anyone knows about extreme switch Thank you it works properly Do you know the default pw? Thank you again --- On Fri, 2/13/09, LEdouard Louis wrote: > From: LEdouard Louis > Subject: RE: anyone knows about extreme switch > To: oiyankok at yahoo.ca, nanog at nanog.org > Received: Friday, February 13, 2009, 4:11 PM > We use Extreme products, but use telnet or SSH behind > firewall. > > Can you use telnet? It provide more flexibility, but SSH is > more secure > > Regardless of the connection the CLI configuration is the > same. > > HyperTerminal setting? > > Baud rate-9600 > Data bits-8 > Stop bit-1 > Parity-None > Flow control-XON/XOFF > > Cable: Null-Modem RS-232 (9 pin to 25 pin) > > Good luck! > > --Louis > > > > -----Original Message----- > From: ann kok [mailto:oiyankok at yahoo.ca] > Sent: Friday, February 13, 2009 3:31 PM > To: nanog at nanog.org > Subject: anyone knows about extreme switch > > > Hi > > I have old model extreme switch > > Anyone knows about hyperterminal setting. > > ls null modem cable same as HP serial cables? > > I try both cables in this switch and can see the boot > information > but keyboard is not responsing ! > > Thank you > > > > > __________________________________________________________________ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ __________________________________________________________________ Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/ From fernando at gont.com.ar Fri Feb 13 16:39:49 2009 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 13 Feb 2009 20:39:49 -0200 Subject: Security Assessment of the Transmission Control Protocol (TCP) In-Reply-To: <18837.60849.852071.770423@world.std.com> References: <4994B5AA.4080801@gont.com.ar> <18837.60849.852071.770423@world.std.com> Message-ID: <4995F6B5.3010205@gont.com.ar> Barry Shein wrote: > And it was observed that routing around damage could at least in > theory have utility in a situation where circuit facilities were being > damaged in warfare so long as some route between two points remained. > > So these two goals are not mutually exclusive by any means. The point of the text was to point out that "operating in warfare environments" was not the top level goal. The recent John Day?s "Patterns in Network Architecture" provides more insights in this aspec. >> As a result, many protocol specifications focus >> only on the operational aspects of the protocols they specify, and >> overlook their security implications. > > This is a non-sequitar and not a result at all. Neither goal implied > security, only integrity. > > This was not an oversight, security was, and to a great extent still > is, thought to be a higher-level function than packetizing and packet > routing, with a few exceptions where a potential security flaw truly > lies in the protocol (e.g., poor choice of packet sequence numbers.) I don't really understand what you mean. Attacks such as syn-floods and others are clearly issues that lie in the protocol design. And while it is understood that security was not a goal two or three decades ago, one would expect that it should be a goal nowadays, and that the specs should have been updated accordingly. >> For some reason, much of the effort of the security community on the >> Internet protocols did not result in official documents (RFCs) being >> issued by the IETF (Internet Engineering Task Force). > > (for some reason?) > > To the best of my knowledge the reason is quite simple: That is not > what RFCs are used for tho occasionally some summary of the state of > the art appears in an RFC. Not sure what you mean. Only *few* years ago there was some work published within the IETF about well-known issues such as, e.g., syn-floods. Think about any TCP/IP-based security issue, and most likely you will not be able to find any information about it within the RFC series. Talk with anybody that works day-to-day implementing the TCP/IP protocols, and most likely the comment you'll get about the current situation is a PITA. A few years ago I published an I-D on ICMP attacks against TCP (draft-ietf-tcpm-icmp-attacks, which is close to be published as an RFC, I believe). Known issues... but the counter-measures were not clear. The reult? Vulnerability advisories from many vendors, including Cisco, Microsoft, and the security-concious OpenBSD. I don't think it should be that hard to implement the protocols in a security-conscious way from the IETF specs. And that is the area in which this CPNI document (and the preivous "Security Assessment of the Internet Protocol") tries to help. Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nrauhauser at gmail.com Fri Feb 13 17:18:30 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Fri, 13 Feb 2009 17:18:30 -0600 Subject: Chicago Sprint convulsions? Message-ID: <9515c62d0902131518g1e98b973td276fafec6f8cd23@mail.gmail.com> Is anyone else seeing convulsions via Sprint Chicago? Lightly loaded OC3 and we've got stuff all over the net seeing crazy latency. -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From charles.regan at gmail.com Fri Feb 13 17:48:54 2009 From: charles.regan at gmail.com (Charles Regan) Date: Fri, 13 Feb 2009 19:48:54 -0400 Subject: One /22 Two ISP no BGP In-Reply-To: <4995EBF1.3060406@rollernet.us> References: <20090207171656.S77937@psg.com> <20090212002303.M21699@psg.com> <4995E0F1.5090203@rollernet.us> <4995EBF1.3060406@rollernet.us> Message-ID: The problem we have now is that we got our /22 from arin to do multihoming. If we dump tlb, no more multihoming? No /22. Is that correct? We also have a contract with tlb. $$$ 1.5yrs left... 2009/2/13, Seth Mattinen : > Charles Regan wrote: >> Isp2 is vtl not bell >> >> 2009/2/13, Seth Mattinen : >>> Charles Regan wrote: >>>> Just got final confirmation from ISP1 that they will not do BGP with us. >>>> >>>> ISP1 is Telebec. >>>> http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0&submit=Go >>>> >>>> My subnet >>>> http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0&submit=Go >>>> >>>> What can we do now ? Any suggestions ? >>>> >>> Do you know who is upstream of ISP2? We've established that Telebec is >>> only connected to Bell Canada. If ISP2 also has a connection to Bell >>> then you don't gain anything with Telebec except this huge mess and >>> horrible hacks to work around their lack of BGP. >>> >>> ~Seth >>> >> > > > Also, VTL peers with Sprint and SAVVIS. Based on this information I'd > just drop Telebec completely. They only have one upstream. You won't get > any redundancy with them since they're just giving you a connection to > Bell, which VTL already gives you. Here's the view from my SAVVIS router > with Sprint as the preferred path: > > routy-border0>show ip bgp 216.113.0.0/17 > BGP routing table entry for 216.113.0.0/17, version 78286019 > Paths: (3 available, best #1, table Default-IP-Routing-Table) > Not advertised to any peer > 1239 5769, (received & used) > 208.79.242.129 (metric 3) from 208.79.242.129 (208.79.242.129) > Origin IGP, metric 439, localpref 100, valid, internal, best > Community: 11170:1239 > 3561 5769 > 216.88.158.93 from 216.88.158.93 (206.24.210.102) > Origin IGP, localpref 90, valid, external > Community: 3561:11840 11170:3561 > 3561 5769, (received-only) > 216.88.158.93 from 216.88.158.93 (206.24.210.102) > Origin IGP, localpref 90, valid, external > Community: 3561:11840 > > > -- > Seth Mattinen sethm at rollernet.us > Roller Network LLC > -- Envoy? avec mon mobile From nanog at headcandy.org Fri Feb 13 17:49:49 2009 From: nanog at headcandy.org (Steve Church) Date: Fri, 13 Feb 2009 18:49:49 -0500 Subject: Happy 1234567890 everyone! Message-ID: Just in case you missed it. date -d "Fri Feb 13 23:31:30 UTC 2009" +%s It's like a really geeky y2k without the potential cataclysm. :) Steve From ravi at cow.org Fri Feb 13 17:54:54 2009 From: ravi at cow.org (Ravi Pina) Date: Fri, 13 Feb 2009 18:54:54 -0500 Subject: Happy 1234567890 everyone! In-Reply-To: References: Message-ID: <20090213235454.GV59570@neu.cow.org> On Fri, Feb 13, 2009 at 06:49:49PM -0500, Steve Church wrote: > Just in case you missed it. > > date -d "Fri Feb 13 23:31:30 UTC 2009" +%s > > It's like a really geeky y2k without the potential cataclysm. :) > > Steve Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19... ...by then I can only hope I am out of this profession. :) -r From sethm at rollernet.us Fri Feb 13 17:58:54 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 13 Feb 2009 15:58:54 -0800 Subject: One /22 Two ISP no BGP In-Reply-To: References: <20090207171656.S77937@psg.com> <20090212002303.M21699@psg.com> <4995E0F1.5090203@rollernet.us> <4995EBF1.3060406@rollernet.us> Message-ID: <4996093E.9090006@rollernet.us> Charles Regan wrote: > The problem we have now is that we got our /22 from arin to do multihoming. > If we dump tlb, no more multihoming? No /22. Is that correct? > > We also have a contract with tlb. > $$$ 1.5yrs left... > > There's something in there about non-multihomed sites, but I'm not familiar with it. Telebec doesn't appear to be multihomed, though. The only other thing I can think of to avoid horrible hackery is to convince them to colo a router for you to do eBGP to. Honestly, I wouldn't recommend multihoming *without* BGP. One day you'll end up with some really ugly failure mode. ~Seth From web at typo.org Fri Feb 13 17:58:56 2009 From: web at typo.org (Wayne E. Bouchard) Date: Fri, 13 Feb 2009 16:58:56 -0700 Subject: Happy 1234567890 everyone! In-Reply-To: <20090213235454.GV59570@neu.cow.org> References: <20090213235454.GV59570@neu.cow.org> Message-ID: <20090213235856.GA63079@typo.org> You haven't lived until you've lived through an epoch. On Fri, Feb 13, 2009 at 06:54:54PM -0500, Ravi Pina wrote: > On Fri, Feb 13, 2009 at 06:49:49PM -0500, Steve Church wrote: > > Just in case you missed it. > > > > date -d "Fri Feb 13 23:31:30 UTC 2009" +%s > > > > It's like a really geeky y2k without the potential cataclysm. :) > > > > Steve > > Yes... that is more like the y2k38 problem on 03:14:07 UTC > 2038-01-19... > > ...by then I can only hope I am out of this profession. :) > > -r > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From msmith at internap.com Fri Feb 13 18:01:42 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 13 Feb 2009 19:01:42 -0500 Subject: One /22 Two ISP no BGP Message-ID: <65C5927BEED3C2428307863DB5C6C6FB02006341@cx49.800onemail.com> And/or see if bell canada can sell you something diverse. ----- Original Message ----- From: Seth Mattinen To: Charles Regan Cc: nanog at nanog.org Sent: Fri Feb 13 18:58:54 2009 Subject: Re: One /22 Two ISP no BGP Charles Regan wrote: > The problem we have now is that we got our /22 from arin to do multihoming. > If we dump tlb, no more multihoming? No /22. Is that correct? > > We also have a contract with tlb. > $$$ 1.5yrs left... > > There's something in there about non-multihomed sites, but I'm not familiar with it. Telebec doesn't appear to be multihomed, though. The only other thing I can think of to avoid horrible hackery is to convince them to colo a router for you to do eBGP to. Honestly, I wouldn't recommend multihoming *without* BGP. One day you'll end up with some really ugly failure mode. ~Seth From cmadams at hiwaay.net Fri Feb 13 19:03:20 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 13 Feb 2009 19:03:20 -0600 Subject: Happy 1234567890 everyone! In-Reply-To: <20090213235454.GV59570@neu.cow.org> References: <20090213235454.GV59570@neu.cow.org> Message-ID: <20090214010320.GA1513611@hiwaay.net> Once upon a time, Ravi Pina said: > Yes... that is more like the y2k38 problem on 03:14:07 UTC > 2038-01-19... Oddly enough, the end of the current Unix epoch is a prime. Not only that, it is a Mersenne prime, 2^31 - 1. Even more, it is the largest known Mersenne prime where its Mersenne number (31) is also a Mersenne prime (2^5 - 1). You can always count on numerology. This means something! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From neito at nerdramblingz.com Fri Feb 13 19:06:27 2009 From: neito at nerdramblingz.com (Nathan Malynn) Date: Fri, 13 Feb 2009 20:06:27 -0500 Subject: Happy 1234567890 everyone! In-Reply-To: <20090214010320.GA1513611@hiwaay.net> References: <20090213235454.GV59570@neu.cow.org> <20090214010320.GA1513611@hiwaay.net> Message-ID: Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? On Fri, Feb 13, 2009 at 8:03 PM, Chris Adams wrote: > Once upon a time, Ravi Pina said: >> Yes... that is more like the y2k38 problem on 03:14:07 UTC >> 2038-01-19... > > Oddly enough, the end of the current Unix epoch is a prime. Not only > that, it is a Mersenne prime, 2^31 - 1. Even more, it is the largest > known Mersenne prime where its Mersenne number (31) is also a Mersenne > prime (2^5 - 1). > > You can always count on numerology. This means something! > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From cmadams at hiwaay.net Fri Feb 13 19:33:56 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 13 Feb 2009 19:33:56 -0600 Subject: Happy 1234567890 everyone! In-Reply-To: References: <20090213235454.GV59570@neu.cow.org> <20090214010320.GA1513611@hiwaay.net> Message-ID: <20090214013356.GB1513611@hiwaay.net> Once upon a time, Nathan Malynn said: > Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? Unix/POSIX systems use "time_t" to store the base time counter, which is seconds since the epoch (1970-01-01 00:00:00 UTC). Most platforms still use a 32 bit time_t for compatibility. However, it does appear that at some point, 64 bit Linux systems switched to a 64 bit time_t, so I can only assume others are switching as well. Hopefully, the 32 bit systems (at least that have to count seconds) will be mostly gone in another 29 years. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From eric at nixwizard.net Fri Feb 13 19:34:27 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Fri, 13 Feb 2009 18:34:27 -0700 Subject: Happy 1234567890 everyone! In-Reply-To: References: <20090213235454.GV59570@neu.cow.org> <20090214010320.GA1513611@hiwaay.net> Message-ID: <5792267e0902131734l4d85cf0cw7a1e79a73c360129@mail.gmail.com> On Fri, Feb 13, 2009 at 6:06 PM, Nathan Malynn wrote: > Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? > Exactly! What are we going to do when we're at the end of the 2^64 epoch?? (after the sun burns out and.. oh wait) -- Eric http://nixwizard.net From rveloso at cs.ucla.edu Fri Feb 13 19:39:05 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Fri, 13 Feb 2009 17:39:05 -0800 Subject: Global Blackhole Service In-Reply-To: <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> References: <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> Message-ID: <5FE62D45-EF8B-4204-B405-E144960C203D@cs.ucla.edu> Nuno et all, Count me in for this.. Cheers, --Ricardo http://www.cs.ucla.edu/~rveloso On Feb 13, 2009, at 8:41 AM, Nuno Vieira - nfsi telecom wrote: > Ok, however, what i am talking about is a competelly diferent thing, > and i think that my thoughts are alligned with Jens. > > We want to have a Sink-BGP-BL, based on Destination. > > Imagine, i as an ISP, host a particular server that is getting nn > Gbps of DDoS attack. I null route it, and start advertising a /32 > to my upstream providers with a community attached, for them to null > route it at their network. > However, the attacks continue going, on and on, often flooding > internet exchange connections and so. > > A solution like this, widelly used, would prevent packets to leave > their home network, mitigating with effective any kind of DDoS (or > packet flooding). > > Obviously, we need a few people to build this (A Website, an > organization), where when a new ISP connects is added to the system, > a prefix list should be implemented, preventing that ISP to announce > IP addresses that DON'T belong to him. > > The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, > and those member ISP's, should apply route-maps or whatever they > want, but, in the end they want to discard the traffic to those > prefixes (ex: Null0 or /dev/null). > > This is a matter or getting enough people to kick this off, to build > a website, to establish one or two route-servers and to give use to. > > Once again, i am interested on this, if others are aswell, let > know. This should be a community-driven project. > > regards, > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Valdis Kletnieks" wrote: > >> How do you vet proposed new entries to make sure that some miscreant >> doesn't >> DoS a legitimate site by claiming it is in need of black-holing? >> Note >> that >> it's a different problem space than a bogon BGP feed or a spam-source >> BGP >> feed - if the Cymru guys take another 6 hours to do a proper >> paperwork >> and >> background check to verify a bogon, or if Paul and company take >> another day >> to verify something really *is* a cesspit of spam sources, it doesn't >> break the >> basic concept or usability of the feed. >> >> You usually don't *have* a similar luxury if you're trying to deal >> with a >> DDoS, because those are essentially a real-time issue. >> >> Oh, and cleaning up an entry in a timely fashion is also important, >> otherwise >> an attacker can launch a DDoS, get the target into the feed, and walk >> away... From jgreco at ns.sol.net Fri Feb 13 20:23:42 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 13 Feb 2009 20:23:42 -0600 (CST) Subject: Happy 1234567890 everyone! In-Reply-To: <20090214013356.GB1513611@hiwaay.net> from "Chris Adams" at Feb 13, 2009 07:33:56 PM Message-ID: <200902140223.n1E2Ngks023201@aurora.sol.net> > Once upon a time, Nathan Malynn said: > > Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? > > Unix/POSIX systems use "time_t" to store the base time counter, which is > seconds since the epoch (1970-01-01 00:00:00 UTC). Most platforms still > use a 32 bit time_t for compatibility. > > However, it does appear that at some point, 64 bit Linux systems > switched to a 64 bit time_t, so I can only assume others are switching > as well. Hopefully, the 32 bit systems (at least that have to count > seconds) will be mostly gone in another 29 years. FreeBSD used a 64-bit time_t for the AMD64 port pretty much right away. On the flip side, it used a 32-bit time_t for the Alpha port. I guess someone predicted "it wouldn't be a problem." Nowhere near as annoying a problem as the variability of the size of size_t. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From cmadams at hiwaay.net Fri Feb 13 21:08:12 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 13 Feb 2009 21:08:12 -0600 Subject: Happy 1234567890 everyone! In-Reply-To: <200902140223.n1E2Ngks023201@aurora.sol.net> References: <20090214013356.GB1513611@hiwaay.net> <200902140223.n1E2Ngks023201@aurora.sol.net> Message-ID: <20090214030812.GC1513611@hiwaay.net> Once upon a time, Joe Greco said: > FreeBSD used a 64-bit time_t for the AMD64 port pretty much right away. > On the flip side, it used a 32-bit time_t for the Alpha port. I guess > someone predicted "it wouldn't be a problem." Tru64 on Alpha uses a 32 bit time_t (they have their own time64_t and time64() call), so I expect *BSD and Linux on Alpha stayed with 32 bit time_t for compatibility (Linux at least could run many Tru64 binaries). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From smb at cs.columbia.edu Fri Feb 13 21:11:40 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 13 Feb 2009 22:11:40 -0500 Subject: Happy 1234567890 everyone! In-Reply-To: <20090214030812.GC1513611@hiwaay.net> References: <20090214013356.GB1513611@hiwaay.net> <200902140223.n1E2Ngks023201@aurora.sol.net> <20090214030812.GC1513611@hiwaay.net> Message-ID: <20090213221140.2976a8de@cs.columbia.edu> On Fri, 13 Feb 2009 21:08:12 -0600 Chris Adams wrote: > Once upon a time, Joe Greco said: > > FreeBSD used a 64-bit time_t for the AMD64 port pretty much right > > away. On the flip side, it used a 32-bit time_t for the Alpha > > port. I guess someone predicted "it wouldn't be a problem." > > Tru64 on Alpha uses a 32 bit time_t (they have their own time64_t and > time64() call), so I expect *BSD and Linux on Alpha stayed with 32 bit > time_t for compatibility (Linux at least could run many Tru64 > binaries). NetBSD has just converted its -current branch to 64-bit time_t; I'm pretty sure that that includes the Alpha port. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Mark_Andrews at isc.org Sat Feb 14 02:15:12 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat, 14 Feb 2009 19:15:12 +1100 Subject: Happy 1234567890 everyone! In-Reply-To: Your message of "Fri, 13 Feb 2009 20:06:27 CDT." Message-ID: <200902140815.n1E8FCgb032809@drugs.dv.isc.org> In message , Nathan Malynn writes: > Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? No. Even if they were you have 32 bit timestamps in lots of things that have to be handled even if time/time64 returns a 64 bit timestamp. > On Fri, Feb 13, 2009 at 8:03 PM, Chris Adams wrote: > > Once upon a time, Ravi Pina said: > >> Yes... that is more like the y2k38 problem on 03:14:07 UTC > >> 2038-01-19... > > > > Oddly enough, the end of the current Unix epoch is a prime. Not only > > that, it is a Mersenne prime, 2^31 - 1. Even more, it is the largest > > known Mersenne prime where its Mersenne number (31) is also a Mersenne > > prime (2^5 - 1). > > > > You can always count on numerology. This means something! > > -- > > Chris Adams > > Systems and Network Administrator - HiWAAY Internet Services > > I don't speak for anybody but myself - that's enough trouble. > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From tkapela at gmail.com Sat Feb 14 02:25:29 2009 From: tkapela at gmail.com (Anton Kapela) Date: Sat, 14 Feb 2009 09:25:29 +0100 Subject: One /22 Two ISP no BGP In-Reply-To: <65C5927BEED3C2428307863DB5C6C6FB02006341@cx49.800onemail.com> References: <65C5927BEED3C2428307863DB5C6C6FB02006341@cx49.800onemail.com> Message-ID: <2e9d8ae50902140025j61335a80k72cc23b2dbbd1f90@mail.gmail.com> If all else fails, you could setup a pair of static IPIP or GRE tunnels using the static provider-assigned address on your link into the non-bgp speaking provider. Then, terminate the 'far side' of the tunnel on a router collocated somewhere upstream of if the brain-dead provider. This would get you a 'unicast overlay' across the brain-dead reseller of the bell.ca transit to a router where you could speak bgp to real-er transits providers, peers, or others networks. If you had the luxury of a cisco 720x/7301 pair (for your local router and upstream tunnel endpoint), you could take advantage of the transparent ip fragmentation and virtual-reassembly in 12.4, ip tcp mss 'adjustment' (to handle the 20+ bytes of lost MTU via the tunnel), and some shaping/fancy-QoS for making the (likely) congested-as-heck path in or out of this network a bit less horrible for end-users. Best, -Tk From chris at ghostbusters.co.uk Sat Feb 14 06:25:23 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sat, 14 Feb 2009 12:25:23 +0000 Subject: Linux Router: TCP slow, UDP fast Message-ID: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> Hi All, I'm losing the will to live with this networking headache ! Please feel free to point me at a Linux list if NANOG isn't suitable. I'm at a loss where else to ask. I've diagnosed some traffic oddities and after lots of head-scratching, reading and trial and error I can say with certainty that: With and without shaping and over different bandwidth providers using the e1000 driver for an Intel PRO/1000 MT Dual Port Gbps NIC (82546EB) I can replicate full, expected throughput with UDP but consistently only get 300kbps - 600kbps throughput _per connection_ for outbound TCP (I couldn't find a tool I trusted to replicate ICMP traffic). Multiple connections are cumulative and increase incrementally at roughly 300kbps - 600kbps. Inbound seems slightly erratic in holding a consistent speed but manages 15Mbps as expected, a far cry from 300kbps to 600kbps. The router is Quad Core sitting at no load and there's very little traffic being forwarded back and forth. The NIC's kernel parameters are set at default as 'built-in'. NAPI is not enabled though (enabling it requires a reboot which is a problem as this box is in production). The only other change to the box is that over Christmas IPtables (ip_conntrack and its associated modules mainly) was loaded into the kernel as 'built-in'. There's no sign of packet loss on any tests and I upped the conntrack max_connections size suitably for the amount of RAM. Has anyone come across IPtables without any rules loaded causing throughput issues ? I've also changed the following kernel parameters with no luck: net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_no_metrics_save = 1 net.core.netdev_max_backlog = 2500 echo 0 > /proc/sys/net/ipv4/tcp_window_scaling It feels to me like a buffer limit is being reached 'per connection'. The throughput spikes at around 1.54Mbps and TCP backs off to about 300kbps - 600kbps or so. What am I missing ? Is NAPI that essential for such low traffic ? A very similar build moved far higher throughput on cheap NICs. MTU is at 1500, txqueuelen is 1000. Any help would be massively appreciated ! Chris From ler762 at gmail.com Sat Feb 14 06:51:22 2009 From: ler762 at gmail.com (Lee) Date: Sat, 14 Feb 2009 07:51:22 -0500 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> Message-ID: Try enabling window scaling echo 1 > /proc/sys/net/ipv4/tcp_window_scaling or, if you really want it disabled, configure a larger minimum window size net.ipv4.tcp_rmem = 64240 87380 16777216 HTH, Lee On 2/14/09, Chris wrote: > Hi All, > > I'm losing the will to live with this networking headache ! Please feel free > to point me at a Linux list if NANOG isn't suitable. I'm at a loss where > else to ask. > > I've diagnosed some traffic oddities and after lots of head-scratching, > reading and trial and error I can say with certainty that: > > With and without shaping and over different bandwidth providers using the > e1000 driver for an Intel PRO/1000 MT Dual Port Gbps NIC (82546EB) I can > replicate full, expected throughput with UDP but consistently only get > 300kbps - 600kbps throughput _per connection_ for outbound TCP (I couldn't > find a tool I trusted to replicate ICMP traffic). Multiple connections are > cumulative and increase incrementally at roughly 300kbps - 600kbps. Inbound > seems slightly erratic in holding a consistent speed but manages 15Mbps as > expected, a far cry from 300kbps to 600kbps. > > The router is Quad Core sitting at no load and there's very little traffic > being forwarded back and forth. The NIC's kernel parameters are set at > default as 'built-in'. NAPI is not enabled though (enabling it requires a > reboot which is a problem as this box is in production). > > The only other change to the box is that over Christmas IPtables > (ip_conntrack and its associated modules mainly) was loaded into the kernel > as 'built-in'. There's no sign of packet loss on any tests and I upped the > conntrack max_connections size suitably for the amount of RAM. Has anyone > come across IPtables without any rules loaded causing throughput issues ? > > I've also changed the following kernel parameters with no luck: > > net.core.rmem_max = 16777216 > net.core.wmem_max = 16777216 > > net.ipv4.tcp_rmem = 4096 87380 16777216 > net.ipv4.tcp_wmem = 4096 65536 16777216 > > net.ipv4.tcp_no_metrics_save = 1 > > net.core.netdev_max_backlog = 2500 > > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling > > It feels to me like a buffer limit is being reached 'per connection'. The > throughput spikes at around 1.54Mbps and TCP backs off to about 300kbps - > 600kbps or so. What am I missing ? Is NAPI that essential for such low > traffic ? A very similar build moved far higher throughput on cheap NICs. > MTU is at 1500, txqueuelen is 1000. > > Any help would be massively appreciated ! > > Chris > From fw at deneb.enyo.de Sat Feb 14 06:55:02 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 14 Feb 2009 13:55:02 +0100 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> (chris@ghostbusters.co.uk's message of "Sat, 14 Feb 2009 12:25:23 +0000") References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> Message-ID: <87ab8pkwk9.fsf@mid.deneb.enyo.de> > I'm losing the will to live with this networking headache ! Please feel free > to point me at a Linux list if NANOG isn't suitable. I'm at a loss where > else to ask. The linux-net might be more appropriate indeed. > With and without shaping and over different bandwidth providers using the > e1000 driver for an Intel PRO/1000 MT Dual Port Gbps NIC (82546EB) I can > replicate full, expected throughput with UDP but consistently only get > 300kbps - 600kbps throughput _per connection_ for outbound TCP I've seen this behavior as the result of duplex mismatches. (The tcp settings are end system matters and do not affect how the router forwards traffic.) From fw at deneb.enyo.de Sat Feb 14 07:01:12 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 14 Feb 2009 14:01:12 +0100 Subject: Happy 1234567890 everyone! In-Reply-To: <200902140815.n1E8FCgb032809@drugs.dv.isc.org> (Mark Andrews's message of "Sat, 14 Feb 2009 19:15:12 +1100") References: <200902140815.n1E8FCgb032809@drugs.dv.isc.org> Message-ID: <8763jdkw9z.fsf@mid.deneb.enyo.de> * Mark Andrews: > In message , Nathan Malynn writes: >> Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? > > No. Even if they were you have 32 bit timestamps in lots > of things that have to be handled even if time/time64 returns > a 64 bit timestamp. Those values can often be interpreted as unsigned, so we get another 68 years. By then, hopefully, the required protocol updates can be fully automated. From marcus.sachs at verizon.com Sat Feb 14 07:09:14 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Sat, 14 Feb 2009 08:09:14 -0500 Subject: Happy 1234567890 everyone! In-Reply-To: <8763jdkw9z.fsf@mid.deneb.enyo.de> References: <200902140815.n1E8FCgb032809@drugs.dv.isc.org> <8763jdkw9z.fsf@mid.deneb.enyo.de> Message-ID: <81D582C724CA1046A279A7EE1299638B985AA9@FHDP1LUMXCV24.us.one.verizon.com> What about embedded systems (I'm thinking PCS, SCADA, ICS, etc.) that run a micro version of *nix? Wonder how many of them will still be warm but confused in January of 2038? Marc -----Original Message----- From: Florian Weimer [mailto:fw at deneb.enyo.de] Sent: Saturday, February 14, 2009 8:01 AM To: Mark Andrews Cc: NANOG list Subject: Re: Happy 1234567890 everyone! * Mark Andrews: > In message , Nathan Malynn writes: >> Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? > > No. Even if they were you have 32 bit timestamps in lots > of things that have to be handled even if time/time64 returns > a 64 bit timestamp. Those values can often be interpreted as unsigned, so we get another 68 years. By then, hopefully, the required protocol updates can be fully automated. From swmike at swm.pp.se Sat Feb 14 07:09:33 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 14 Feb 2009 14:09:33 +0100 (CET) Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> Message-ID: On Sat, 14 Feb 2009, Lee wrote: > Try enabling window scaling > echo 1 > /proc/sys/net/ipv4/tcp_window_scaling > or, if you really want it disabled, configure a larger minimum window size > net.ipv4.tcp_rmem = 64240 87380 16777216 Without window scaling, you're limited to 64k window size anyway. Chris, what is the round trip delay between the machines involved in your TCP session? -- Mikael Abrahamsson email: swmike at swm.pp.se From chris at ghostbusters.co.uk Sat Feb 14 07:48:53 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sat, 14 Feb 2009 13:48:53 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: <87ab8pkwk9.fsf@mid.deneb.enyo.de> References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: Thanks loads for the quick replies. I'll try and respond individually. Lee > I recently disabled tcp_window_scaling and it didn't solve the problem. I don't know enough about it. Should I enable it again ? Settings differing from defaults are copied in my first post. Mike > Strangely I'm not seeing any errors on either the ingress or egress NICs: RX packets:3371200609 errors:0 dropped:0 overruns:0 frame:0 TX packets:3412500706 errors:0 dropped:0 overruns:0 carrier:0 The only errors I see anywhere are similar on both NICs. Both connect to the same model of switch with the same default config: rx_long_byte_count: 1396158525465 rx_csum_offload_good: 3341342496 rx_csum_offload_errors: 89459 and it may be worth noting that flow control is on. Are these a reasonable level of pause frames to be seeing ? They seem to be higher on non-routing boxes. Total bytes (TX)2466202288Unicast packets (TX)3436389971Multicast packets (TX)213310Broadcast packets (TX)4952902Single Collision Frames (TX)0Late Collisions (TX)0Excessive Collisions (TX)0Transmitted Pause Frames (TX)27806 Florian > They're running without obvious errors. Auto Neg has taken 1Gbps, Full. Can Auto Neg cause these symptoms do you think ? Thanks again, Chris From nikky at mnet.bg Sat Feb 14 08:18:54 2009 From: nikky at mnet.bg (Nickola Kolev) Date: Sat, 14 Feb 2009 16:18:54 +0200 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: <20090214161854.dc5ab3ff.nikky@mnet.bg> Hello, Chris, So, as it seems you have problem with TCP, and not UDP, maybe this is something with regard to TCP segmentation offloading. It could be a total shot in the dark, but can you see what ethtool -k says? Then you can have a look at 'man ethtool' and turn on/off the appropriate stuff. On Sat, 14 Feb 2009 13:48:53 +0000 Chris wrote: > Thanks loads for the quick replies. I'll try and respond individually. > Lee > I recently disabled tcp_window_scaling and it didn't solve the > problem. I don't know enough about it. Should I enable it again ? Settings > differing from defaults are copied in my first post. > > Mike > Strangely I'm not seeing any errors on either the ingress or egress > NICs: > > RX packets:3371200609 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3412500706 errors:0 dropped:0 overruns:0 carrier:0 > > The only errors I see anywhere are similar on both NICs. Both connect to the > same model of switch with the same default config: > > rx_long_byte_count: 1396158525465 > rx_csum_offload_good: 3341342496 > rx_csum_offload_errors: 89459 > > and it may be worth noting that flow control is on. Are these a reasonable > level of pause frames to be seeing ? They seem to be higher on non-routing > boxes. > > Total bytes (TX)2466202288Unicast packets (TX)3436389971Multicast packets > (TX)213310Broadcast packets (TX)4952902Single Collision Frames (TX)0Late > Collisions (TX)0Excessive Collisions (TX)0Transmitted Pause Frames (TX)27806 > > Florian > They're running without obvious errors. Auto Neg has taken 1Gbps, > Full. Can Auto Neg cause these symptoms do you think ? > > Thanks again, > > Chris -- Best regards, Nickola From chris at ghostbusters.co.uk Sat Feb 14 08:26:22 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sat, 14 Feb 2009 14:26:22 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: <20090214161854.dc5ab3ff.nikky@mnet.bg> References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> <20090214161854.dc5ab3ff.nikky@mnet.bg> Message-ID: Thanks, Nickola. What's your opinion on these settings ? Do you recommend switching off "tcp segmentation offload" ? Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on udp fragmentation offload: off generic segmentation offload: on Thanks again, Chris From francois at menards.ca Sat Feb 14 08:41:41 2009 From: francois at menards.ca (Francois Menard) Date: Sat, 14 Feb 2009 09:41:41 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: <65C5927BEED3C2428307863DB5C6C6FB02006341@cx49.800onemail.com> References: <65C5927BEED3C2428307863DB5C6C6FB02006341@cx49.800onemail.com> Message-ID: The short story behind this deployment is that Charle's infrastructure is at the tail end of a submarine cable on an island, where there is only 1 competitor, but the ILEC, on the island side of the submarine cable. The ILEC owns the submarine cable But the ILEC will not do BGP The competitor will do BGP But the the ILEC will not do BGP Because the ILEC has yet to do BGP with anyone in its serving territory. Its a SMALL ILEC which does not have ISP customers wishing to do BGP elsewhere in its territory. I have told Charles that should he wish to complain to the regulator, to force the ILEC to do BGP, then we would help him. His question is rather - how to do multihoming on the same /22, when one the two upstream ISPs, will not do BGP. And the obvious answer is, S.O.L. The not so obvious answer, is ANYONE OUT THERE knows how to do multihoming without BGP on one of the two legs... F. -- Fran?ois D. M?nard francois at menards.ca On 13-Feb-09, at 7:01 PM, Michael Smith wrote: > And/or see if bell canada can sell you something diverse. > > > ----- Original Message ----- > From: Seth Mattinen > To: Charles Regan > Cc: nanog at nanog.org > Sent: Fri Feb 13 18:58:54 2009 > Subject: Re: One /22 Two ISP no BGP > > Charles Regan wrote: >> The problem we have now is that we got our /22 from arin to do >> multihoming. >> If we dump tlb, no more multihoming? No /22. Is that correct? >> >> We also have a contract with tlb. >> $$$ 1.5yrs left... >> >> > > > There's something in there about non-multihomed sites, but I'm not > familiar with it. Telebec doesn't appear to be multihomed, though. > > The only other thing I can think of to avoid horrible hackery is to > convince them to colo a router for you to do eBGP to. Honestly, I > wouldn't recommend multihoming *without* BGP. One day you'll end up > with > some really ugly failure mode. > > ~Seth > From francois at menards.ca Sat Feb 14 08:44:44 2009 From: francois at menards.ca (Francois Menard) Date: Sat, 14 Feb 2009 09:44:44 -0500 Subject: One /22 Two ISP no BGP In-Reply-To: References: <20090207171656.S77937@psg.com> <20090212002303.M21699@psg.com> <4995E0F1.5090203@rollernet.us> <4995EBF1.3060406@rollernet.us> Message-ID: <5F3A9B55-B54C-4012-899C-4645A7BFADA5@menards.ca> The rule with ARIN is that you only need to demonstrate that you WANT do do multihoming, not that you WILL do multihoming. That question would be better asked on the ARIN policy mailing list. I'm also on that list. That was cleared with ARIN as part of the process to get that /22 I guess ARIN rightly assumes that most ISPs do want to do BGP with their customers... F. -- Fran?ois D. M?nard francois at menards.ca On 13-Feb-09, at 6:48 PM, Charles Regan wrote: > The problem we have now is that we got our /22 from arin to do > multihoming. > If we dump tlb, no more multihoming? No /22. Is that correct? > > We also have a contract with tlb. > $$$ 1.5yrs left... > > > > > > > 2009/2/13, Seth Mattinen : >> Charles Regan wrote: >>> Isp2 is vtl not bell >>> >>> 2009/2/13, Seth Mattinen : >>>> Charles Regan wrote: >>>>> Just got final confirmation from ISP1 that they will not do BGP >>>>> with us. >>>>> >>>>> ISP1 is Telebec. >>>>> http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0&submit=Go >>>>> >>>>> My subnet >>>>> http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0&submit=Go >>>>> >>>>> What can we do now ? Any suggestions ? >>>>> >>>> Do you know who is upstream of ISP2? We've established that >>>> Telebec is >>>> only connected to Bell Canada. If ISP2 also has a connection to >>>> Bell >>>> then you don't gain anything with Telebec except this huge mess and >>>> horrible hacks to work around their lack of BGP. >>>> >>>> ~Seth >>>> >>> >> >> >> Also, VTL peers with Sprint and SAVVIS. Based on this information I'd >> just drop Telebec completely. They only have one upstream. You >> won't get >> any redundancy with them since they're just giving you a connection >> to >> Bell, which VTL already gives you. Here's the view from my SAVVIS >> router >> with Sprint as the preferred path: >> >> routy-border0>show ip bgp 216.113.0.0/17 >> BGP routing table entry for 216.113.0.0/17, version 78286019 >> Paths: (3 available, best #1, table Default-IP-Routing-Table) >> Not advertised to any peer >> 1239 5769, (received & used) >> 208.79.242.129 (metric 3) from 208.79.242.129 (208.79.242.129) >> Origin IGP, metric 439, localpref 100, valid, internal, best >> Community: 11170:1239 >> 3561 5769 >> 216.88.158.93 from 216.88.158.93 (206.24.210.102) >> Origin IGP, localpref 90, valid, external >> Community: 3561:11840 11170:3561 >> 3561 5769, (received-only) >> 216.88.158.93 from 216.88.158.93 (206.24.210.102) >> Origin IGP, localpref 90, valid, external >> Community: 3561:11840 >> >> >> -- >> Seth Mattinen sethm at rollernet.us >> Roller Network LLC >> > > -- > Envoy? avec mon mobile > From ler762 at gmail.com Sat Feb 14 08:57:13 2009 From: ler762 at gmail.com (Lee) Date: Sat, 14 Feb 2009 09:57:13 -0500 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: On 2/14/09, Chris wrote: > Thanks loads for the quick replies. I'll try and respond individually. > Lee > I recently disabled tcp_window_scaling and it didn't solve the > problem. I don't know enough about it. Should I enable it again ? Settings > differing from defaults are copied in my first post. I don't know if the tcp window size makes any difference when the box is acting as a router. But when UDP works as expected & each additional TCP connection gets 300-600kbps the first thing I'd look at is the window size. If it was a duplex mismatch additional TCP connections would make things worse instead of each getting 3-600Kb bandwidth. > The only other change to the box is that over Christmas IPtables > (ip_conntrack and its associated modules mainly) was loaded into the kernel If all else fails, backing out recent changes usually works :) Regards, Lee From chris at ghostbusters.co.uk Sat Feb 14 09:11:01 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sat, 14 Feb 2009 15:11:01 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: Thanks very much, Lee. My head's whirring. Am I right in thinking by turning on scaling (which I just did) then the window size is automatically set ? I'll do some more reading. I'm looking at TSO too as above, mentioned by Nickola. I'll maybe risk changing it with ethtool during a quiet network moment. I've just discovered the netstat -s command which gives loads more info than anything else I've come across. Any pointers about window size or TSO from the output appreciated :-) Thanks again, Chris From ler762 at gmail.com Sat Feb 14 09:24:50 2009 From: ler762 at gmail.com (Lee) Date: Sat, 14 Feb 2009 10:24:50 -0500 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: On 2/14/09, Chris wrote: > Thanks very much, Lee. My head's whirring. Am I right in thinking by turning > on scaling (which I just did) then the window size is automatically set ? No. Scaling just allows you to have a window size larger than 64KB. These might help http://www-didc.lbl.gov/TCP-tuning/troubleshooting.html http://www-didc.lbl.gov/TCP-tuning/linux.html Regards, Lee From chris at ghostbusters.co.uk Sat Feb 14 09:26:44 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sat, 14 Feb 2009 15:26:44 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: Thanks a lot, Lee. From chris at ghostbusters.co.uk Sat Feb 14 11:42:50 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sat, 14 Feb 2009 17:42:50 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: Hi Mikael, I just realised that I didn't respond to your post. The RTTs vary massively because the router is forwarding from websites on the LAN to visitors worldwide. Is that what you meant ? Disabling TSO didn't work unfortunately. Thanks again, Chris From brandon.galbraith at gmail.com Sat Feb 14 11:45:02 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sat, 14 Feb 2009 11:45:02 -0600 Subject: One /22 Two ISP no BGP In-Reply-To: <5F3A9B55-B54C-4012-899C-4645A7BFADA5@menards.ca> References: <20090212002303.M21699@psg.com> <4995E0F1.5090203@rollernet.us> <4995EBF1.3060406@rollernet.us> <5F3A9B55-B54C-4012-899C-4645A7BFADA5@menards.ca> Message-ID: <366100670902140945o1a55b7a2jee4fa626c4cf512d@mail.gmail.com> Could Charlie do long haul microwave to someone who can do BGP? On 2/14/09, Francois Menard wrote: > The rule with ARIN is that you only need to demonstrate that you WANT > do do multihoming, not that you WILL do multihoming. > > That question would be better asked on the ARIN policy mailing list. > I'm also on that list. > > That was cleared with ARIN as part of the process to get that /22 > > I guess ARIN rightly assumes that most ISPs do want to do BGP with > their customers... > > F. > -- > Fran?ois D. M?nard > francois at menards.ca > > > > On 13-Feb-09, at 6:48 PM, Charles Regan wrote: > >> The problem we have now is that we got our /22 from arin to do >> multihoming. >> If we dump tlb, no more multihoming? No /22. Is that correct? >> >> We also have a contract with tlb. >> $$$ 1.5yrs left... >> >> >> >> >> >> >> 2009/2/13, Seth Mattinen : >>> Charles Regan wrote: >>>> Isp2 is vtl not bell >>>> >>>> 2009/2/13, Seth Mattinen : >>>>> Charles Regan wrote: >>>>>> Just got final confirmation from ISP1 that they will not do BGP >>>>>> with us. >>>>>> >>>>>> ISP1 is Telebec. >>>>>> http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=142.217.0.0&submit=Go >>>>>> >>>>>> My subnet >>>>>> http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=204.144.60.0&submit=Go >>>>>> >>>>>> What can we do now ? Any suggestions ? >>>>>> >>>>> Do you know who is upstream of ISP2? We've established that >>>>> Telebec is >>>>> only connected to Bell Canada. If ISP2 also has a connection to >>>>> Bell >>>>> then you don't gain anything with Telebec except this huge mess and >>>>> horrible hacks to work around their lack of BGP. >>>>> >>>>> ~Seth >>>>> >>>> >>> >>> >>> Also, VTL peers with Sprint and SAVVIS. Based on this information I'd >>> just drop Telebec completely. They only have one upstream. You >>> won't get >>> any redundancy with them since they're just giving you a connection >>> to >>> Bell, which VTL already gives you. Here's the view from my SAVVIS >>> router >>> with Sprint as the preferred path: >>> >>> routy-border0>show ip bgp 216.113.0.0/17 >>> BGP routing table entry for 216.113.0.0/17, version 78286019 >>> Paths: (3 available, best #1, table Default-IP-Routing-Table) >>> Not advertised to any peer >>> 1239 5769, (received & used) >>> 208.79.242.129 (metric 3) from 208.79.242.129 (208.79.242.129) >>> Origin IGP, metric 439, localpref 100, valid, internal, best >>> Community: 11170:1239 >>> 3561 5769 >>> 216.88.158.93 from 216.88.158.93 (206.24.210.102) >>> Origin IGP, localpref 90, valid, external >>> Community: 3561:11840 11170:3561 >>> 3561 5769, (received-only) >>> 216.88.158.93 from 216.88.158.93 (206.24.210.102) >>> Origin IGP, localpref 90, valid, external >>> Community: 3561:11840 >>> >>> >>> -- >>> Seth Mattinen sethm at rollernet.us >>> Roller Network LLC >>> >> >> -- >> Envoy? avec mon mobile >> > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From jtk at cymru.com Sat Feb 14 11:50:17 2009 From: jtk at cymru.com (John Kristoff) Date: Sat, 14 Feb 2009 11:50:17 -0600 Subject: Global Blackhole Service In-Reply-To: <49958A5C.2070200@plusserver.de> References: <49958A5C.2070200@plusserver.de> Message-ID: <20090214115017.5528b9b9@t61p> On Fri, 13 Feb 2009 15:57:32 +0100 Jens Ott - PlusServer AG wrote: > in the last 24 hours we received two denial of service attacks with > something like 6-8GBit volume. It did not harm us too much, but e.g. > one of our upstreams got his Amsix-Port exploded. [...] > Therefore I had the following idea: Why not taking one of my old > routers and set it up as blackhole-service. Then everyone who is > interested could set up a session to there and Hi Jens, We do something similar globally with our bogon route server project. We'd be happy to host and maintain a similar setup. John From fw at deneb.enyo.de Sat Feb 14 11:55:59 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 14 Feb 2009 18:55:59 +0100 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: (chris@ghostbusters.co.uk's message of "Sat, 14 Feb 2009 15:11:01 +0000") References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: <87fxig9a34.fsf@mid.deneb.enyo.de> > I'm looking at TSO too as above, mentioned by Nickola. I'll maybe risk > changing it with ethtool during a quiet network moment. Turning off offloading might be something to try indeed. Regarding the negotation issue, can you look at the other end of the link and check what it's saying? Looking at "netstat -s" statistics at the endpoint (not the router) could be illuminating, too. I haven't got any expertise in this area, but TCP problems can often be diagnosed by looking at tcpdump/packet captures and analyzing them using tcptrace (and the special xplot variant which can plot tcptrace output). From swmike at swm.pp.se Sat Feb 14 11:57:33 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 14 Feb 2009 18:57:33 +0100 (CET) Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <87ab8pkwk9.fsf@mid.deneb.enyo.de> Message-ID: On Sat, 14 Feb 2009, Chris wrote: > The RTTs vary massively because the router is forwarding from websites > on the LAN to visitors worldwide. Is that what you meant ? And your TCP speed when doing testing is always 300-600 kilobyte/s regardless of RTT between the boxes with which you're testing? Without TCP window scaling turned on on the boxes doing TCP with each others, you're always limited to 1/RTT*64k bytes/s of transfer speed. Changing window scaling on the linux router will of course not change the behaviour of the traffic going thru it, only TCP sessions that itself does. -- Mikael Abrahamsson email: swmike at swm.pp.se From chris at ghostbusters.co.uk Sat Feb 14 13:05:38 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sat, 14 Feb 2009 19:05:38 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: <000601c98ec7$87ce9a70$976bcf50$@org> References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <000601c98ec7$87ce9a70$976bcf50$@org> Message-ID: Thanks for all the answers. I'm currently going down the path of looking at IPtables' conntrack slowing the forwarding rate. If I can't find any more docs then I'll boot the router with a kernel without any IPtables built-in and see if that's it. As Lee said "rollback" ! That's the last change to the box. If I can rule out the logging of traffic from conntrack is slowing down the forwarding then I can look into hardware further ;-) Chris From chris at ghostbusters.co.uk Sat Feb 14 13:07:27 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sat, 14 Feb 2009 19:07:27 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <000601c98ec7$87ce9a70$976bcf50$@org> Message-ID: Thanks for all the answers. I'm currently going down the path of looking at IPtables' conntrack slowing the forwarding rate. If I can't find any more docs then I'll boot the router with a kernel without any IPtables built-in and see if that's it. As Lee said "rollback" ! That's the last change to the box. If I can rule out the logging of traffic from conntrack is slowing down the forwarding then I can look into hardware further ;-) Chris From lazlor at lotaris.org Sat Feb 14 14:43:15 2009 From: lazlor at lotaris.org (Allen Smith) Date: Sat, 14 Feb 2009 12:43:15 -0800 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <000601c98ec7$87ce9a70$976bcf50$@org> Message-ID: <49972CE3.3070700@lotaris.org> If this router is not doing some kind of proxying, tuning tcp related kernel bits will not impact "long fat pipe" or "long fat network" issues. The place that needs to be tuned for larger window sizes/scaling is the web server. http://www.psc.edu/networking/projects/tcptune/#Linux or search for "Linux TCP tuning" or "large fat pipes" Also make sure your firewall isn't "helping" you out by "cleaning up" the TCP SYN/ACK sequence and fiddling with the window scaling stuff. Also if you have load balancers, they might break this stuff as well. Good luck, -Allen Chris wrote: > Thanks for all the answers. I'm currently going down the path of looking at > IPtables' conntrack slowing the forwarding rate. > > If I can't find any more docs then I'll boot the router with a kernel > without any IPtables built-in and see if that's it. > > As Lee said "rollback" ! That's the last change to the box. If I can rule > out the logging of traffic from conntrack is slowing down > the forwarding then I can look into hardware further ;-) > > Chris > From vixie at isc.org Sat Feb 14 16:07:11 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 14 Feb 2009 22:07:11 +0000 Subject: Global Blackhole Service In-Reply-To: Your message of "Fri, 13 Feb 2009 12:04:49 CST." <4995B641.7000308@brightok.net> References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> <4995B641.7000308@brightok.net> Message-ID: <64816.1234649231@nsa.vix.com> > > where you lose me is where "the attacker must always win". > > Do you have a miraculous way to stop DDOS? Is there now a way to quickly > and efficiently track down forged packets? Is there a remedy to shutting > down the *known* botnets, not to mention the unknown ones? there are no silver bullets. anyone who says otherwise is selling something. > The attacker will always win if he has a large enough attack platform/... > > While all this is worked out, we have one solution we know works. "we had to destroy the village in order to save it." > If we null route the victim IP, the traffic stops at the null route. > Since most attackers don't care to DOS the ISP, but just to take care of > that end point, they usually don't start shifting targets to try and keep > the ISP itself out. if you null route the victim IP, the victim is off the air, so the DDoS is a success even though it mostly does not reach its target. you're proposing that we lower an attacker's costs. in a war of economics that's bad juju, and all wars are about economics. there are no silver bullets. isp's who permit random source addresses on packets leaving their networks are creating a global hazard, and since they are defending their practices on the basis of thin profit margins it's right to call this "the chemical polluter business model." as long as the rest of us continue to peer with these chemical polluters, then anyone on the internet can be the victim of a devastating DDoS at any time and at low cost. that's not a silver bullet however. if most ISP's controlled their source addresses there would still be DDoS's and then the new problem would be lack of real-time cooperation along the lines of "hi i'm in the XYZ NOC and we're tracking a DDoS against one of our customers and 14% of it is coming from your address space, here's the summary of timestamp-ip-volume and here's a pointer to your share of the netflows, can you remediate?" the answer will start out just like today's BCP38 answer, no we can't afford the staff or technology to do that, and then lawyers would worry about liability, and we'd all have to worry about monopolies, censorship, social engineering, and so on. in all of these cases the problem is the margins themselves. just as the full cost of a fast food cheeseburger is probably about $20 if you count all the costs that the corporations are shifting onto society, so it is that the full cost of a 3MBit/sec DSL line is probably $300/month if you count all the costs that ISPs shift onto digital society. the usual argument goes (and i'm just putting it out here to save time, though i'm betting several respondants will not read closely and so will just spew this out as though it's their original idea and as though i had not dismissed it many times over the decades): "we cannot build a digital economy without cost shifting since noone would pay what it really costs during the rampup". i don't dignify that with a reply, either here in effigy, or if anyone happens to trot it out again. From fw at deneb.enyo.de Sat Feb 14 16:43:58 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 14 Feb 2009 23:43:58 +0100 Subject: Global Blackhole Service In-Reply-To: <20090213121553.1aea266c@cs.columbia.edu> (Steven M. Bellovin's message of "Fri, 13 Feb 2009 12:15:53 -0500") References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> Message-ID: <87k57swsep.fsf@mid.deneb.enyo.de> * Steven M. Bellovin: > As Randy and Valdis have pointed out, if this isn't done very carefully > it's an open invitation to a new, very effective DoS technique. You > can't do this without authoritative knowledge of exactly who owns any > prefix; you also have to be able to authenticate the request to > blackhole it. Those two points are *hard*. If you want to run a public exchange point, you need to solve the same announcement validation problem. Multiple organizations appear to do it successfully, so it can't be that difficult. From patrick at ianai.net Sat Feb 14 16:45:11 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 14 Feb 2009 17:45:11 -0500 Subject: Global Blackhole Service In-Reply-To: <87k57swsep.fsf@mid.deneb.enyo.de> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> Message-ID: <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> On Feb 14, 2009, at 5:43 PM, Florian Weimer wrote: > * Steven M. Bellovin: > >> As Randy and Valdis have pointed out, if this isn't done very >> carefully >> it's an open invitation to a new, very effective DoS technique. You >> can't do this without authoritative knowledge of exactly who owns any >> prefix; you also have to be able to authenticate the request to >> blackhole it. Those two points are *hard*. > > If you want to run a public exchange point, you need to solve the same > announcement validation problem. Multiple organizations appear to do > it successfully, so it can't be that difficult. No you don't. And yes it is. To be clear, I am not saying it should or should not be done, just that your comparison is invalid. -- TTFN, patrick From mmc at internode.com.au Sat Feb 14 18:02:35 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 15 Feb 2009 10:32:35 +1030 Subject: Global Blackhole Service In-Reply-To: <87k57swsep.fsf@mid.deneb.enyo.de> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> Message-ID: <49975B9B.9020506@internode.com.au> Florian Weimer wrote: > If you want to run a public exchange point, you need to solve the same > announcement validation problem. Multiple organizations appear to do > it successfully, so it can't be that difficult. How exactly do you do "validation"? If I give you a list of ASes and prefixes, what can you do to validate that they're ones I can actually announce on behalf of someone else? I can put whatever I want in an AS-SET (etc) pretty much. How do you actually check that I have the right relationship with a customer (or customer of a customer of a customer etc)? To put it into context - the approach of stuffing other people's ASes in a path to prevent them learning it is wide spread, especially in Asia - I've seen AS-SETs with all sorts of Tier1/2 ASes even though I know that they have no transit relationship with them! MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From vixie at isc.org Sat Feb 14 18:40:27 2009 From: vixie at isc.org (Paul Vixie) Date: Sun, 15 Feb 2009 00:40:27 +0000 Subject: Global Blackhole Service In-Reply-To: <4995BF92.7020401@plusserver.de> (Jens Ott's message of "Fri\, 13 Feb 2009 19\:44\:34 +0100") References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> <4995B641.7000308@brightok.net> <4995BF92.7020401@plusserver.de> Message-ID: a minor editorial comment: Jens Ott - PlusServer AG writes: > Jack Bates schrieb: >> Paul Vixie wrote: >> >> Do you have a miraculous way to stop DDOS? Is there now a way to quickly >> and efficiently track down forged packets? Is there a remedy to shutting >> down the *known* botnets, not to mention the unknown ones? the quoted text was written by jack bates, not paul vixie. -- Paul Vixie From j.ott at plusserver.de Sun Feb 15 02:18:45 2009 From: j.ott at plusserver.de (Jens Ott - PlusServer AG) Date: Sun, 15 Feb 2009 09:18:45 +0100 Subject: Global Blackhole Service In-Reply-To: References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> <4995B641.7000308@brightok.net> <4995BF92.7020401@plusserver.de> Message-ID: <4997CFE5.5090607@plusserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Paul Vixie schrieb: > a minor editorial comment: > > Jens Ott - PlusServer AG writes: > >> Jack Bates schrieb: >>> Paul Vixie wrote: >>> >>> Do you have a miraculous way to stop DDOS? Is there now a way to quickly >>> and efficiently track down forged packets? Is there a remedy to shutting >>> down the *known* botnets, not to mention the unknown ones? > > the quoted text was written by jack bates, not paul vixie. Sorry ... must have deleted a little to much from context .... Didn'r want to move someones word into the otherones mouth ... Have a nice sunday - -- =================================================================== Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j.ott at plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstra?e 9-11 50354 H?rth Germany HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschl?ger =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmXz+UACgkQMf0yjMLKfXqC+ACfbj1PcMQknt6R3G5or5iqHD5f 5awAniuOjy+Eoxq4TLd0x7ekQqaeIX9r =oNog -----END PGP SIGNATURE----- From chris at ghostbusters.co.uk Sun Feb 15 03:24:50 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sun, 15 Feb 2009 09:24:50 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: <20090214221852.6bf1a99d.nikky@mnet.bg> References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <000601c98ec7$87ce9a70$976bcf50$@org> <20090214221852.6bf1a99d.nikky@mnet.bg> Message-ID: Thanks, Karl, Allen and Nickola. I failed-over to another router last night and briefly had full expected throughput but this morning despite dropping providers and moving between routers again for trial and error I still see _outbound_ TCP at about the same 300 - 600kbps per session. I eliminated conntract modules firstly, then iptables as a whole. I've eliminated TSO and checksumming (which caused very sticky connections) on the e1000 NIC. The failover router has a slightly older kernel and was working before Christmas so it's not most likely not kernel versions. I've also tried removing FIB_TRIE as a stab in the dark with no success. And the failover router connects using FE not GE so I've eliminated NICs and connection speeds to a front-facing switch. The only constant is the front-facing switch (it's negotiating perfectly at FD though) so all I can think of is removing that from the equation. It's definitely only _outbound_ TCP getting buffered though ! I've pushed 92Mbps on a FE link with UDP and uploaded at 16Mbps on a 16Mbps link. Any last ideas appreciated before causing headaches removing switches would be appreciated. Thanks, Chris From mathias.wolkert at gmail.com Sun Feb 15 04:10:44 2009 From: mathias.wolkert at gmail.com (Mathias Wolkert) Date: Sun, 15 Feb 2009 11:10:44 +0100 Subject: Linux Router: TCP slow, UDP fast Message-ID: I would turn off ethernet flow control. Maybe you already have. It can be really mean on tcp's own flow control if the switch has an issue of some kind (load). /Tias 15 feb 2009 kl. 10.24 skrev Chris : > Thanks, Karl, Allen and Nickola. > I failed-over to another router last night and briefly had full > expected > throughput but this morning despite dropping providers and moving > between > routers again for trial and error I still see _outbound_ TCP at > about the > same 300 - 600kbps per session. > > I eliminated conntract modules firstly, then iptables as a whole. I've > eliminated TSO and checksumming (which caused very sticky > connections) on > the e1000 NIC. > > The failover router has a slightly older kernel and was working before > Christmas so it's not most likely not kernel versions. I've also tried > removing FIB_TRIE as a stab in the dark with no success. And the > failover > router connects using FE not GE so I've eliminated NICs and connection > speeds to a front-facing switch. > > The only constant is the front-facing switch (it's negotiating > perfectly at > FD though) so all I can think of is removing that from the equation. > > It's definitely only _outbound_ TCP getting buffered though ! I've > pushed > 92Mbps on a FE link with UDP and uploaded at 16Mbps on a 16Mbps link. > > Any last ideas appreciated before causing headaches removing > switches would > be appreciated. > > Thanks, > > Chris From chris at ghostbusters.co.uk Sun Feb 15 05:18:04 2009 From: chris at ghostbusters.co.uk (Chris) Date: Sun, 15 Feb 2009 11:18:04 +0000 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: <1234693947.29925.44.camel@ernie.internal.graemef.net> References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <000601c98ec7$87ce9a70$976bcf50$@org> <20090214221852.6bf1a99d.nikky@mnet.bg> <1234693947.29925.44.camel@ernie.internal.graemef.net> Message-ID: Thanks for the suggestions everyone. I've got to the bottom of the problem now (I'm sure there will be a collective sigh of relief from the list because of the noise this thread generated :-)). I installed two brand new, low spec, 3Com switches one at the 'front' of the network and one 'behind' the routers. They are the same model, same latest firmware, same config (saved to and then copied off disk) and only their IPs were different. The front switch was the problem. As two final tests before removing it we switched off unicast/multicast broadcast control and flow control (and simultaneously on the same port on the switch behind the routers) because there were pause frames showing but not a massive amount in terms of percentage. The switch behind the routers however is serving the same bandwidth equally well ! We've put an ancient switch in place of the front switch and its been working perfectly so far. My lesson learned is too change as little as possible at once ! That said, recent network changes were spread about a month apart and this very odd issue was far easier to dismiss than believe due to its bizarre nature. Especially when providers have changes in their network conditions as testing is done. I really appreciate all the input and have learnt loads, possibly just not in the way I would have liked to :-) Doubles all round, Chris From bosch at adacore.com Sun Feb 15 06:38:23 2009 From: bosch at adacore.com (Geert Bosch) Date: Sun, 15 Feb 2009 07:38:23 -0500 Subject: Linux Router: TCP slow, UDP fast In-Reply-To: References: <2f77000a0902140425n628d53b8xbdabe8b8fb265fe4@mail.gmail.com> <000601c98ec7$87ce9a70$976bcf50$@org> <20090214221852.6bf1a99d.nikky@mnet.bg> Message-ID: On Feb 15, 2009, at 04:24, Chris wrote: > Any last ideas appreciated before causing headaches removing > switches would > be appreciated. The TCP offloading should be suspect. Any current PC hardware should be able to deal with huge amounts of traffic without any offloading. Start with turning that off, so everything will be handled by Linux directly. Even if you still would have a problem, it's easier to trouble shoot without magic black boxes (TOE) in between. -Geert From randy at psg.com Sun Feb 15 02:57:02 2009 From: randy at psg.com (Randy Bush) Date: Sun, 15 Feb 2009 17:57:02 +0900 Subject: Global Blackhole Service In-Reply-To: References: <614574061.43361234539946992.JavaMail.root@zimbra.nfsi.pt> <83578762.43451234540229508.JavaMail.root@zimbra.nfsi.pt> <4995AC56.2050501@brightok.net> <90675.1234546538@nsa.vix.com> <4995B641.7000308@brightok.net> <4995BF92.7020401@plusserver.de> Message-ID: Paul Vixie wrote: > the quoted text was written by jack bates, not paul vixie. the problem of misattributed quotations is greatly exacerbated by those who do not clearly attribute the text(s) they are quoting. randy From mike at mtcc.com Sun Feb 15 12:46:05 2009 From: mike at mtcc.com (Michael Thomas) Date: Sun, 15 Feb 2009 10:46:05 -0800 Subject: Global Blackhole Service In-Reply-To: <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> Message-ID: <499862ED.4060904@mtcc.com> [] I keep reading this subject as "Global Backhoe Service", ie, the sworn enemy of NANOG :) Mike From tme at multicasttech.com Sun Feb 15 13:14:42 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 15 Feb 2009 14:14:42 -0500 Subject: Global Blackhole Service In-Reply-To: <499862ED.4060904@mtcc.com> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> <499862ED.4060904@mtcc.com> Message-ID: On Feb 15, 2009, at 1:46 PM, Michael Thomas wrote: > [] > > I keep reading this subject as "Global Backhoe Service", ie, the sworn > enemy of NANOG :) > Why ? At the Global Backhoe Service your dues will go to our initiative to place an iPhone running Google latitude on every backhoe on the planet. The GBS will then track their positions and place a call whenever anyone raises their hoes over any cable belonging to a GBS member. Non members will get a call inviting them to subscribe... quickly. What could possibly go wrong ? Regards Marshall > Mike > From jmartinez at zero11.com Sun Feb 15 15:48:12 2009 From: jmartinez at zero11.com (John Martinez) Date: Sun, 15 Feb 2009 13:48:12 -0800 Subject: cogent issues In-Reply-To: References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> <499862ED.4060904@mtcc.com> Message-ID: <49988D9C.9000509@zero11.com> Has anyone opened a ticket with Cogent? Their packet loss is reaching ~10%. http://www.internetpulse.net From john at hypergeek.net Sun Feb 15 23:35:30 2009 From: john at hypergeek.net (John A. Kilpatrick) Date: Sun, 15 Feb 2009 21:35:30 -0800 (PST) Subject: Capture problems with Intel quad cards? Message-ID: Has anyone had problems with using current Intel quad ethernet cards for packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT and hooked it up to some Network Critical taps. There was a very strange issue with corruption of the captured packets. The *only* issue (but it's a big one) is that the source IP on some captured packets is munged. As far as I can tell that's the *only* issue with the packet captures - no other data is corrupted. Oh, and to rule out other issues: 1. Corruption seen both when using network taps and when using a port span/mirror (so it's not the taps). 2. Corruption *not* seen using the on-board broadcom nics of the test host (so it's not the box). So I'm pretty sure we narrowed it down to the card. We tried the card in an indentical host and saw the same problems. I thought it might be a driver issue - I tried both gentoo and FreeBSD (not sure how different the drivers are) just to see if it mattered at all and it didn't. Much googling didn't show this to be a known issue - just wondering if anyone else has seen it? Other recommendations welcome - the next step is, I suppose, a broadcom-based PCI-X card. (I've got some old pizza boxes I'm trying to repurpose as network probes.) Thanks, John -- John A. Kilpatrick john at hypergeek.net Email| http://www.hypergeek.net/ john-page at hypergeek.net Text pages| ICQ: 19147504 remember: no obstacles/only challenges From vegasnetman at gmail.com Mon Feb 16 10:52:29 2009 From: vegasnetman at gmail.com (Ozar) Date: Mon, 16 Feb 2009 08:52:29 -0800 Subject: 3/11 (invalid or corrupt AS path) Message-ID: <8cd002180902160852k77f417a1yd6f4843488767b7c@mail.gmail.com> I am starting to see random BGP neighbor messages from multiple neighbors on different boxes. %BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or corrupt AS path) 516 bytes I dont see much documentation on this, and we are in the process of opening a TAC case, just curious if anyone else has seen these and may be able to shed some light. Thanks From mliotta at r337.com Mon Feb 16 10:55:27 2009 From: mliotta at r337.com (Matt Liotta) Date: Mon, 16 Feb 2009 11:55:27 -0500 Subject: anyone else seeing very long AS paths? Message-ID: I am seeing them from 39625 and 47868. -Matt From sthaug at nethelp.no Mon Feb 16 10:56:14 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 16 Feb 2009 17:56:14 +0100 (CET) Subject: 3/11 (invalid or corrupt AS path) In-Reply-To: <8cd002180902160852k77f417a1yd6f4843488767b7c@mail.gmail.com> References: <8cd002180902160852k77f417a1yd6f4843488767b7c@mail.gmail.com> Message-ID: <20090216.175614.74724593.sthaug@nethelp.no> > I am starting to see random BGP neighbor messages from multiple neighbors on > different boxes. > > %BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or corrupt > AS path) 516 bytes Maybe because of this? 94.125.216.0/21 *[BGP/170] 00:31:49, MED 22367, localpref 100 AS path: 3356 29113 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 I Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jponter at navisite.com Mon Feb 16 10:59:55 2009 From: jponter at navisite.com (Ponter, James) Date: Mon, 16 Feb 2009 16:59:55 +0000 Subject: anyone else seeing very long AS paths? In-Reply-To: Message-ID: I'm seeing it too Feb 16 16:44:36.065 GMT: BGP: x.x.x.x Bad attributes Feb 16 16:45:43.389 GMT: %BGP-6-ASPATH: Long AS path 6461 1299 29113 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 received from x.x.x.x: Has more than 255 AS Feb 16 16:45:43.389 GMT: %BGP-5-ADJCHANGE: neighbor x.x.x.x Down BGP Notification sent Feb 16 16:45:43.389 GMT: %BGP-3-NOTIFICATION: sent to neighbor x.x.x.x 3/11 (invalid or corrupt AS path) 516 bytes 50020200 02FF193D 051371B9 BAFCBAFC BA Feb 16 16:45:43.389 GMT: BGP: x.x.x.x Bad attributes On 16/02/2009 16:55, "Matt Liotta" wrote: > I am seeing them from 39625 and 47868. > > -Matt > ____________________________________ James Ponter UK Operations Manager NaviSite jponter at navisite.com +44 (0) 207 510 2504 (Office) +44 (0) 798 938 1039 (Cell) Reduce the Cost of IT with Managed Hosting and Application Services from NaviSite. Visit www.NaviSite.com today. This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. From ranmails at gmail.com Mon Feb 16 10:52:35 2009 From: ranmails at gmail.com (Ran Liebermann) Date: Mon, 16 Feb 2009 18:52:35 +0200 Subject: Littering the global BGP - AS 47868 Message-ID: <8c19328e0902160852k58055c34u46729db029523353@mail.gmail.com> Hi all, We're seeing some garbage being thrown into the global BGP table by AS 47868. %BGP-6-ASPATH: Long AS path 3549 3257 29113 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 received from 208.49.128.49: Has more than 255 AS This is hitting some routers with older software versions. Is there someone here from AS 29113 (Sloane Park Property Trust in the Czech Repulic) that can filter this from the source? Cheers, -- Ran Liebermann VP Engineering, PurePeak ranl at purepeak.com http://purepeak.com From john at vanoppen.com Mon Feb 16 11:01:24 2009 From: john at vanoppen.com (John van Oppen) Date: Mon, 16 Feb 2009 09:01:24 -0800 Subject: anyone else seeing very long AS paths? References: Message-ID: I just see it from 47868 and I just filtered it so it would stop blowing up BGP sessions to customers. In our case we are only seeing the prefix from level3 which prompted me to create a route map to block it: ip as-path access-list 500 permit _47868_ route-map as3356-in deny 1 match as-path 500 John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Matt Liotta [mailto:mliotta at r337.com] Sent: Monday, February 16, 2009 8:55 AM To: nanog at nanog.org Subject: anyone else seeing very long AS paths? I am seeing them from 39625 and 47868. -Matt From davei at otd.com Mon Feb 16 11:03:17 2009 From: davei at otd.com (Dave Israel) Date: Mon, 16 Feb 2009 12:03:17 -0500 Subject: 3/11 (invalid or corrupt AS path) In-Reply-To: <8cd002180902160852k77f417a1yd6f4843488767b7c@mail.gmail.com> References: <8cd002180902160852k77f417a1yd6f4843488767b7c@mail.gmail.com> Message-ID: <49999C55.3010606@otd.com> We're seeing them from AS 48438, coming across to us as an Optional Transitive Attribute which our force-10s are not parsing (but cheerfully passing along to our clients, who are then flapping their peers because of it.) Sample route; 91.210.248.0/23 Ozar wrote: > I am starting to see random BGP neighbor messages from multiple neighbors on > different boxes. > > %BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or corrupt > AS path) 516 bytes > > I dont see much documentation on this, and we are in the process of opening > a TAC case, just curious if anyone else has seen these and may be able to > shed some light. > > Thanks > From andy at nosignal.org Mon Feb 16 11:10:22 2009 From: andy at nosignal.org (Andy Davidson) Date: Mon, 16 Feb 2009 17:10:22 +0000 Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: Hi, Yep, we see them too. Nasty because there are lots of networks flapping as the long as-paths are tickling old bug CSCdr54230, so even networks not affected by the bug will be getting lots of extra updates. Anyone with contacts at 47868 ? Any upstreams onlist that want to bin them ? Andy From nrauhauser at gmail.com Mon Feb 16 11:16:22 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Mon, 16 Feb 2009 11:16:22 -0600 Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: <9515c62d0902160916y293c1204n547c4087eb7f1408@mail.gmail.com> Sprint has already expunged 47868 from their offerings but Paetec nee McLeod is still bouncing sessions to us. It is Monday, isn't it? On Mon, Feb 16, 2009 at 11:10 AM, Andy Davidson wrote: > > Hi, > > Yep, we see them too. Nasty because there are lots of networks flapping as > the long as-paths are tickling old bug CSCdr54230, so even networks not > affected by the bug will be getting lots of extra updates. > > Anyone with contacts at 47868 ? Any upstreams onlist that want to bin them > ? > > Andy > > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From john at vanoppen.com Mon Feb 16 11:24:53 2009 From: john at vanoppen.com (John van Oppen) Date: Mon, 16 Feb 2009 09:24:53 -0800 Subject: anyone else seeing very long AS paths? References: Message-ID: Yep we saw the same, every customer with old IOS had their sessions die to us at the same time... That always makes for an interesting time when watching the NMS system... We are seeing a much more sane path now: agg2-sea-A>show ip bgp 94.125.216.0/21 BGP routing table entry for 94.125.216.0/21, version 25944571 Paths: (1 available, best #1) Multipath: eBGP Advertised to update-groups: 2 3 5 6 7 8 9 3561 3356 29113 47868 208.76.153.96 (metric 5102) from 208.76.153.96 (208.76.153.96) Origin IGP, metric 0, localpref 50, valid, internal, best Community: 11404:1000 11404:1040 agg2-sea-A> John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Andy Davidson [mailto:andy at nosignal.org] Sent: Monday, February 16, 2009 9:10 AM To: John van Oppen Cc: Matt Liotta; nanog at nanog.org Subject: Re: anyone else seeing very long AS paths? Hi, Yep, we see them too. Nasty because there are lots of networks flapping as the long as-paths are tickling old bug CSCdr54230, so even networks not affected by the bug will be getting lots of extra updates. Anyone with contacts at 47868 ? Any upstreams onlist that want to bin them ? Andy From jake at nobistech.net Mon Feb 16 11:35:09 2009 From: jake at nobistech.net (Jake Mertel) Date: Mon, 16 Feb 2009 11:35:09 -0600 Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: <18DCD1A1EB78DF41B564964698425DE201207D3DC2@srv372.exchange.nobistech.net> Looks good here too telnet at edge1.chi.ubiquityservers.com(config)#show ip bgp 94.125.216.0/21 Number of BGP Routes matching display condition : 2 Status codes: s suppressed, d damped, h history, * valid, > best, i internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 94.125.216.0/21 72.37.148.177 3 100 0 25973 29113 47868 i * 94.125.216.0/21 65.47.180.113 3 100 0 2828 3257 29113 47868 i Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -----Original Message----- From: John van Oppen [mailto:john at vanoppen.com] Sent: Monday, February 16, 2009 11:25 AM To: Andy Davidson Cc: nanog at nanog.org Subject: RE: anyone else seeing very long AS paths? Yep we saw the same, every customer with old IOS had their sessions die to us at the same time... That always makes for an interesting time when watching the NMS system... We are seeing a much more sane path now: agg2-sea-A>show ip bgp 94.125.216.0/21 BGP routing table entry for 94.125.216.0/21, version 25944571 Paths: (1 available, best #1) Multipath: eBGP Advertised to update-groups: 2 3 5 6 7 8 9 3561 3356 29113 47868 208.76.153.96 (metric 5102) from 208.76.153.96 (208.76.153.96) Origin IGP, metric 0, localpref 50, valid, internal, best Community: 11404:1000 11404:1040 agg2-sea-A> John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Andy Davidson [mailto:andy at nosignal.org] Sent: Monday, February 16, 2009 9:10 AM To: John van Oppen Cc: Matt Liotta; nanog at nanog.org Subject: Re: anyone else seeing very long AS paths? Hi, Yep, we see them too. Nasty because there are lots of networks flapping as the long as-paths are tickling old bug CSCdr54230, so even networks not affected by the bug will be getting lots of extra updates. Anyone with contacts at 47868 ? Any upstreams onlist that want to bin them ? Andy From jlewis at lewis.org Mon Feb 16 11:43:10 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 16 Feb 2009 12:43:10 -0500 (EST) Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: On Mon, 16 Feb 2009, John van Oppen wrote: > Yep we saw the same, every customer with old IOS had their sessions die > to us at the same time... That always makes for an interesting time > when watching the NMS system... Is there a reason you don't use something like "bgp maxas-limit NN" on your transit sessions? We saw this too, but it stopped at our transit routers. There was actually another a few days ago. Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 39412 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625... Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868... ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From michal at krsek.cz Mon Feb 16 11:46:14 2009 From: michal at krsek.cz (Michal Krsek) Date: Mon, 16 Feb 2009 18:46:14 +0100 Subject: cogent issues In-Reply-To: <49988D9C.9000509@zero11.com> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> <499862ED.4060904@mtcc.com> <49988D9C.9000509@zero11.com> Message-ID: <4999A666.9020906@krsek.cz> We didn't but see significant routing problem here in Prague/EU. Michal Krsek - AS41711 John Martinez napsal(a): > Has anyone opened a ticket with Cogent? > Their packet loss is reaching ~10%. > > http://www.internetpulse.net > From tomas at caslavsky.cz Mon Feb 16 11:49:01 2009 From: tomas at caslavsky.cz (Tomas Caslavsky) Date: Mon, 16 Feb 2009 18:49:01 +0100 Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: <4999A70D.3080907@caslavsky.cz> Hello, I am in touch with Sloane ( as29113 ) to fix this issue Tomas Caslavsky Jon Lewis wrote: > On Mon, 16 Feb 2009, John van Oppen wrote: > >> Yep we saw the same, every customer with old IOS had their sessions die >> to us at the same time... That always makes for an interesting time >> when watching the NMS system... > > Is there a reason you don't use something like "bgp maxas-limit NN" on > your transit sessions? > > We saw this too, but it stopped at our transit routers. There was > actually another a few days ago. > > Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 > 39412 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625... > > Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 47868 47868 47868 47868 47868 47868... > > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From leland at taranta.discpro.org Mon Feb 16 11:53:00 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Mon, 16 Feb 2009 17:53:00 +0000 (GMT) Subject: anyone else seeing very long AS paths? In-Reply-To: Message-ID: bgp maxas-limit has a default value of 75 if you don't include it explicitly in the config so in this case it wouldn't have made much of a difference. L. On Mon, 16 Feb 2009, Jon Lewis wrote: > On Mon, 16 Feb 2009, John van Oppen wrote: > > > Yep we saw the same, every customer with old IOS had their sessions die > > to us at the same time... That always makes for an interesting time > > when watching the NMS system... > > Is there a reason you don't use something like "bgp maxas-limit NN" on > your transit sessions? > > We saw this too, but it stopped at our transit routers. There was > actually another a few days ago. > > Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 39412 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625... > > Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 47868 47868 47868... > > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From john at vanoppen.com Mon Feb 16 11:57:18 2009 From: john at vanoppen.com (John van Oppen) Date: Mon, 16 Feb 2009 09:57:18 -0800 Subject: anyone else seeing very long AS paths? References: Message-ID: I am also a bit leery of setting it much lower than the defaults due to the possibility of filtering something my customers will care about... I am not sure what the best strategy is but what really bit a couple of our customers was their old IOSes that tore the sessions down. I note that most of our customers speaking BGP had no issue just three out of about 25. What do people think is a reasonable maximum as-path length to enforce at ones edge? John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Leland E. Vandervort [mailto:leland at taranta.discpro.org] Sent: Monday, February 16, 2009 9:53 AM To: Jon Lewis Cc: John van Oppen; nanog at nanog.org Subject: RE: anyone else seeing very long AS paths? bgp maxas-limit has a default value of 75 if you don't include it explicitly in the config so in this case it wouldn't have made much of a difference. L. On Mon, 16 Feb 2009, Jon Lewis wrote: > On Mon, 16 Feb 2009, John van Oppen wrote: > > > Yep we saw the same, every customer with old IOS had their sessions die > > to us at the same time... That always makes for an interesting time > > when watching the NMS system... > > Is there a reason you don't use something like "bgp maxas-limit NN" on > your transit sessions? > > We saw this too, but it stopped at our transit routers. There was > actually another a few days ago. > > Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 39412 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625... > > Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 47868 47868 47868... > > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From jlewis at lewis.org Mon Feb 16 12:00:39 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 16 Feb 2009 13:00:39 -0500 (EST) Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: Why do you say that? I counted 78 instances of 47868 in this long as-path, and our maxas-limit settings did trigger and reject these. On Mon, 16 Feb 2009, Leland E. Vandervort wrote: > > bgp maxas-limit has a default value of 75 if you don't include it > explicitly in the config so in this case it wouldn't have made much of a > difference. > > L. > > > On Mon, 16 Feb 2009, Jon Lewis wrote: > >> On Mon, 16 Feb 2009, John van Oppen wrote: >> >>> Yep we saw the same, every customer with old IOS had their sessions die >>> to us at the same time... That always makes for an interesting time >>> when watching the NMS system... >> >> Is there a reason you don't use something like "bgp maxas-limit NN" on >> your transit sessions? >> >> We saw this too, but it stopped at our transit routers. There was >> actually another a few days ago. >> >> Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 39412 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625... >> >> Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 47868 >> 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 >> 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 >> 47868 47868 47868 47868... >> >> >> ---------------------------------------------------------------------- >> Jon Lewis | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jlewis at lewis.org Mon Feb 16 12:02:23 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 16 Feb 2009 13:02:23 -0500 (EST) Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: On Mon, 16 Feb 2009, John van Oppen wrote: > I am also a bit leery of setting it much lower than the defaults due to > the possibility of filtering something my customers will care about... > I am not sure what the best strategy is but what really bit a couple of > our customers was their old IOSes that tore the sessions down. I note > that most of our customers speaking BGP had no issue just three out of > about 25. > > > What do people think is a reasonable maximum as-path length to enforce > at ones edge? I've been using 75 for years and have never seen it trigger on 'legitimate' routes. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jared at puck.nether.net Mon Feb 16 12:03:09 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 16 Feb 2009 13:03:09 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: <79740517-2B66-4F8A-A0D3-92C29743511C@puck.nether.net> On Feb 16, 2009, at 12:57 PM, John van Oppen wrote: > I am also a bit leery of setting it much lower than the defaults due > to > the possibility of filtering something my customers will care about... > I am not sure what the best strategy is but what really bit a couple > of > our customers was their old IOSes that tore the sessions down. I > note > that most of our customers speaking BGP had no issue just three out of > about 25. > > > What do people think is a reasonable maximum as-path length to enforce > at ones edge? > Would you want your upstream to set an arbitrary limit on these announcements for you, or should the few wayward souls finally upgrade their code? If your upstream were to set a limit (64, 96, 128, 192, 255) what would you expect that to be and how should it be disclosed? my opinion is that if you're going to operate in an active environment (eg: bgp) where messages are constantly being sent, you need to be an active participant in managing your risk. If you're not, perhaps you don't really need BGP since you can't afford the 'operational costs' of managing that asset. - Jared From leland at taranta.discpro.org Mon Feb 16 12:03:57 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Mon, 16 Feb 2009 18:03:57 +0000 (GMT) Subject: anyone else seeing very long AS paths? In-Reply-To: Message-ID: http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfbgp1.html#wp1254976 Defaults The default value in Cisco IOS software for the number argument is 75. On Mon, 16 Feb 2009, Jon Lewis wrote: > Why do you say that? I counted 78 instances of 47868 in this long > as-path, and our maxas-limit settings did trigger and reject these. > > On Mon, 16 Feb 2009, Leland E. Vandervort wrote: > > > > > bgp maxas-limit has a default value of 75 if you don't include it > > explicitly in the config so in this case it wouldn't have made much of a > > difference. > > > > L. > > > > > > On Mon, 16 Feb 2009, Jon Lewis wrote: > > > >> On Mon, 16 Feb 2009, John van Oppen wrote: > >> > >>> Yep we saw the same, every customer with old IOS had their sessions die > >>> to us at the same time... That always makes for an interesting time > >>> when watching the NMS system... > >> > >> Is there a reason you don't use something like "bgp maxas-limit NN" on > >> your transit sessions? > >> > >> We saw this too, but it stopped at our transit routers. There was > >> actually another a few days ago. > >> > >> Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 39412 > >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > >> 39625 39625 39625 39625... > >> > >> Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 47868 > >> 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > >> 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > >> 47868 47868 47868 47868... > >> > >> > >> ---------------------------------------------------------------------- > >> Jon Lewis | I route > >> Senior Network Engineer | therefore you are > >> Atlantic Net | > >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > >> > > > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From nuno.vieira at nfsi.pt Mon Feb 16 12:03:58 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Mon, 16 Feb 2009 18:03:58 +0000 (WET) Subject: anyone else seeing very long AS paths? In-Reply-To: Message-ID: <804035053.50831234807438615.JavaMail.root@zimbra.nfsi.pt> Hi, Anyone onlist knows the similar command (bgp maxas-limit NN) on Foundry XMR platform ? regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Jon Lewis" wrote: > On Mon, 16 Feb 2009, John van Oppen wrote: > > > Yep we saw the same, every customer with old IOS had their sessions > die > > to us at the same time... That always makes for an interesting > time > > when watching the NMS system... > > Is there a reason you don't use something like "bgp maxas-limit NN" on > > your transit sessions? > > We saw this too, but it stopped at our transit routers. There was > actually another a few days ago. > > Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 > 39412 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 > 39625 39625 39625 39625... > > Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 > 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 > 47868 47868 47868 47868... > > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From babydr at baby-dragons.com Mon Feb 16 12:39:18 2009 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Mon, 16 Feb 2009 09:39:18 -0900 (AKST) Subject: Capture problems with Intel quad cards? In-Reply-To: References: Message-ID: Hello John , On Sun, 15 Feb 2009, John A. Kilpatrick wrote: > Has anyone had problems with using current Intel quad ethernet cards for > packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT and > hooked it up to some Network Critical taps. There was a very strange issue > with corruption of the captured packets. The *only* issue (but it's a big > one) is that the source IP on some captured packets is munged. As far as I > can tell that's the *only* issue with the packet captures - no other data is > corrupted. > > Oh, and to rule out other issues: > > 1. Corruption seen both when using network taps and when using a port > span/mirror (so it's not the taps). > 2. Corruption *not* seen using the on-board broadcom nics of the test > host (so it's not the box). > > So I'm pretty sure we narrowed it down to the card. We tried the card in > an indentical host and saw the same problems. > > I thought it might be a driver issue - I tried both gentoo and FreeBSD (not > sure how different the drivers are) just to see if it mattered at all and it > didn't. Much googling didn't show this to be a known issue - just wondering > if anyone else has seen it? Other recommendations welcome - the next step > is, I suppose, a broadcom-based PCI-X card. (I've got some old pizza boxes > I'm trying to repurpose as network probes.) > > Thanks, > John Does this device provide 4 unique mac-addresses ? Reason for the question is some old(I mean old) multiport cards presented a single mac-address because the were driven by a single 'Switch chip' . Just a thought . I've been looking a the Intel site gandering over the overview & have not seen anything to relieve my concern . But one Hopes they have learned not to create themselves such a problem . Hth , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ From nrauhauser at gmail.com Mon Feb 16 13:13:51 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Mon, 16 Feb 2009 13:13:51 -0600 Subject: cogent issues In-Reply-To: <4999A666.9020906@krsek.cz> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> <499862ED.4060904@mtcc.com> <49988D9C.9000509@zero11.com> <4999A666.9020906@krsek.cz> Message-ID: <9515c62d0902161113m2c7b5a8i91339312db780f36@mail.gmail.com> Loss between AS22663 and various European sites was running 50% for us around 10:00 GMT. We dropped Paetec peering, which got Cogent out from between us and the sites in question, then things were fine via Sprint. Our usage at the time was maybe 5 mbits on a DS3. On Mon, Feb 16, 2009 at 11:46 AM, Michal Krsek wrote: > We didn't but see significant routing problem here in Prague/EU. > > Michal Krsek - AS41711 > > John Martinez napsal(a): > > Has anyone opened a ticket with Cogent? >> Their packet loss is reaching ~10%. >> >> http://www.internetpulse.net >> >> > > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From ranmails at gmail.com Mon Feb 16 13:38:12 2009 From: ranmails at gmail.com (Ran Liebermann) Date: Mon, 16 Feb 2009 21:38:12 +0200 Subject: cogent issues In-Reply-To: <49988D9C.9000509@zero11.com> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> <499862ED.4060904@mtcc.com> <49988D9C.9000509@zero11.com> Message-ID: <8c19328e0902161138j5acac7f1g4d29118a6f4a13fd@mail.gmail.com> On Sun, Feb 15, 2009 at 11:48 PM, John Martinez wrote: > Has anyone opened a ticket with Cogent? > Their packet loss is reaching ~10%. We see strange losses to/from their network. Losses to some hosts while other hosts on the same network route do not experience losses. Seems like problems in some of their paths that utilize equal-cost load sharing. -- Ran Liebermann VP Engineering, PurePeak ranl at purepeak.com http://purepeak.com From tme at multicasttech.com Mon Feb 16 14:06:47 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 16 Feb 2009 15:06:47 -0500 Subject: cogent issues In-Reply-To: <4999A666.9020906@krsek.cz> References: <10790.1234542537@turing-police.cc.vt.edu> <422106592.43981234543301085.JavaMail.root@zimbra.nfsi.pt> <20090213121553.1aea266c@cs.columbia.edu> <87k57swsep.fsf@mid.deneb.enyo.de> <623A455C-6BA6-4C36-A184-8621FF129E6D@ianai.net> <499862ED.4060904@mtcc.com> <49988D9C.9000509@zero11.com> <4999A666.9020906@krsek.cz> Message-ID: <02179A0D-BA73-46B5-9DA5-F180CFA638C7@multicasttech.com> I had big problems ~ 11:30 AM EST in Vienna, Virginia, but they are fixed now. Marshall On Feb 16, 2009, at 12:46 PM, Michal Krsek wrote: > We didn't but see significant routing problem here in Prague/EU. > > Michal Krsek - AS41711 > > John Martinez napsal(a): >> Has anyone opened a ticket with Cogent? >> Their packet loss is reaching ~10%. >> >> http://www.internetpulse.net >> > From Jay.Murphy at state.nm.us Mon Feb 16 15:47:39 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 16 Feb 2009 14:47:39 -0700 Subject: Capture problems with Intel quad cards? In-Reply-To: References: Message-ID: Yea cards are default for separate physicals MACs, since they are supported by individual net chips. The only time one would see a "logical" Mac, is when the ports are trunked, and this is driven by software. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Mr. James W. Laferriere [mailto:babydr at baby-dragons.com] Sent: Monday, February 16, 2009 11:39 AM To: John A. Kilpatrick Cc: nanog at nanog.org Subject: Re: Capture problems with Intel quad cards? Hello John , On Sun, 15 Feb 2009, John A. Kilpatrick wrote: > Has anyone had problems with using current Intel quad ethernet cards for > packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT and > hooked it up to some Network Critical taps. There was a very strange issue > with corruption of the captured packets. The *only* issue (but it's a big > one) is that the source IP on some captured packets is munged. As far as I > can tell that's the *only* issue with the packet captures - no other data is > corrupted. > > Oh, and to rule out other issues: > > 1. Corruption seen both when using network taps and when using a port > span/mirror (so it's not the taps). > 2. Corruption *not* seen using the on-board broadcom nics of the test > host (so it's not the box). > > So I'm pretty sure we narrowed it down to the card. We tried the card in > an indentical host and saw the same problems. > > I thought it might be a driver issue - I tried both gentoo and FreeBSD (not > sure how different the drivers are) just to see if it mattered at all and it > didn't. Much googling didn't show this to be a known issue - just wondering > if anyone else has seen it? Other recommendations welcome - the next step > is, I suppose, a broadcom-based PCI-X card. (I've got some old pizza boxes > I'm trying to repurpose as network probes.) > > Thanks, > John Does this device provide 4 unique mac-addresses ? Reason for the question is some old(I mean old) multiport cards presented a single mac-address because the were driven by a single 'Switch chip' . Just a thought . I've been looking a the Intel site gandering over the overview & have not seen anything to relieve my concern . But one Hopes they have learned not to create themselves such a problem . Hth , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From Jay.Murphy at state.nm.us Mon Feb 16 16:17:07 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 16 Feb 2009 15:17:07 -0700 Subject: Capture problems with Intel quad cards? In-Reply-To: References: Message-ID: One more note.... it is a bridging chip, not switching, that is resident on the board that is the communicator to the other NIC chipsets. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Mr. James W. Laferriere [mailto:babydr at baby-dragons.com] Sent: Monday, February 16, 2009 11:39 AM To: John A. Kilpatrick Cc: nanog at nanog.org Subject: Re: Capture problems with Intel quad cards? Hello John , On Sun, 15 Feb 2009, John A. Kilpatrick wrote: > Has anyone had problems with using current Intel quad ethernet cards for > packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT and > hooked it up to some Network Critical taps. There was a very strange issue > with corruption of the captured packets. The *only* issue (but it's a big > one) is that the source IP on some captured packets is munged. As far as I > can tell that's the *only* issue with the packet captures - no other data is > corrupted. > > Oh, and to rule out other issues: > > 1. Corruption seen both when using network taps and when using a port > span/mirror (so it's not the taps). > 2. Corruption *not* seen using the on-board broadcom nics of the test > host (so it's not the box). > > So I'm pretty sure we narrowed it down to the card. We tried the card in > an indentical host and saw the same problems. > > I thought it might be a driver issue - I tried both gentoo and FreeBSD (not > sure how different the drivers are) just to see if it mattered at all and it > didn't. Much googling didn't show this to be a known issue - just wondering > if anyone else has seen it? Other recommendations welcome - the next step > is, I suppose, a broadcom-based PCI-X card. (I've got some old pizza boxes > I'm trying to repurpose as network probes.) > > Thanks, > John Does this device provide 4 unique mac-addresses ? Reason for the question is some old(I mean old) multiport cards presented a single mac-address because the were driven by a single 'Switch chip' . Just a thought . I've been looking a the Intel site gandering over the overview & have not seen anything to relieve my concern . But one Hopes they have learned not to create themselves such a problem . Hth , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From bogstad at pobox.com Mon Feb 16 17:01:02 2009 From: bogstad at pobox.com (Bill Bogstad) Date: Mon, 16 Feb 2009 18:01:02 -0500 Subject: Capture problems with Intel quad cards? In-Reply-To: References: Message-ID: <2d6a9f6f0902161501r4f851ce4t3b58385adf539923@mail.gmail.com> On Mon, Feb 16, 2009 at 12:35 AM, John A. Kilpatrick wrote: > > Has anyone had problems with using current Intel quad ethernet cards for > packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT > and hooked it up to some Network Critical taps. There was a very strange > issue with corruption of the captured packets. The *only* issue (but it's a > big one) is that the source IP on some captured packets is munged. As far > as I can tell that's the *only* issue with the packet captures - no other > data is corrupted. Dumb question... It sounds like you've only used the card in packet capture mode (i.e. promiscuous mode). Have you tried testing the card just for normal host-to-host network flows? Maybe you have a bad card? If you still see problems on host-host flows, it's more likely to be a bad card rather then a bad driver. (Given that a driver that can't handle host-host flows is going to be obvious pretty quickly.) Good Luck, Bill Bogstad From swulf at phonoscope.com Mon Feb 16 17:09:41 2009 From: swulf at phonoscope.com (Swen Wulf) Date: Mon, 16 Feb 2009 17:09:41 -0600 Subject: Looking for GBLX contact + check your ACL for 66.249.96.0/20 please :) Message-ID: Hello, We have been assigned 66.249.96.0/20 in April of 2008. Little did we know that this network was used by a spammer in 2004 (Lightwave Transit) and with this is deeply embedded in a lot of ACL's that seem to be unmaintained. If a GLBX engineer could take a look, it seems traffic originating from 66.249.96.0/20 can't reach some website when passing thru GBLX. Other prefixes we announce from our AS (22442) such as 66.60.224.0/20 don't have this problem. Customer with source of 66.249.106.112/27 can't get to the website of www.ups.com (72.246.89.243 (akamai)). core1#traceroute 72.246.89.243 source 66.249.106.113 Type escape sequence to abort. Tracing the route to a72-246-89-243.deploy.akamaitechnologies.com (72.246.89.243) 1 ge-1-11.r03.hstntx01.us.bb.gin.ntt.net (128.241.5.1) 0 msec 0 msec 0 msec 2 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) [AS 2914] 0 msec 0 msec 0 msec 3 p64-1-3-0.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) [AS 2914] 8 msec 8 msec 8 msec 4 po-2.r03.dllstx09.us.bb.gin.ntt.net (129.250.4.38) [AS 2914] 4 msec 4 msec 8 msec 5 xe-0.globalcrossing.dllstx09.us.bb.gin.ntt.net (129.250.8.190) [AS 2914] 4 msec 8 msec 4 msec 6 te7-1-10G.ar2.DAL2.gblx.net (67.16.129.117) [AS 3549] 8 msec 12 msec 4 msec 7 * * * 8 * * And from a different source IP from the same router core1#traceroute 72.246.89.243 source 66.60.233.1 Type escape sequence to abort. Tracing the route to a72-246-89-243.deploy.akamaitechnologies.com (72.246.89.243) 1 ge-1-11.r03.hstntx01.us.bb.gin.ntt.net (128.241.5.1) 4 msec 0 msec 0 msec 2 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) [AS 2914] 0 msec 4 msec 0 msec 3 p64-1-3-0.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) [AS 2914] 8 msec 8 msec 8 msec 4 po-2.r03.dllstx09.us.bb.gin.ntt.net (129.250.4.38) [AS 2914] 4 msec 8 msec * 5 xe-0.globalcrossing.dllstx09.us.bb.gin.ntt.net (129.250.8.190) [AS 2914] 4 msec 8 msec 8 msec 6 te7-1-10G.ar2.DAL2.gblx.net (67.16.129.117) [AS 3549] 4 msec 8 msec 8 msec 7 PCCW-Global-Chicago-Dallas.te3-2.ar2.DAL2.gblx.net (64.211.211.186) [AS 3549] 200 msec 24 msec 212 msec 8 * * * 9 I tried an email to their puck noc email address, but without being a customer I can't open a ticket. Thanks, Swen Wulf Network Security Manager Email: swulf at phonoscope.com Phone: 832-615-7743 (direct) Fax: 832-213-0110 --- * Network Operations Center (NOC): 713-272-4600 (24x7x365) --- Phonoscope - moving at the speed of light From justin at justinshore.com Mon Feb 16 17:09:49 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 16 Feb 2009 17:09:49 -0600 Subject: Global Blackhole Service In-Reply-To: <49958A5C.2070200@plusserver.de> References: <49958A5C.2070200@plusserver.de> Message-ID: <4999F23D.3050109@justinshore.com> Jens Ott - PlusServer AG wrote: > Therefore I had the following idea: Why not taking one of my old routers and > set it up as blackhole-service. Then everyone who is interested could set up a > session to there and I do something similar on our network with a RTBH trigger router. I peer with it from my edges that are capable of handling that many BGP routes. I feed into it hosts that scan our networks looking for running SSH daemons and open proxies on specific default ports. With uRPF on all our edges it will drop traffic whether the target IP is the source or the destination. Works slick. The Cisco Press "Router Security Strategies" book has good examples. A trustworthy source for BGP blacklists of sorts would be an excellent thing IMHO. I'd love to be able to reliably drop traffic from malicious hosts before they scan our network and end up in my netflow logs. Trust would be a big issue though. Justin From maillist at webjogger.net Mon Feb 16 18:26:23 2009 From: maillist at webjogger.net (Adam Greene) Date: Mon, 16 Feb 2009 19:26:23 -0500 Subject: anyone else seeing very long AS paths? References: <804035053.50831234807438615.JavaMail.root@zimbra.nfsi.pt> Message-ID: <26C8736A04564E51BEB3B1BFBFA72BC0@GINKGO> Anyone have an estimate as to when these long announcements began? Seems like the first reports appeared just before noon, UTC-05. We noticed a significant dip in Internet traffic to AS11579 for a few minutes last night (19:00 UTC-05) which we've been trying to hunt down the cause of. At first glance, the two events seem unrelated. Anyone else see anything similar? > ----- "Jon Lewis" wrote: > >> On Mon, 16 Feb 2009, John van Oppen wrote: >> >> > Yep we saw the same, every customer with old IOS had their sessions >> die >> > to us at the same time... That always makes for an interesting >> time >> > when watching the NMS system.. >> >> Is there a reason you don't use something like "bgp maxas-limit NN" on >> >> your transit sessions? >> >> We saw this too, but it stopped at our transit routers. There was >> actually another a few days ago. >> >> Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 >> 39412 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 >> 39625 39625 39625 39625... >> >> Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 >> 47868 >> 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 >> 47868 >> 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 >> 47868 >> 47868 47868 47868 47868... >> >> >> ---------------------------------------------------------------------- >> Jon Lewis | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > From mulitskiy at acedsl.com Mon Feb 16 22:51:20 2009 From: mulitskiy at acedsl.com (Michael Ulitskiy) Date: Mon, 16 Feb 2009 23:51:20 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <26C8736A04564E51BEB3B1BFBFA72BC0@GINKGO> References: <804035053.50831234807438615.JavaMail.root@zimbra.nfsi.pt> <26C8736A04564E51BEB3B1BFBFA72BC0@GINKGO> Message-ID: <200902162351.20286.mulitskiy@acedsl.com> It hit my routers at 11:26:40, EST. Michael On Monday 16 February 2009 07:26:23 pm Adam Greene wrote: > Anyone have an estimate as to when these long announcements began? Seems > like the first reports appeared just before noon, UTC-05. > > We noticed a significant dip in Internet traffic to AS11579 for a few > minutes last night (19:00 UTC-05) which we've been trying to hunt down the > cause of. At first glance, the two events seem unrelated. Anyone else see > anything similar? From adimino at shadowserver.org Mon Feb 16 22:53:21 2009 From: adimino at shadowserver.org (Andre' M. DiMino) Date: Mon, 16 Feb 2009 23:53:21 -0500 Subject: Shadowserver - ASN & Netblock Alerting & Reporting Service Message-ID: <499A42C1.2070306@shadowserver.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Shadowserver Foundation is pleased to announce the formal rollout of our ASN/netblock alerting and reporting service. This reporting service is provided free-of-charge and is designed for ISPs, enterprises, hosting providers, and other organizations that directly own or control network space. It allows them to receive customized reports detailing detected malicious activity to assist in their detection and mitigation program. Shadowserver has been providing this service to many subscribers for over two years, and currently generate over 4000 reports nightly. Since the response to this service has been extremely positive from our consumer base, we now wish to make it more widely and openly available. The reporting service monitors and alerts the following activity: Detected Botnet Command and Control servers Infected systems (drones) DDoS attacks (source and victim) Scans Clickfraud Compromised hosts Proxies Spam relays Malicious software droppers and other related information. The Shadowserver Foundation filters data received from its worldwide sensor and monitoring networks and employs an analysis engine to classify the attacks. It then sorts this data according to ASN, netblock, and even Geolocation. Detected malicious activity on a subscriber's network is flagged accordingly and is included in daily summarization reports detailing the previous 24 hours of activity. Reports are only sent upon detection of malicious activity. These customized reports are made freely available to the responsible network operators as a subscription service. To request a free subscription to The Shadowserver Foundation's ASN/netblock reporting service, send an email from your organization's email account to admin at shadowserver.org Please provide the following information: Name Organization Networks of responsibility by ASN or CIDR Email address(es) of the report receipients Contact information for verification The Shadowserver Foundation is an all volunteer, non-profit, vendor-neutral organization that gathers, tracks, and reports on malicious software, botnet activity, and electronic fraud. It is the mission of the Shadowserver Foundation to improve the security of the Internet by raising awareness of the presence of compromised servers, malicious attackers, and the spread of malicious software. - -- Andre' M. Di Mino - SemperSecurus The Shadowserver Foundation http://www.shadowserver.org Skype: sempersecurus AIM: sempersecurus "Make sure that nobody pays back wrong for wrong, but always try to be kind to each other and to everyone else." 1 Thessalonians 5:15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmaQsEACgkQPJaIJoADD653DQCgkF4aRfxbpSh+IxBfGyrMqT3X eAYAnjfPpeA8ATZ//s1VUrim8DbZPO0C =oMJw -----END PGP SIGNATURE----- From lauren at vortex.com Mon Feb 16 22:55:22 2009 From: lauren at vortex.com (Lauren Weinstein) Date: Mon, 16 Feb 2009 20:55:22 -0800 Subject: Announcing GCTIP - New Forums for Internet Transparency, Performance, and ISP Issues Message-ID: <20090217045522.GC12450@vortex.com> Announcing GCTIP - New Forums for Internet Transparency, Performance, and ISP Issues http://lauren.vortex.com/archive/000506.html Greetings. I'm pleased to announce the availability of a new venue for discussion, reporting, analysis, information sharing, queries, and consumer assistance regarding Internet performance, transparency, and measurement, plus a wide range of topics associated with consumers and their interactions with Internet Service Providers (ISPs). Called GCTIP Forums: http://forums.gctip.org this project -- The "Global Coalition for Transparent Internet Performance" -- is the outgrowth of a network measurement workshop meeting sponsored by Vint Cerf and Google at their headquarters in June, 2008 for a number of academic network measurement researchers and other related parties. This is the same meeting that formed the genesis of the open platform M-Lab ("Measurement Lab") project that was recently announced ( http://www.measurementlab.net ). GCTIP was the original name for the mailing list that I maintained for that Google meeting and subsequent discussions (full disclosure: I helped to organize the agenda for the meeting and also attended). Unless we know what the performance of the Internet for any given users really is -- true bandwidth performance, traffic management, port blocking, server prohibitions, Terms of Service concerns, and a wide range of other parameters, it's impossible for anyone who uses Internet services to really know if they're getting what they're paying for, if their data is being handled appropriately in terms of privacy and security, and all manner of other crucial related issues. While transparency and related concerns do have impacts on "network neutrality" issues, neither GCTIP nor GCTIP Forums are oriented toward network neutrality discussions. The purpose of GCTIP Forums is to provide a free discussion environment to act as a clearinghouse for all stakeholders (technical, consumers, ISPs, government-related, etc.) to interact on the range of "network transparency" and associated topics. The focus is on collecting, analyzing, and disseminating reports relating to Internet measurement/test data -- plus associated concerns, discussions, etc., in manners that are most useful to the network community at large. There are many groups working in the network measurement area, but surprisingly little data sharing, coordination, or ongoing reporting in a form that is useful to most ordinary Internet consumers or other interested observers. An area of particular concern is helping to assure that measurement tests and perceived consumer problems with their ISPs aren't misinterpreted by users resulting in unfair or simply wrong accusations against those ISPs. I feel strongly that consumers need a place to go with these sorts of issues where the broader community and experts can help interpret what's really going on. Guilty firms should be exposed, but the innocent must not be inappropriately branded. All current GCTIP Forums topics can be viewed without signing up on the system. Simple registration is required to post new discussion threads and replies, but no non-administrative topics are currently pre-moderated (any reported materials confirmed to be inappropriate will be deleted promptly). GCTIP Forums exist to enable the exchange of relevant ideas, queries, data, and other information for anyone concerned about the Internet worldwide. The Forums are seeded with five top-level discussion topics to get things rolling, but suggestions for additional categories are welcome. New threads (e.g. discussions of particular measurement tools, measurement results, specific ISP issues and concerns, etc.) can be created by registered users, starting right now. Please note that I am running GCTIP on my own dime at this point. At such a time as any outside support funding becomes available for the project (which would be very much appreciated!) it will be publicly announced of course. Spread the word! This is your chance to help yourself and everyone else better understand what the Internet is really doing, and by extension, where it is going tomorrow. Thanks very much. Be seeing you ... at: http://forums.gctip.org ... --Lauren-- Lauren Weinstein lauren at vortex.com or lauren at pfir.org Tel: +1 (818) 225-2800 http://www.pfir.org/lauren Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org Co-Founder, NNSquad - Network Neutrality Squad - http://www.nnsquad.org Founder, PRIVACY Forum - http://www.vortex.com Member, ACM Committee on Computers and Public Policy Lauren's Blog: http://lauren.vortex.com From fergdawgster at gmail.com Mon Feb 16 23:01:30 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 16 Feb 2009 21:01:30 -0800 Subject: anyone else seeing very long AS paths? In-Reply-To: <200902162351.20286.mulitskiy@acedsl.com> References: <804035053.50831234807438615.JavaMail.root@zimbra.nfsi.pt> <26C8736A04564E51BEB3B1BFBFA72BC0@GINKGO> <200902162351.20286.mulitskiy@acedsl.com> Message-ID: <6cd462c00902162101n5e905be9wc796d6844e30214b@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Feb 16, 2009 at 8:51 PM, Michael Ulitskiy wrote: > It hit my routers at 11:26:40, EST. > > Michael > > On Monday 16 February 2009 07:26:23 pm Adam Greene wrote: >> Anyone have an estimate as to when these long announcements began? Seems >> like the first reports appeared just before noon, UTC-05. >> >> We noticed a significant dip in Internet traffic to AS11579 for a few >> minutes last night (19:00 UTC-05) which we've been trying to hunt down >> the cause of. At first glance, the two events seem unrelated. Anyone >> else see anything similar? > > Just as a follow-up -- and in case anyone hasn't read these yet: http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml http://asert.arbornetworks.com/2009/02/ahh-the-ease-of-introducing-global-r outing-instability/ - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJmkSgq1pz9mNUZTMRAvSrAKDx5/Z5vECDGbxul3rU+vJfr4kiYQCfSNbR um+X7vSLClA3fTkBqszSkWM= =Gm4l -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From jasonlai at singtel.com Mon Feb 16 23:03:59 2009 From: jasonlai at singtel.com (Jason Kalai Arasu) Date: Tue, 17 Feb 2009 13:03:59 +0800 Subject: anyone else seeing very long AS paths? In-Reply-To: <6cd462c00902162101n5e905be9wc796d6844e30214b@mail.gmail.com> References: <804035053.50831234807438615.JavaMail.root@zimbra.nfsi.pt><26C8736A04564E51BEB3B1BFBFA72BC0@GINKGO><200902162351.20286.mulitskiy@acedsl.com> <6cd462c00902162101n5e905be9wc796d6844e30214b@mail.gmail.com> Message-ID: I encountered it yesterday from AS47868. -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Tuesday, February 17, 2009 01:02 PM To: nanog at nanog.org Subject: Re: anyone else seeing very long AS paths? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Feb 16, 2009 at 8:51 PM, Michael Ulitskiy wrote: > It hit my routers at 11:26:40, EST. > > Michael > > On Monday 16 February 2009 07:26:23 pm Adam Greene wrote: >> Anyone have an estimate as to when these long announcements began? >> Seems like the first reports appeared just before noon, UTC-05. >> >> We noticed a significant dip in Internet traffic to AS11579 for a few >> minutes last night (19:00 UTC-05) which we've been trying to hunt >> down the cause of. At first glance, the two events seem unrelated. >> Anyone else see anything similar? > > Just as a follow-up -- and in case anyone hasn't read these yet: http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml http://asert.arbornetworks.com/2009/02/ahh-the-ease-of-introducing-globa l-r outing-instability/ - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJmkSgq1pz9mNUZTMRAvSrAKDx5/Z5vECDGbxul3rU+vJfr4kiYQCfSNbR um+X7vSLClA3fTkBqszSkWM= =Gm4l -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From andreas at naund.org Mon Feb 16 23:46:09 2009 From: andreas at naund.org (Andreas Ott) Date: Mon, 16 Feb 2009 21:46:09 -0800 Subject: Capture problems with Intel quad cards? In-Reply-To: ; from john@hypergeek.net on Sun, Feb 15, 2009 at 09:35:30PM -0800 References: Message-ID: <20090216214609.U1205@naund.org> Hello, On Sun, Feb 15, 2009 at 09:35:30PM -0800, John A. Kilpatrick wrote: > Has anyone had problems with using current Intel quad ethernet cards for > packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT > and hooked it up to some Network Critical taps. There was a very strange > issue with corruption of the captured packets. The *only* issue (but it's > a big one) is that the source IP on some captured packets is munged. As > far as I can tell that's the *only* issue with the packet captures - no > other data is corrupted. ... > So I'm pretty sure we narrowed it down to the card. We tried the card in > an indentical host and saw the same problems. About three years back we had an issue with a dual-port E1000 NIC in Intel 7230NH based 1U servers. Together with the knowledgeable folks at iXsystems we tracked that down to a PCI riser card issue. The 'default' riser was the standard PCB 1U with perpendicular female PCI connector. Using these we saw checksum mismatches on many packets using FreeBSD. After replacing this riser with another one that has a flat ribbon cable to draw more power from an adjacent PCI slot all works well. We did similar elimination troubleshooting: the board worked fine, the card worked fine, the card worked fine when sticking it into the slot while the case was open. Just when using the riser we had trouble. -andreas -- Andreas Ott K6OTT andreas at naund.org From hank at efes.iucc.ac.il Tue Feb 17 00:07:36 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 17 Feb 2009 08:07:36 +0200 (IST) Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: On Mon, 16 Feb 2009, Jon Lewis wrote: > Is there a reason you don't use something like "bgp maxas-limit NN" on your > transit sessions? I've been using maxas=50 for years now (see the 2005 thread: http://www.atm.tut.fi/list-archive/nanog-2005/msg04753.html) I also knew this would happen one day and have tried to get various lists "engaged" but the consensus was "live with it". Here is just my 3 month logs: Nov 30 18:51:32: %BGP-6-ASPATH: Long AS path 8551 3491 7473 45147 18351 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 24532 2 Dec 17 20:47:33: %BGP-6-ASPATH: Long AS path 8551 174 5391 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 43179 received from 128.139.247.2: More than configured MAXAS-LIMIT Dec 24 01:52:20: %BGP-6-ASPATH: Long AS path 8551 174 34224 42555 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 received from 128.139.247.2: More than configured MAXAS-LIMIT Dec 24 02:02:27: %BGP-6-ASPATH: Long AS path 8551 174 34224 42555 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 received from 128.139.247.2: More than configured MAXAS-LIMIT Dec 27 12:31:57: %BGP-6-ASPATH: Long AS path 8551 174 34224 42555 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 received from 128.139.247.2: More than configured MAXAS-LIMIT Dec 27 12:33:16: %BGP-6-ASPATH: Long AS path 8551 3491 174 34224 42555 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 received from 128.139.247.2: More than configured MAXAS-LIMIT Dec 27 12:46:49: %BGP-6-ASPATH: Long AS path 8551 174 34224 42555 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 48262 received from 128.139.247.2: More than configured MAXAS-LIMIT Jan 7 19:26:45: %BGP-6-ASPATH: Long AS path 8551 12989 19181 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 received from 128.139.247.2: More than configured MAXAS-LIMIT Jan 7 19:30:27: %BGP-6-ASPATH: Long AS path 8551 12989 19181 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 received from 128.139.247.2: More than configured MAXAS-LIMIT Jan 7 19:38:06: %BGP-6-ASPATH: Long AS path 8551 12989 19181 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 6488 received from 128.139.247.2: More than configured MAXAS-LIMIT Jan 10 04:57:12: %BGP-6-ASPATH: Long AS path 8551 3257 6453 12968 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 received from 128.139.247.2: More than configured MAXAS-LIMIT Jan 10 05:26:57: %BGP-6-ASPATH: Long AS path 8551 3257 3356 12968 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 received from 128.139.247.2: More than configured MAXAS-LIMIT Jan 10 05:37:06: %BGP-6-ASPATH: Long AS path 8551 3257 1299 1299 1299 1299 8246 39412 39412 39412 12741 12968 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 received from 128.139.247.2: More than configured MAXAS-LIMIT Jan 10 05:37:52: %BGP-6-ASPATH: Long AS path 8551 3491 3549 3320 3320 8246 39412 39412 39412 12741 12887 3257 3356 12968 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 received from 128.139.247.2: More than configured MAXAS-LIMIT Jan 20 10:57:05: %BGP-6-ASPATH: Long AS path 8551 3356 12968 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 33838 received from 128.139.247.2: More than configured MAXAS-LIMIT Feb 14 01:45:13: %BGP-6-ASPATH: Long AS path 8551 3257 3356 39412 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 received from 128.139.247.2: More than configured MAXAS-LIMIT Feb 14 01:45:59: %BGP-6-ASPATH: Long AS path 8551 3257 12887 12741 39412 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 received from 128.139.247.2: More than configured MAXAS-LIMIT Feb 16 18:23:45: %BGP-6-ASPATH: Long AS path 8551 3356 29113 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 received from 128.139.247.2: More than configured MAXAS-LIMIT A regular UN of attempts to do this previously: 24532 - PT. Inet Global Indo, Indonesia 43179 - Team Consulting AS, Bosnia and Herzegovina 48262 - Noblecom Ltd., Bulgaria 6488 - Arizona Macintosh Users Group, USA 39625 - Omni-Araneo, Poland 33838 - BetaNET sp. z o.o, Poland 47868 - SUPRO, spol. s r.o., Czech Republic "They" will keep trying and until a vast majority of ISPs implement maxas, this will keep happening. -Hank > > We saw this too, but it stopped at our transit routers. There was actually > another a few days ago. > > Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 39412 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625... > > Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 > 47868 47868... > > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From j.ott at plusserver.de Tue Feb 17 03:01:52 2009 From: j.ott at plusserver.de (Jens Ott - PlusServer AG) Date: Tue, 17 Feb 2009 10:01:52 +0100 Subject: anyone else seeing very long AS paths? In-Reply-To: References: <804035053.50831234807438615.JavaMail.root@zimbra.nfsi.pt><26C8736A04564E51BEB3B1BFBFA72BC0@GINKGO><200902162351.20286.mulitskiy@acedsl.com> <6cd462c00902162101n5e905be9wc796d6844e30214b@mail.gmail.com> Message-ID: <499A7D00.6040305@plusserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just received reply from Sloan-Park, that they have shutdown that customer yesterday 6:40pm CET and the customer has been requested to clean-up his config. BR Jens Jason Kalai Arasu schrieb: > I encountered it yesterday from AS47868. > > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster at gmail.com] > Sent: Tuesday, February 17, 2009 01:02 PM > To: nanog at nanog.org > Subject: Re: anyone else seeing very long AS paths? > > On Mon, Feb 16, 2009 at 8:51 PM, Michael Ulitskiy > wrote: > >> It hit my routers at 11:26:40, EST. > >> Michael > >> On Monday 16 February 2009 07:26:23 pm Adam Greene wrote: >>> Anyone have an estimate as to when these long announcements began? >>> Seems like the first reports appeared just before noon, UTC-05. >>> >>> We noticed a significant dip in Internet traffic to AS11579 for a few > >>> minutes last night (19:00 UTC-05) which we've been trying to hunt >>> down the cause of. At first glance, the two events seem unrelated. >>> Anyone else see anything similar? > > > Just as a follow-up -- and in case anyone hasn't read these yet: > > http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml > http://asert.arbornetworks.com/2009/02/ahh-the-ease-of-introducing-globa > l-r > outing-instability/ > > - ferg > - -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ - -- =================================================================== Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j.ott at plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstra?e 9-11 50354 H?rth Germany HRB 58428 / Amtsgericht K?ln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschl?ger =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmafQAACgkQMf0yjMLKfXowUACgi4F/j+eGkFfL+2G01r/Ohb0Q XgIAoI4jH6WrkngSOUlDK5lBUZZ3wuEE =/66k -----END PGP SIGNATURE----- From fweimer at bfk.de Tue Feb 17 08:55:38 2009 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 17 Feb 2009 15:55:38 +0100 Subject: anyone else seeing very long AS paths? In-Reply-To: (Hank Nussbacher's message of "Tue, 17 Feb 2009 08:07:36 +0200 (IST)") References: Message-ID: <82r61x5d05.fsf@mid.bfk.de> * Hank Nussbacher: > "They" will keep trying and until a vast majority of ISPs implement > maxas, this will keep happening. Or enthusiastic prepending will be used more often to override local preference. Hard to tell. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jared at puck.nether.net Tue Feb 17 09:05:55 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Feb 2009 10:05:55 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: References: Message-ID: <20090217150555.GB73561@puck.nether.net> On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > A regular UN of attempts to do this previously: > > 24532 - PT. Inet Global Indo, Indonesia > 43179 - Team Consulting AS, Bosnia and Herzegovina > 48262 - Noblecom Ltd., Bulgaria > 6488 - Arizona Macintosh Users Group, USA > 39625 - Omni-Araneo, Poland > 33838 - BetaNET sp. z o.o, Poland > 47868 - SUPRO, spol. s r.o., Czech Republic > > "They" will keep trying and until a vast majority of ISPs implement > maxas, this will keep happening. Or until people who are still running multi-year old cisco code actually upgrade? This seems to primarily impact: 1) Old cisco code 2) PC based bgp daemons Both of which likely just need to be upgraded. I actually suspect that a lot of people who dropped their bgp sessions did not notice something happened, and still will not upgrade their code. I searched the archives, some variations of this have happened since 2001. There's been a few PSIRT and other issues since then, I suspect these people don't even know they have a bgp speaking device anymore. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From cchurc05 at harris.com Tue Feb 17 09:13:15 2009 From: cchurc05 at harris.com (Church, Charles) Date: Tue, 17 Feb 2009 09:13:15 -0600 Subject: IP DSLAMs Message-ID: All, Looking for a recommendation on DSLAMs to replace our unsupported Cisco 6015s. Requirements are: G.SHDSL 2 and 4 wire mode (CPEs are strictly Cisco 828, 878, and small cisco routers using WIC-1SHDSL and the V2/V3 of them) QOS would be nice, not a necessity SNMPv3 and SSHv2 support IPv6 support now or in a future upgrade Doesn't need to actually route, but if it can bridge one or more downstream CPEs into an ethernet dot1q VLAN on an uplink, that'll work Don't want ATM uplinks, ethernet only, dual uplinks preferred Looking for port density ranging from 15 to about 100 in a chassis Power can be DC, but AC is greatly preferred Off-list responses appreciated, since this is kind of OT. These are for large campus environments where some remote buildings are maybe a mile or two from a campus-owned telecom shack, with only copper connectivity to said building. No POTS is required over the DSL links, the copper pairs are dedicated. Thanks, Chuck From shrdlu at deaddrop.org Tue Feb 17 09:21:07 2009 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Tue, 17 Feb 2009 07:21:07 -0800 Subject: anyone else seeing very long AS paths? In-Reply-To: <20090217150555.GB73561@puck.nether.net> References: <20090217150555.GB73561@puck.nether.net> Message-ID: <499AD5E3.30806@deaddrop.org> Jared Mauch wrote: > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: >>"They" will keep trying and until a vast majority of ISPs implement >>maxas, this will keep happening. > Or until people who are still running multi-year old cisco code > actually upgrade? This seems to primarily impact: > > 1) Old cisco code > 2) PC based bgp daemons > Both of which likely just need to be upgraded. I actually suspect > that a lot of people who dropped their bgp sessions did not notice > something happened, and still will not upgrade their code....I > suspect these people don't even know they have a bgp speaking device > anymore. On the other hand, the fact that various entities have gone out of their way to advertise that they're running old hardware/out-of-date software has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, that you update, before someone less pleasant and friendly than myself finds you. Please. -- Remember, if it's in the news, don't worry about it. The very definition of news is "something that almost never happens." When something is so common that it's no longer news -- car crashes, domestic violence -- that's when you should worry about it. (Bruce Schneier) From adrian at creative.net.au Tue Feb 17 09:34:03 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 18 Feb 2009 00:34:03 +0900 Subject: anyone else seeing very long AS paths? In-Reply-To: <499AD5E3.30806@deaddrop.org> References: <20090217150555.GB73561@puck.nether.net> <499AD5E3.30806@deaddrop.org> Message-ID: <20090217153403.GC14136@skywalker.creative.net.au> On Tue, Feb 17, 2009, Etaoin Shrdlu wrote: > On the other hand, the fact that various entities have gone out of their > way to advertise that they're running old hardware/out-of-date software > has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, > that you update, before someone less pleasant and friendly than myself > finds you. Please. What, and the other, "make sure you hard limit the max AS path length from customers and peers, in case of ${LINK_TO_THIS_NANOG_THREAD} ?" Adrian From mulitskiy at acedsl.com Tue Feb 17 10:07:12 2009 From: mulitskiy at acedsl.com (Michael Ulitskiy) Date: Tue, 17 Feb 2009 11:07:12 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <499AD5E3.30806@deaddrop.org> References: <20090217150555.GB73561@puck.nether.net> <499AD5E3.30806@deaddrop.org> Message-ID: <200902171107.13032.mulitskiy@acedsl.com> My bgp speaking devices are a couple of 7200s running 12.2(40). Not the newest IOS out there, but it's been doing the job just fine up until yesterday. Yesterday, when that malformed announcement hit my routers they didn't crash, but they did reset bgp sessions (even though I didn't accept the route) and they kept doing so until I got my upstream to filter it out. According to cisco bug toolkit CSCdr54230 should be fixed in 12.2, so obviously it's not enough. Does anybody know what IOS version has fix this problem, 'cause I couldn't find this info at CCO? Thanks, Michael On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > Jared Mauch wrote: > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > >>"They" will keep trying and until a vast majority of ISPs implement > >>maxas, this will keep happening. > > > Or until people who are still running multi-year old cisco code > > actually upgrade? This seems to primarily impact: > > > > 1) Old cisco code > > 2) PC based bgp daemons > > > Both of which likely just need to be upgraded. I actually suspect > > that a lot of people who dropped their bgp sessions did not notice > > something happened, and still will not upgrade their code....I > > suspect these people don't even know they have a bgp speaking device > > anymore. > > On the other hand, the fact that various entities have gone out of their > way to advertise that they're running old hardware/out-of-date software > has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, > that you update, before someone less pleasant and friendly than myself > finds you. Please. > From hank at efes.iucc.ac.il Tue Feb 17 10:10:24 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 17 Feb 2009 18:10:24 +0200 (IST) Subject: anyone else seeing very long AS paths? In-Reply-To: <20090217150555.GB73561@puck.nether.net> References: <20090217150555.GB73561@puck.nether.net> Message-ID: On Tue, 17 Feb 2009, Jared Mauch wrote: > Or until people who are still running multi-year old cisco code > actually upgrade? This seems to primarily impact: > > 1) Old cisco code > 2) PC based bgp daemons > > Both of which likely just need to be upgraded. I actually suspect > that a lot of people who dropped their bgp sessions did not notice something > happened, and still will not upgrade their code. I searched the archives, some > variations of this have happened since 2001. There's been a few PSIRT and > other issues since then, I suspect these people don't even know they have a > bgp speaking device anymore. While at it - perhaps others wish to join this bugid so as to enhance IOS: CSCso47162 Bug Details BGP-6-ASPATH message should print offending prefix(es) None Symptoms Syslog message below doesn't print info about offending prefix(es) %BGP-6-ASPATH: Invalid AS path [chars] received from [int]: [chars] Further Problem Description Examples of such a message : %BGP-6-ASPATH: Long AS path 64501 64501 65000 65000 received from x.x.x.x: Morethan configured MAXAS-LIMIT %BGP-6-ASPATH: Invalid AS path (64721) 64700 64720 65400 65231 received from x.x.x.x: Non confederation peer I opened it in March 2008 and the more people who bug Cisco to implement this sev 6 request - the better off we will all be in the future. -Hank From Carl.Rosevear at demandmedia.com Tue Feb 17 10:59:28 2009 From: Carl.Rosevear at demandmedia.com (Carl Rosevear) Date: Tue, 17 Feb 2009 08:59:28 -0800 Subject: IPv6 Confusion Message-ID: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... How does IPv6 addressing work? I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host. My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either? >From what I can tell, this may still be a question of great debate. Everyone seems to act like they know exactly what's going on but behind closed doors admits that they don't really know x, y, or z. I realize this is typical of my industry and even myself from time to time. J But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition. There are people here at my company that seem to get it but can't seem to explain it clearly to me. To me, its basically just larger addressing space with some new logical boundaries.... But there are so many discussions of potential addressing methods that I am confused. I know from my lab setups that I can "make it work" but I'd like to "do it right". J I've been doing this for over 10 years now... IPv4 is native to me. If you can point me in the direction of some good, authoritative information or even say "Dood, go get IPv6 for dummies", that's fine I just need to know where to find some good information. Can someone say "well, you know how it would be nice to have like 100 different addresses on hosts to differentiate services and blah blah.... Well now that's what you account for and so then you know how a /24 almost always ends up being tight in IPv4? Right, so think of your basic bit boundaries that you adhere to as /?? And /??? In IPv6." Or "Throw all that old thought out the window. Now its kind of like how the Ford Probe is actually a Mazda... ummm.... Yeah I can't really explain it either but it makes sense. Here read this book and it'll make sense to you too." Respectfully yours, Carl Rosevear From mohacsi at niif.hu Tue Feb 17 11:21:24 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 17 Feb 2009 18:21:24 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> Message-ID: On Tue, 17 Feb 2009, Carl Rosevear wrote: > So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ... > > How does IPv6 addressing work? If you are interested about the addressing architecture only, have a look at RFC 4291: http://tools.ietf.org/html/rfc4291 If you want to have some allocation guidelines from experiences, have a look at these slides: http://www.6deploy.org/tutorials/030-6deploy_ipv6_addressing_v0_2.pdf http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_3.pdf Best Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From trejrco at gmail.com Tue Feb 17 11:35:38 2009 From: trejrco at gmail.com (TJ) Date: Tue, 17 Feb 2009 12:35:38 -0500 Subject: IPv6 Confusion In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> Message-ID: <008401c99126$26ae6d40$740b47c0$@com> >How does IPv6 addressing work? Short version: 2000::/3 The currently active global unicast pool RIRx::/12 IANA (by default) assigns /12s to RIRs RIRx:ISPx::/32 RIRs (by default) assign /32s to ISPs RIRx:ISPx:ORGx::/48 ISPs (by default) assign /48s to enterprises (/56s to homes) RIRx:ISPx:ORGx:VLAN::/64 Enterprises 'subnet' their allocation into /64s (debate over [/126 | /127] to P2P links) >I know it's been hashed and rehashed but several orgs I am associated with are >about to ask for their allocations from ARIN and we are all realizing we don't >really know how the network / subnet structure trickles down from the edge to >the host. We really don't have a firm grasp of all of this as there seems to >be multiple options regarding how many addresses should be assigned to a host, >if the MAC address should be included in the address or if that is just for >auto-configuration purposes or what the heck the deal is. There are a lot of >clear statements out there and a lot that are clear as mud. Unfortunately, >even when trying to analyze which RFC superseded another. Can I just subnet it Use the IETF/RFC web interface, clearly shows what RFCs where deprecated by, or deprecate/update, a given doc: e.g. - http://tools.ietf.org/html/rfc2461 ... has an obsoleted by, updated by, and obsoletes ... >all like IPv4 but with room to grow or is each host really going to need its >own /84 or something? I can't see why hosts would need any more addresses than >today but maybe I'm missing something because a lot of addressing models sure >allow for a huge number of unique addresses per host. > > >My buddy and I are about to go to Barnes and Noble, not having and luck with >standard internet media but then we realized... how will we know if any of >that is really what we are looking for either? Depends what you are looking for, and possibly your HW vendor of choice. <> From fred at cisco.com Tue Feb 17 12:04:26 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 17 Feb 2009 10:04:26 -0800 Subject: IPv6 Confusion In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> Message-ID: You already have a fair bit of information, but the short answer to your question is... Apart from a few special purposes addresses (see RFC 4291), IPv6 addresses are a cross between IPv4-style CIDR addressing and XNS/IPX/ ISO-style network+host addressing. Bits 0..63 of the address are a CIDR prefix; there are various guidelines on what prefix lengths should be allocated in various cases, but they are just that - unenforceable and mutable. Bits 64..127 are a host part, which may be a MAC Address, a random number, or pretty much anything else. The key thing is that the host part is unique on a LAN. There are probably four important prefix lengths in the world - prefixes that might have special meaning, prefixes that get allocated by IANA, prefixes that get allocated by RIRs, and prefixes that get allocated to customers of ISPs. In general, IANA is treating IPv6 much like IPv4 - making sure that the RIRs have enough to work with. The RIRs are also treating IPv6 much like IPv4, with the exception that the rules require a lot less hoop-jumping. If folks need prefixes, they hand them out. The one difference is that they are trying to avoid PI addressing, as that is one of the major contributors to the current explosion of the route table (the others being "long prefixes" and "traffic engineering"). What to replace PI addressing with is a topic of ongoing discussion - various ideas have been proposed but all require some change to some business model or sacred cow somewhere, meaning that any idea that is viable gets dismissed pretty rapidly, something the folks who buy memory for routers will eventually pay the price of unless that nonsense passes. Edge networks are edge networks; they tend to assign subnets, or campuses with subnets in them. On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: > So, I understand the main concepts behind IPv6. Most of my peers > understand. We all have a detailed understanding of most things > IPv4. I have Googled and read RFCs about IPv6 for HOURS. That > said, to quickly try to minimize people thinking I am an idiot who > asks before he reads, I need some answers. First of all, several of > my friends who feel they are rather authoritative on the subject of > things network-related have given me conflicting answers. So what's > the question? ... > > How does IPv6 addressing work? > > I know it's been hashed and rehashed but several orgs I am > associated with are about to ask for their allocations from ARIN and > we are all realizing we don't really know how the network / subnet > structure trickles down from the edge to the host. We really don't > have a firm grasp of all of this as there seems to be multiple > options regarding how many addresses should be assigned to a host, > if the MAC address should be included in the address or if that is > just for auto-configuration purposes or what the heck the deal is. > There are a lot of clear statements out there and a lot that are > clear as mud. Unfortunately, even when trying to analyze which RFC > superseded another. Can I just subnet it all like IPv4 but with > room to grow or is each host really going to need its own /84 or > something? I can't see why hosts would need any more addresses than > today but maybe I'm missing something because a lot of addressing > models sure allow for a huge number of unique addresses per host. > > > My buddy and I are about to go to Barnes and Noble, not having and > luck with standard internet media but then we realized... how will > we know if any of that is really what we are looking for either? > >> From what I can tell, this may still be a question of great >> debate. Everyone seems to act like they know exactly what's going >> on but behind closed doors admits that they don't really know x, y, >> or z. I realize this is typical of my industry and even myself >> from time to time. J > > But so I am truly reaching out here. What is the deal with IPv6 > addressing and subneting? Where is the official guide to this new > galaxy? I will be sure to pass this information on to my equally > less clueful peers to the benefit of all of us that are making this > transition. > > There are people here at my company that seem to get it but can't > seem to explain it clearly to me. To me, its basically just larger > addressing space with some new logical boundaries.... But there are > so many discussions of potential addressing methods that I am > confused. I know from my lab setups that I can "make it work" but > I'd like to "do it right". J > > I've been doing this for over 10 years now... IPv4 is native to > me. If you can point me in the direction of some good, > authoritative information or even say "Dood, go get IPv6 for > dummies", that's fine I just need to know where to find some good > information. > > Can someone say "well, you know how it would be nice to have like > 100 different addresses on hosts to differentiate services and blah > blah.... Well now that's what you account for and so then you know > how a /24 almost always ends up being tight in IPv4? Right, so > think of your basic bit boundaries that you adhere to as /?? > And /??? In IPv6." Or "Throw all that old thought out the > window. Now its kind of like how the Ford Probe is actually a > Mazda... ummm.... Yeah I can't really explain it either but it > makes sense. Here read this book and it'll make sense to you too." > > > > Respectfully yours, > > > > Carl Rosevear > > > From scott at doc.net.au Tue Feb 17 12:26:33 2009 From: scott at doc.net.au (Scott Howard) Date: Tue, 17 Feb 2009 10:26:33 -0800 Subject: IPv6 Confusion In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> Message-ID: I can't help directly with your biggest question, but there's a smaller point here that seems to come up a lot and I think is important to address... On Tue, Feb 17, 2009 at 8:59 AM, Carl Rosevear < Carl.Rosevear at demandmedia.com> wrote: > I can't see why hosts would need any more addresses than today but maybe > I'm missing something because a lot of addressing models sure allow for a > huge number of unique addresses per host. According to your website your head office is located at "1333 2nd St., Suite 100". Is there a 1331 2nd Street? Or a 1335? Or even a Suite 99? Or has the street addressing system been created in a wasteful manner in order to allow flexibility in addressing and allow the numbers themselves to be more than just numbers? Just like street numbers, IPv6 is a near limitless resource, which allows for the address assigned to be more than just a simple, single address. Yes, this results in some "waste", just like having to write "1333" in your address where "17" might have sufficed. IPv6 assigns a /something to each "thing", in the same way as many areas in the US simply assign 100 numbers to each block. In that sense IPv6 requires a mind-set change from IPv4 - you can stop thinking in terms of the absolute minimum requirements (eg, a single IP address in v4 because they are a scarce commodity) and start thinking about what works best for the larger environment (such as just handing out a /64 to each network and allowing autoconfig to handle the rest). Is that wasteful? Hell yeah! Does it matter? No! The bigger question here is of course what size "/something", and what is a "thing", and as recent discussions here and elsewhere have proven there's still some contention over those questions - especially around home users. The problem is that as an industry there simply hasn't been enough IPv6 deployment done to know what will work and what will not - or what is "best" (for some definition of "best") I'm sure many of us were around in the days when if even a smaller customer wanted a network routed you were just as likely to either give them a class C, or even to get them to register their own class C - because at the time we thought that was the right thing to do. Over the years as the commercial Internet grew we leant what was the "best" thing to do in most cases, and the same business who 15 years ago was registering their own class C would today probably get gives a single IP address - possibly even a dynamic one! Of course the hardware also changed with the times, so that now the $30 router you can buy at Walmart has NAT, DHCP, uPNP and the ability to update DDNS all buit in to make the model work. Odds are what is best is going to be "best" for IPv6 will be a similar iterative approach - the model the first round of IPv6 ISPs roll out will probably not be the same as the one we're using in 5-10 years. Part of this will be due to limitations in the infrastructure (not the least the home-user CPE), but part of it of it will simply come down to experiences, and learning what does and doesn't work well. Today you'll find numerous RFCs and IETF drafts telling you in theory how it could/should work, but until there's more people doing it these are little more than theory... Scott From jbates at brightok.net Tue Feb 17 12:32:26 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 17 Feb 2009 12:32:26 -0600 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> Message-ID: <499B02BA.8040304@brightok.net> Mohacsi Janos wrote: > If you are interested about the addressing architecture only, have a > look at RFC 4291: http://tools.ietf.org/html/rfc4291 > > If you want to have some allocation guidelines from experiences, have a > look at these slides: > http://www.6deploy.org/tutorials/030-6deploy_ipv6_addressing_v0_2.pdf > http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf > > http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_3.pdf > Just to add to this, beware the vendor documentation. In particular, I noticed many "examples" posted by vendors that used all kinds of notations. Cisco, for example, formally uses /64 in current documentation but still has a ton of old docs which use /112 or other similar boundaries. Since searches don't always turn up "most current", you may find obsolete documentation. -Jack From owen at delong.com Tue Feb 17 12:40:50 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 17 Feb 2009 10:40:50 -0800 Subject: IPv6 Confusion In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> Message-ID: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: > So, I understand the main concepts behind IPv6. Most of my peers > understand. We all have a detailed understanding of most things > IPv4. I have Googled and read RFCs about IPv6 for HOURS. That > said, to quickly try to minimize people thinking I am an idiot who > asks before he reads, I need some answers. First of all, several of > my friends who feel they are rather authoritative on the subject of > things network-related have given me conflicting answers. So what's > the question? ... > > How does IPv6 addressing work? > There are a lot of different possible answers to that question, many of which are accurate. In general: It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). > I know it's been hashed and rehashed but several orgs I am > associated with are about to ask for their allocations from ARIN and > we are all realizing we don't really know how the network / subnet > structure trickles down from the edge to the host. We really don't > have a firm grasp of all of this as there seems to be multiple > options regarding how many addresses should be assigned to a host, > if the MAC address should be included in the address or if that is > just for auto-configuration purposes or what the heck the deal is. > There are a lot of clear statements out there and a lot that are > clear as mud. Unfortunately, even when trying to analyze which RFC > superseded another. Can I just subnet it all like IPv4 but with > room to grow or is each host really going to need its own /84 or > something? I can't see why hosts would need any more addresses than > today but maybe I'm missing something because a lot of addressing > models sure allow for a huge number of unique addresses per host. > You can subnet it just like IPv4. Each host does not need it's own subnet (/64, not /84 for the most part). The theory behind /64 subnets was to support a way for a host to use what it already knows (MAC address) and possibly some additional clues (Router Announcement) from the wire to configure its own IPv6 address on an interface. Whether or not this was a good idea is still controversial, but, whether or not it's how IPv6 is going to work is not. IPv6 is designed to work with Stateless Autoconfiguration whether we like it or not. DHCPv6 so far is prevented from providing default router information (or many of the other things you're used to having DHCP do) as it currently stands. > > My buddy and I are about to go to Barnes and Noble, not having and > luck with standard internet media but then we realized... how will > we know if any of that is really what we are looking for either? > It's a fair point. There is a good FAQ/Wiki on the ARIN web site. That may be a good place to start. >> From what I can tell, this may still be a question of great >> debate. Everyone seems to act like they know exactly what's going >> on but behind closed doors admits that they don't really know x, y, >> or z. I realize this is typical of my industry and even myself >> from time to time. J > > But so I am truly reaching out here. What is the deal with IPv6 > addressing and subneting? Where is the official guide to this new > galaxy? I will be sure to pass this information on to my equally > less clueful peers to the benefit of all of us that are making this > transition. > Officially, the best summary I can give is that the subnetting model is almost identical to IPv4, but, all subnets should be at least a /64 (and it's hard to imagine a scenario where a single subnet should be larger, but, it can be supported). The essential initial guidelines are: ISP /32 Enough for 4billion ISPs Enough for each ISP to support 65,536 /48 customers or 16.7M /56 customers, etc. Larger ISPs can get more than a /32 if needed. End Site /48 Enough for 65,536 /64 subnets Larger organizations can get more than a /48 if needed. Single Subnet /64 Enough for more hosts that most of us can imagine on a single subnet. Support for 64 bit MAC addresses Support for stateless autoconfiguration However, these guidelines can be violated in many circumstances to use smaller subnets if you really want to. I don't recommend it and there's really no reason to do so. Finally, if we're wrong about all of this, it's OK. We can renumber people into the other 7/8ths of the IPv6 space that are not yet issued for usage by IANA with an entirely different numbering scheme. > There are people here at my company that seem to get it but can't > seem to explain it clearly to me. To me, its basically just larger > addressing space with some new logical boundaries.... But there are > so many discussions of potential addressing methods that I am > confused. I know from my lab setups that I can "make it work" but > I'd like to "do it right". J > Hope the above helps. > I've been doing this for over 10 years now... IPv4 is native to > me. If you can point me in the direction of some good, > authoritative information or even say "Dood, go get IPv6 for > dummies", that's fine I just need to know where to find some good > information. > Unfortunately, other than the guidelines above, most of us are still experimenting and don't have a lot of op-ex to build on. > Can someone say "well, you know how it would be nice to have like > 100 different addresses on hosts to differentiate services and blah > blah.... Well now that's what you account for and so then you know > how a /24 almost always ends up being tight in IPv4? Right, so > think of your basic bit boundaries that you adhere to as /?? > And /??? In IPv6." Or "Throw all that old thought out the > window. Now its kind of like how the Ford Probe is actually a > Mazda... ummm.... Yeah I can't really explain it either but it > makes sense. Here read this book and it'll make sense to you too." > Your basic bit boundary for a subnet really should be /64. You certainly can put as many IP addresses on a single host as you wish and there's no reason not to address services as you describe. There is no longer a concern about the tightness of the subnet since a /64 is the square of the total number of hosts that could be supported on the entire internet without network/broadcast overhead, etc. In IPv6, there really is no shortage of addresses and extremely little likelihood of that ever being a problem, even with the wasteful allocation polices we currently have in place. Hope that helps, Owen (Speaking only as and for myself. This is not an official position or recommendation from the ARIN AC. I'm just trying to help.) From gmartine at ajax.opentransit.net Tue Feb 17 12:54:34 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Tue, 17 Feb 2009 13:54:34 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <200902171107.13032.mulitskiy@acedsl.com> References: <20090217150555.GB73561@puck.nether.net> <499AD5E3.30806@deaddrop.org> <200902171107.13032.mulitskiy@acedsl.com> Message-ID: <20090217185434.GA9548@ajax.opentransit.net> On Tue Feb 17, 2009, Michael Ulitskiy wrote: Hello, CSCee30718 ? it removes the default value of bgp max-as from the router. The solution is introduced in CSCeh13489 BGP shouldn't propogate an update w excessive AS Path > 255 Symptoms: A router may reset its Border Gateway Protocol (BGP) session. Conditions: This symptom is observed when a Cisco router that peers with other routers receives an Autonomous System (AS) path with a length that is equal to or greater than 255. Workaround: Configure the bgp maxas limit command in such as way that the maximum length of the AS path is a value below 255. When the router receives an update with an excessive AS path value, the prefix is rejected and recorded the event in the log. This workaround has been suggested previously by Hank. Anyone knows about any possible CPU impacts in case that you implement bgp maxas? Thanks German > My bgp speaking devices are a couple of 7200s running 12.2(40). > Not the newest IOS out there, but it's been doing the job just fine up until yesterday. > Yesterday, when that malformed announcement hit my routers they didn't crash, > but they did reset bgp sessions (even though I didn't accept the route) and they kept doing so > until I got my upstream to filter it out. > According to cisco bug toolkit CSCdr54230 should be fixed in 12.2, so obviously it's not enough. > Does anybody know what IOS version has fix this problem, 'cause I couldn't find this info at CCO? > Thanks, > > Michael > > On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > > Jared Mauch wrote: > > > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > > > >>"They" will keep trying and until a vast majority of ISPs implement > > >>maxas, this will keep happening. > > > > > Or until people who are still running multi-year old cisco code > > > actually upgrade? This seems to primarily impact: > > > > > > 1) Old cisco code > > > 2) PC based bgp daemons > > > > > Both of which likely just need to be upgraded. I actually suspect > > > that a lot of people who dropped their bgp sessions did not notice > > > something happened, and still will not upgrade their code....I > > > suspect these people don't even know they have a bgp speaking device > > > anymore. > > > > On the other hand, the fact that various entities have gone out of their > > way to advertise that they're running old hardware/out-of-date software > > has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, > > that you update, before someone less pleasant and friendly than myself > > finds you. Please. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Carl.Rosevear at demandmedia.com Tue Feb 17 12:57:36 2009 From: Carl.Rosevear at demandmedia.com (Carl Rosevear) Date: Tue, 17 Feb 2009 10:57:36 -0800 Subject: IPv6 Confusion In-Reply-To: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> Message-ID: <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> Thanks to all that responded on and off-list. My confusion is mostly cleared-up. The points that are unclear at this point are generally unclear to most people, it seems due to lack of operational experience with IPv6. Feel free to keep responding to this topic as its all very interesting but I think my needs have been met. Owen, this one from you tied it all together. Thanks all! --Carl -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, February 17, 2009 10:41 AM To: Carl Rosevear Cc: nanog at nanog.org Subject: Re: IPv6 Confusion On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: > So, I understand the main concepts behind IPv6. Most of my peers > understand. We all have a detailed understanding of most things > IPv4. I have Googled and read RFCs about IPv6 for HOURS. That > said, to quickly try to minimize people thinking I am an idiot who > asks before he reads, I need some answers. First of all, several of > my friends who feel they are rather authoritative on the subject of > things network-related have given me conflicting answers. So what's > the question? ... > > How does IPv6 addressing work? > There are a lot of different possible answers to that question, many of which are accurate. In general: It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). > I know it's been hashed and rehashed but several orgs I am > associated with are about to ask for their allocations from ARIN and > we are all realizing we don't really know how the network / subnet > structure trickles down from the edge to the host. We really don't > have a firm grasp of all of this as there seems to be multiple > options regarding how many addresses should be assigned to a host, > if the MAC address should be included in the address or if that is > just for auto-configuration purposes or what the heck the deal is. > There are a lot of clear statements out there and a lot that are > clear as mud. Unfortunately, even when trying to analyze which RFC > superseded another. Can I just subnet it all like IPv4 but with > room to grow or is each host really going to need its own /84 or > something? I can't see why hosts would need any more addresses than > today but maybe I'm missing something because a lot of addressing > models sure allow for a huge number of unique addresses per host. > You can subnet it just like IPv4. Each host does not need it's own subnet (/64, not /84 for the most part). The theory behind /64 subnets was to support a way for a host to use what it already knows (MAC address) and possibly some additional clues (Router Announcement) from the wire to configure its own IPv6 address on an interface. Whether or not this was a good idea is still controversial, but, whether or not it's how IPv6 is going to work is not. IPv6 is designed to work with Stateless Autoconfiguration whether we like it or not. DHCPv6 so far is prevented from providing default router information (or many of the other things you're used to having DHCP do) as it currently stands. > > My buddy and I are about to go to Barnes and Noble, not having and > luck with standard internet media but then we realized... how will > we know if any of that is really what we are looking for either? > It's a fair point. There is a good FAQ/Wiki on the ARIN web site. That may be a good place to start. >> From what I can tell, this may still be a question of great >> debate. Everyone seems to act like they know exactly what's going >> on but behind closed doors admits that they don't really know x, y, >> or z. I realize this is typical of my industry and even myself >> from time to time. J > > But so I am truly reaching out here. What is the deal with IPv6 > addressing and subneting? Where is the official guide to this new > galaxy? I will be sure to pass this information on to my equally > less clueful peers to the benefit of all of us that are making this > transition. > Officially, the best summary I can give is that the subnetting model is almost identical to IPv4, but, all subnets should be at least a /64 (and it's hard to imagine a scenario where a single subnet should be larger, but, it can be supported). The essential initial guidelines are: ISP /32 Enough for 4billion ISPs Enough for each ISP to support 65,536 /48 customers or 16.7M /56 customers, etc. Larger ISPs can get more than a /32 if needed. End Site /48 Enough for 65,536 /64 subnets Larger organizations can get more than a /48 if needed. Single Subnet /64 Enough for more hosts that most of us can imagine on a single subnet. Support for 64 bit MAC addresses Support for stateless autoconfiguration However, these guidelines can be violated in many circumstances to use smaller subnets if you really want to. I don't recommend it and there's really no reason to do so. Finally, if we're wrong about all of this, it's OK. We can renumber people into the other 7/8ths of the IPv6 space that are not yet issued for usage by IANA with an entirely different numbering scheme. > There are people here at my company that seem to get it but can't > seem to explain it clearly to me. To me, its basically just larger > addressing space with some new logical boundaries.... But there are > so many discussions of potential addressing methods that I am > confused. I know from my lab setups that I can "make it work" but > I'd like to "do it right". J > Hope the above helps. > I've been doing this for over 10 years now... IPv4 is native to > me. If you can point me in the direction of some good, > authoritative information or even say "Dood, go get IPv6 for > dummies", that's fine I just need to know where to find some good > information. > Unfortunately, other than the guidelines above, most of us are still experimenting and don't have a lot of op-ex to build on. > Can someone say "well, you know how it would be nice to have like > 100 different addresses on hosts to differentiate services and blah > blah.... Well now that's what you account for and so then you know > how a /24 almost always ends up being tight in IPv4? Right, so > think of your basic bit boundaries that you adhere to as /?? > And /??? In IPv6." Or "Throw all that old thought out the > window. Now its kind of like how the Ford Probe is actually a > Mazda... ummm.... Yeah I can't really explain it either but it > makes sense. Here read this book and it'll make sense to you too." > Your basic bit boundary for a subnet really should be /64. You certainly can put as many IP addresses on a single host as you wish and there's no reason not to address services as you describe. There is no longer a concern about the tightness of the subnet since a /64 is the square of the total number of hosts that could be supported on the entire internet without network/broadcast overhead, etc. In IPv6, there really is no shortage of addresses and extremely little likelihood of that ever being a problem, even with the wasteful allocation polices we currently have in place. Hope that helps, Owen (Speaking only as and for myself. This is not an official position or recommendation from the ARIN AC. I'm just trying to help.) From mike at rockynet.com Tue Feb 17 13:02:50 2009 From: mike at rockynet.com (Mike Lewinski) Date: Tue, 17 Feb 2009 12:02:50 -0700 Subject: anyone else seeing very long AS paths? In-Reply-To: <20090217185434.GA9548@ajax.opentransit.net> References: <20090217150555.GB73561@puck.nether.net> <499AD5E3.30806@deaddrop.org> <200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net> Message-ID: <499B09DA.9090100@rockynet.com> German Martinez wrote: > Workaround: Configure the bgp maxas limit command in such > as way that the maximum length of the AS path is a value below 255. When the > router receives an update with an excessive AS path value, the prefix is > rejected and recorded the event in the log. > > This workaround has been suggested previously by Hank. > > Anyone knows about any possible CPU impacts in case that you implement > bgp maxas? bgp max-as will NOT protect you from this exploit (but if you are not vulnerable it should prevent you from propogating it). As far as I can tell the ONLY defense for a vulnerable IOS is to not run BGP. Dropping every received route with a filter on 0/0 does not mitigate the attack - as soon as that bogus as-path is received the BGP session resets, even if the route is never actually installed (and as far as I can tell the only real effect of the "bgp maxas-limit 75" is to cause all paths with more than 75 ASN to not be installed in the routing table). From gmartine at ajax.opentransit.net Tue Feb 17 13:20:59 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Tue, 17 Feb 2009 14:20:59 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <499B09DA.9090100@rockynet.com> References: <20090217150555.GB73561@puck.nether.net> <499AD5E3.30806@deaddrop.org> <200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net> <499B09DA.9090100@rockynet.com> Message-ID: <20090217192059.GA10934@ajax.opentransit.net> On Tue Feb 17, 2009, Mike Lewinski wrote: > bgp max-as will NOT protect you from this exploit (but if you are not > vulnerable it should prevent you from propogating it). Are you trying to say that the receiving bgp speaker will drop the session no matter what but it won't forward the update? Here is what I have found on Cisco's website bgp maxas-limit To configure Border Gateway Protocol (BGP) to discard routes that have a number of as-path segments that exceed the specified value, use the bgp maxas-limit command in router configuration mode. To return the router to default operation, use the no form of this command. Usage Guidelines The bgp maxas-limit command is used to limit the number of as-path segments that are permitted in inbound routes. If a route is received with an as-path segment that exceeds the configured limit, the BGP routing process will discard the route. I heard about people running this command that were not impacted > > As far as I can tell the ONLY defense for a vulnerable IOS is to not run > BGP. Dropping every received route with a filter on 0/0 does not mitigate > the attack - as soon as that bogus as-path is received the BGP session > resets, even if the route is never actually installed (and as far as I can > tell the only real effect of the "bgp maxas-limit 75" is to cause all paths > with more than 75 ASN to not be installed in the routing table). > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jbates at brightok.net Tue Feb 17 13:19:00 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 17 Feb 2009 13:19:00 -0600 Subject: anyone else seeing very long AS paths? In-Reply-To: <20090217192059.GA10934@ajax.opentransit.net> References: <20090217150555.GB73561@puck.nether.net> <499AD5E3.30806@deaddrop.org> <200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net> <499B09DA.9090100@rockynet.com> <20090217192059.GA10934@ajax.opentransit.net> Message-ID: <499B0DA4.20708@brightok.net> German Martinez wrote: > On Tue Feb 17, 2009, Mike Lewinski wrote: > >> bgp max-as will NOT protect you from this exploit (but if you are not >> vulnerable it should prevent you from propogating it). > > Are you trying to say that the receiving bgp speaker will drop the session > no matter what but it won't forward the update? There are reports that some versions of IOS will drop a peer upon receiving the long AS, even with a bgp max-as command. I can only presume that there are some IOS versions that determine the update is invalid prior to the max-as command determining we are not keeping the route. The whole "is the update valid?" vs "do I want this in my routing table?" Jack From ivan.pepelnjak at zaplana.net Tue Feb 17 13:24:38 2009 From: ivan.pepelnjak at zaplana.net (Ivan Pepelnjak) Date: Tue, 17 Feb 2009 20:24:38 +0100 Subject: anyone else seeing very long AS paths? In-Reply-To: <20090217185434.GA9548@ajax.opentransit.net> References: <20090217150555.GB73561@puck.nether.net><499AD5E3.30806@deaddrop.org><200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net> Message-ID: <002101c99135$60a4d840$0a00000a@nil.si> According to publicly available bug toolkit, CSCee30718 did not touch the maxas limit. The hard-coded maxas-limit in recent IOS releases is 254 (not 75 as suggested in a previous e-mail). Classic IOS (I did not test XE, XR or NX) can handle inbound updates with AS path lengths above 255, but fails miserably when it has to send an oversized update (producing invalid BGP UPDATE message), resulting in a flapping BGP session (anyone who wants to test this behavior and report/fix this bug can get all the files needed to reproduce it). The hard-coded maxas-limit prevents this behavior (254 + my AS = 255), but if you use AS-path prepending on outbound update, you're fried. The __ONLY__ way to be on the safe side is to configure "bgp maxas-limit", otherwise someone who knows you're doing AS-path prepending on major peering sessions (and no inbound AS-path filtering) can selectively target your peering points. I've summarized everything I've discovered in various stress tests today (well, not the targeted attack :) in this article: http://wiki.nil.com/Limit_the_maximum_BGP_AS-path_length Feel free to improve it:) Ivan http://blog.ioshints.info > -----Original Message----- > From: German Martinez [mailto:gmartine at ajax.opentransit.net] > Sent: Tuesday, February 17, 2009 7:55 PM > To: Michael Ulitskiy > Cc: nanog at nanog.org > Subject: Re: anyone else seeing very long AS paths? > > On Tue Feb 17, 2009, Michael Ulitskiy wrote: > > Hello, > CSCee30718 - it removes the default value of bgp max-as from the > router. > > The solution is introduced in CSCeh13489 > > BGP shouldn't propogate an update w excessive AS Path > 255 > Symptoms: A router may reset its Border Gateway Protocol > (BGP) session. > > Conditions: This symptom is observed when a Cisco router that peers > with other routers receives an Autonomous System (AS) path with a > length that is equal to or greater than 255. > > Workaround: Configure the bgp maxas limit command in such as way that > the maximum length of the AS path is a value below 255. When the > router receives an update with an excessive AS path value, the prefix > is rejected and recorded the event in the log. > > This workaround has been suggested previously by Hank. > > Anyone knows about any possible CPU impacts in case that you implement > bgp maxas? > > Thanks > German > > > My bgp speaking devices are a couple of 7200s running 12.2(40). > > Not the newest IOS out there, but it's been doing the job > just fine up until yesterday. > > Yesterday, when that malformed announcement hit my routers > they didn't > > crash, but they did reset bgp sessions (even though I didn't accept > > the route) and they kept doing so until I got my upstream > to filter it out. > > According to cisco bug toolkit CSCdr54230 should be fixed > in 12.2, so obviously it's not enough. > > Does anybody know what IOS version has fix this problem, > 'cause I couldn't find this info at CCO? > > Thanks, > > > > Michael > > > > On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > > > Jared Mauch wrote: > > > > > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > > > > > >>"They" will keep trying and until a vast majority of ISPs > > > >>implement maxas, this will keep happening. > > > > > > > Or until people who are still running > multi-year old cisco code > > > > actually upgrade? This seems to primarily impact: > > > > > > > > 1) Old cisco code > > > > 2) PC based bgp daemons > > > > > > > Both of which likely just need to be upgraded. I > actually suspect > > > > that a lot of people who dropped their bgp sessions did > not notice > > > > something happened, and still will not upgrade their code....I > > > > suspect these people don't even know they have a bgp speaking > > > > device anymore. > > > > > > On the other hand, the fact that various entities have > gone out of > > > their way to advertise that they're running old > hardware/out-of-date > > > software has been noted elsewhere. I'd strongly suggest, > if you're reading NANOG, > > > that you update, before someone less pleasant and friendly than > > > myself finds you. Please. > > > > > > > > From alh-ietf at tndh.net Tue Feb 17 13:28:11 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 17 Feb 2009 11:28:11 -0800 Subject: IPv6 Confusion In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> Message-ID: <050701c99135$df0f0ed0$9d2d2c70$@net> While people frequently claim that auto-config is optional, there are implementations (including OS-X) that don't support anything else at this point. The basic message is that you should not assume that the host implementations will conform to what the network operator would prefer, and you need to test. One last comment (because I hear "just more bits" a lot in the *nog community)... Approach IPv6 as a new and different protocol. If you approach it as "IPv4 with more bits", you will trip over the differences and be pissed off. If you approach it as a "different protocol with a name that starts with IP" and runs alongside IPv4 (like we used to do with decnet, sna, appletalk...), you will be comforted in all the similarities. You will also hear lots of noise about 'lack of compatibility', which is just another instance of refusing to recognize that this is really a different protocol. At the end of the day, it is a packet based protocol that moves payloads around. Tony > -----Original Message----- > From: Carl Rosevear [mailto:Carl.Rosevear at demandmedia.com] > Sent: Tuesday, February 17, 2009 10:58 AM > To: Owen DeLong > Cc: nanog at nanog.org > Subject: RE: IPv6 Confusion > > Thanks to all that responded on and off-list. My confusion is mostly > cleared-up. The points that are unclear at this point are generally > unclear to most people, it seems due to lack of operational experience > with IPv6. Feel free to keep responding to this topic as its all very > interesting but I think my needs have been met. Owen, this one from > you tied it all together. Thanks all! > > > > --Carl > > > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, February 17, 2009 10:41 AM > To: Carl Rosevear > Cc: nanog at nanog.org > Subject: Re: IPv6 Confusion > > > On Feb 17, 2009, at 8:59 AM, Carl Rosevear wrote: > > > So, I understand the main concepts behind IPv6. Most of my peers > > understand. We all have a detailed understanding of most things > > IPv4. I have Googled and read RFCs about IPv6 for HOURS. That > > said, to quickly try to minimize people thinking I am an idiot who > > asks before he reads, I need some answers. First of all, several of > > my friends who feel they are rather authoritative on the subject of > > things network-related have given me conflicting answers. So what's > > the question? ... > > > > How does IPv6 addressing work? > > > There are a lot of different possible answers to that question, many > of which are accurate. > > In general: > > It's a 128 bit address. Routing is done on VLSM, but, generally for > DNS purposes, these > are expected to be at least on nibble boundaries. > > There is an intent to support what is known as EUI-64, which means > every subnet should > be a /64, however, there are people who number smaller subnets and > that is supposed > to work, but, it will break certain IPv6 things like stateless > autoconfiguration (which is > optional). > > > I know it's been hashed and rehashed but several orgs I am > > associated with are about to ask for their allocations from ARIN and > > we are all realizing we don't really know how the network / subnet > > structure trickles down from the edge to the host. We really don't > > have a firm grasp of all of this as there seems to be multiple > > options regarding how many addresses should be assigned to a host, > > if the MAC address should be included in the address or if that is > > just for auto-configuration purposes or what the heck the deal is. > > There are a lot of clear statements out there and a lot that are > > clear as mud. Unfortunately, even when trying to analyze which RFC > > superseded another. Can I just subnet it all like IPv4 but with > > room to grow or is each host really going to need its own /84 or > > something? I can't see why hosts would need any more addresses than > > today but maybe I'm missing something because a lot of addressing > > models sure allow for a huge number of unique addresses per host. > > > You can subnet it just like IPv4. Each host does not need it's own > subnet (/64, not /84 for the most part). > The theory behind /64 subnets was to support a way for a host to use > what it already knows (MAC > address) and possibly some additional clues (Router Announcement) from > the wire to configure > its own IPv6 address on an interface. Whether or not this was a good > idea is still controversial, but, > whether or not it's how IPv6 is going to work is not. IPv6 is > designed to work with Stateless > Autoconfiguration whether we like it or not. DHCPv6 so far is > prevented from providing > default router information (or many of the other things you're used to > having DHCP do) > as it currently stands. > > > > > My buddy and I are about to go to Barnes and Noble, not having and > > luck with standard internet media but then we realized... how will > > we know if any of that is really what we are looking for either? > > > It's a fair point. There is a good FAQ/Wiki on the ARIN web site. > That may be a good place to > start. > > >> From what I can tell, this may still be a question of great > >> debate. Everyone seems to act like they know exactly what's going > >> on but behind closed doors admits that they don't really know x, y, > >> or z. I realize this is typical of my industry and even myself > >> from time to time. J > > > > But so I am truly reaching out here. What is the deal with IPv6 > > addressing and subneting? Where is the official guide to this new > > galaxy? I will be sure to pass this information on to my equally > > less clueful peers to the benefit of all of us that are making this > > transition. > > > Officially, the best summary I can give is that the subnetting model > is almost identical to > IPv4, but, all subnets should be at least a /64 (and it's hard to > imagine a scenario where > a single subnet should be larger, but, it can be supported). > > The essential initial guidelines are: > > ISP /32 > Enough for 4billion ISPs > Enough for each ISP to support 65,536 /48 > customers or 16.7M /56 > customers, etc. > Larger ISPs can get more than a /32 if needed. > > End Site /48 > Enough for 65,536 /64 subnets > Larger organizations can get more than a /48 if > needed. > > Single Subnet > /64 > > Enough for more hosts that most of us can > imagine on a single subnet. > Support for 64 bit MAC addresses > Support for stateless autoconfiguration > > However, these guidelines can be violated in many circumstances to use > smaller > subnets if you really want to. I don't recommend it and there's > really no reason to > do so. > > Finally, if we're wrong about all of this, it's OK. We can renumber > people into > the other 7/8ths of the IPv6 space that are not yet issued for usage > by IANA > with an entirely different numbering scheme. > > > There are people here at my company that seem to get it but can't > > seem to explain it clearly to me. To me, its basically just larger > > addressing space with some new logical boundaries.... But there are > > so many discussions of potential addressing methods that I am > > confused. I know from my lab setups that I can "make it work" but > > I'd like to "do it right". J > > > Hope the above helps. > > > I've been doing this for over 10 years now... IPv4 is native to > > me. If you can point me in the direction of some good, > > authoritative information or even say "Dood, go get IPv6 for > > dummies", that's fine I just need to know where to find some good > > information. > > > Unfortunately, other than the guidelines above, most of us are still > experimenting > and don't have a lot of op-ex to build on. > > > Can someone say "well, you know how it would be nice to have like > > 100 different addresses on hosts to differentiate services and blah > > blah.... Well now that's what you account for and so then you know > > how a /24 almost always ends up being tight in IPv4? Right, so > > think of your basic bit boundaries that you adhere to as /?? > > And /??? In IPv6." Or "Throw all that old thought out the > > window. Now its kind of like how the Ford Probe is actually a > > Mazda... ummm.... Yeah I can't really explain it either but it > > makes sense. Here read this book and it'll make sense to you too." > > > Your basic bit boundary for a subnet really should be /64. You > certainly can put > as many IP addresses on a single host as you wish and there's no > reason not > to address services as you describe. There is no longer a concern > about the > tightness of the subnet since a /64 is the square of the total number > of hosts > that could be supported on the entire internet without > network/broadcast > overhead, etc. > > In IPv6, there really is no shortage of addresses and extremely little > likelihood > of that ever being a problem, even with the wasteful allocation > polices we > currently have in place. > > > Hope that helps, > > Owen > > (Speaking only as and for myself. This is not an official position or > recommendation > from the ARIN AC. I'm just trying to help.) From jbates at brightok.net Tue Feb 17 13:31:02 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 17 Feb 2009 13:31:02 -0600 Subject: anyone else seeing very long AS paths? In-Reply-To: <002101c99135$60a4d840$0a00000a@nil.si> References: <20090217150555.GB73561@puck.nether.net><499AD5E3.30806@deaddrop.org><200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net> <002101c99135$60a4d840$0a00000a@nil.si> Message-ID: <499B1076.7030404@brightok.net> Ivan Pepelnjak wrote: > Classic IOS (I did not test XE, XR or NX) can handle inbound updates with AS > path lengths above 255, but fails miserably when it has to send an oversized > update (producing invalid BGP UPDATE message), resulting in a flapping BGP > session (anyone who wants to test this behavior and report/fix this bug can > get all the files needed to reproduce it). Just to reconfirm. The issue arrives with sending an update, not receiving? So if an ISP does not have a limit and their IOS cannot handle this, they will send an invalid BGP UPDATE to the downstream peers causing them to reset regardless of their max as-path settings? Just trying to reconfirm, so I can inform my customers if there was anything they could do to prevent it, or if it is actually their provider that instigated the peer reset by sending invalid updates. -Jack From mike at rockynet.com Tue Feb 17 13:44:04 2009 From: mike at rockynet.com (Mike Lewinski) Date: Tue, 17 Feb 2009 12:44:04 -0700 Subject: anyone else seeing very long AS paths? In-Reply-To: <499B1076.7030404@brightok.net> References: <20090217150555.GB73561@puck.nether.net><499AD5E3.30806@deaddrop.org><200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net> <002101c99135$60a4d840$0a00000a@nil.si> <499B1076.7030404@brightok.net> Message-ID: <499B1384.8030201@rockynet.com> Jack Bates wrote: > Just to reconfirm. The issue arrives with sending an update, not > receiving? So if an ISP does not have a limit and their IOS cannot > handle this, they will send an invalid BGP UPDATE to the downstream > peers causing them to reset regardless of their max as-path settings? > > Just trying to reconfirm, so I can inform my customers if there was > anything they could do to prevent it, or if it is actually their > provider that instigated the peer reset by sending invalid updates. We were dropping ALL prefixes and the eBGP session was still resetting. I used this filter: ip prefix-list drop seq 1 deny 0.0.0.0/0 ge 32 router bgp neighbor x.x.x.x prefix-list drop in I confirmed via "show ip bgp sum" that there were 0 prefixes received. Of course "show ip bgp nei x.x.x.x received-routes" still showed the routes coming in, they just weren't being installed into the tables (or redistributed to any iBGP neighbors). So, to reiterate: 1) "bgp maxas-limit 75" had no effect mitigating this problem on the IOS we were using. That is: it was previously verified to be working just fine to drop paths longer than 75, but once we started receiving paths > 255 then BGP started resetting. 2) "prefix-list drop in" ensured that ALL eBGP learned routes were dropped before being installed or re-advertised. eBGP still reset itself every three minutes or so, which was about the length of time it took for the session to restore itself and get to the offending route. I believe that upgraded IOS is the ONLY possibly fix in some cases. From ip at ioshints.info Tue Feb 17 13:50:42 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 17 Feb 2009 20:50:42 +0100 Subject: anyone else seeing very long AS paths? In-Reply-To: <499B1076.7030404@brightok.net> References: <20090217150555.GB73561@puck.nether.net><499AD5E3.30806@deaddrop.org><200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net><002101c99135$60a4d840$0a00000a@nil.si> <499B1076.7030404@brightok.net> Message-ID: <005101c99139$055f60f0$0a00000a@nil.si> As far as I understand the issues :) There are two limits: the first one @ 128 AS numbers (where BGP switches to the 'extended length' of BGP attribute), the other one @ 256 AS numbers (where BGP has to use two AS_SEQUENCE segments). Old IOS releases break on the first boundary when processing INBOUND update. bgp maxas-limit cannot save you, as the router drops UPSTREAM BGP session before the update is fully processed. New IOS releases accept all INBOUND updates. Prefixes with AS-path length above 254 are never valid (the long printout contains maxas-limit status). bgp maxas-limit works on inbound updates and thus drops whatever you feel is oversized. New IOS release fail when sending OUTBOUND updates. If you've configured bgp maxas-limit, you're safe. If not, your DOWNSTREAM BGP session will be dropped by your neighbor receiving invalid BGP update. If your customers are using old IOS, there was nothing they could do to prevent the BGP session reset (apart from upgrading, obviously :). Who was the actual culprit depends on the AS-path length ... See above. Does this make sense? I know it's complex :) Ivan > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Tuesday, February 17, 2009 8:31 PM > To: Ivan Pepelnjak > Cc: nanog at nanog.org > Subject: Re: anyone else seeing very long AS paths? > > Ivan Pepelnjak wrote: > > Classic IOS (I did not test XE, XR or NX) can handle > inbound updates > > with AS path lengths above 255, but fails miserably when it has to > > send an oversized update (producing invalid BGP UPDATE message), > > resulting in a flapping BGP session (anyone who wants to test this > > behavior and report/fix this bug can get all the files > needed to reproduce it). > > Just to reconfirm. The issue arrives with sending an update, > not receiving? So if an ISP does not have a limit and their > IOS cannot handle this, they will send an invalid BGP UPDATE > to the downstream peers causing them to reset regardless of > their max as-path settings? > > Just trying to reconfirm, so I can inform my customers if > there was anything they could do to prevent it, or if it is > actually their provider that instigated the peer reset by > sending invalid updates. > > -Jack > > From owen at delong.com Tue Feb 17 13:48:49 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 17 Feb 2009 11:48:49 -0800 Subject: IPv6 Confusion In-Reply-To: <050701c99135$df0f0ed0$9d2d2c70$@net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > While people frequently claim that auto-config is optional, there are > implementations (including OS-X) that don't support anything else at > this > point. The basic message is that you should not assume that the host > implementations will conform to what the network operator would > prefer, and > you need to test. I can configure OS-X statically, so, that simply isn't true. What is true is that there are many implementations which do not (yet) support DHCPv6. That is not the same as "don't support anything else". > > > > One last comment (because I hear "just more bits" a lot in the *nog > community)... Approach IPv6 as a new and different protocol. If you > approach > it as "IPv4 with more bits", you will trip over the differences and be > pissed off. If you approach it as a "different protocol with a name > that > starts with IP" and runs alongside IPv4 (like we used to do with > decnet, > sna, appletalk...), you will be comforted in all the similarities. > You will > also hear lots of noise about 'lack of compatibility', which is just > another > instance of refusing to recognize that this is really a different > protocol. > At the end of the day, it is a packet based protocol that moves > payloads > around. > The problem here, IMHO, stems from the fact that unlike DECnet, Appletalk, SNA, et. al., IPv6 is intended as a replacement for IPv4. (None of the other protocols was ever intended to replace any of the others). As a replacement, the IETF realized that at the current scale of the internet when they began designing IPv6, a flag day conversion (like what happened when we went to IPv4) was not possible. Unfortunately, the migration plan set forth by the IETF made many assumptions (especially on vendor preparedness and rate of adoption prior to IPv4 runout) that have not proven out, so, the "Everyone who has IPv4 starts running dual-stack before we need any IPv6 only connectivity" plan is not going to prove out. More unfortunately, there is no real contingency plan for how migration happens absent that scenario and we are, therefore, in for some interesting times ahead. Owen From ip at ioshints.info Tue Feb 17 13:58:48 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 17 Feb 2009 20:58:48 +0100 Subject: anyone else seeing very long AS paths? In-Reply-To: <499B1384.8030201@rockynet.com> References: <20090217150555.GB73561@puck.nether.net><499AD5E3.30806@deaddrop.org><200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net> <002101c99135$60a4d840$0a00000a@nil.si><499B1076.7030404@brightok.net> <499B1384.8030201@rockynet.com> Message-ID: <005201c9913a$26a1d300$0a00000a@nil.si> > We were dropping ALL prefixes and the eBGP session was still > resetting. Upstream or downstream? > 1) "bgp maxas-limit 75" had no effect mitigating this problem > on the IOS we were using. That is: it was previously verified > to be working just fine to drop paths longer than 75, but > once we started receiving paths > > 255 then BGP started resetting. I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The paths were generated by Quagga BGP daemon. 12.2SRC causes the downstream session to break when the installed AS-path length is close to 255 and you use downstream AS-path prepending. In your case, I'm assuming you were hit with an older bug (probably at the 128 AS-path length boundary). It would be very hard to generate just the right AS-path length to unintentionally break your upstream EBGP session (as I said before, it's a nice targeted attack if you know your downstream topology). If your IOS is vulnerable to the older bugs that break inbound processing of AS paths longer than 128, there's nothing you can do on your end. The internal BGP checks reject the inbound update before the inbound filters (or bgp maxas-limit) can touch it and reset the upstream BGP session. Hope this helps Ivan Disclaimer: as I don't have internal access to Cisco, all of the above is a result of lab tests. From ssaner at hubris.net Tue Feb 17 14:05:35 2009 From: ssaner at hubris.net (Steven Saner) Date: Tue, 17 Feb 2009 14:05:35 -0600 Subject: anyone else seeing very long AS paths? In-Reply-To: <005101c99139$055f60f0$0a00000a@nil.si> References: <20090217150555.GB73561@puck.nether.net><499AD5E3.30806@deaddrop.org><200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net><002101c99135$60a4d840$0a00000a@nil.si> <499B1076.7030404@brightok.net> <005101c99139$055f60f0$0a00000a@nil.si> Message-ID: <73AD9E1F-4359-4879-BA6E-2E3A1723B584@hubris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 17, 2009, at 1:50 PM, Ivan Pepelnjak wrote: > As far as I understand the issues :) > > There are two limits: the first one @ 128 AS numbers (where BGP > switches to > the 'extended length' of BGP attribute), the other one @ 256 AS > numbers > (where BGP has to use two AS_SEQUENCE segments). > > Old IOS releases break on the first boundary when processing INBOUND > update. > bgp maxas-limit cannot save you, as the router drops UPSTREAM BGP > session > before the update is fully processed. > > New IOS releases accept all INBOUND updates. Prefixes with AS-path > length > above 254 are never valid (the long printout contains maxas-limit > status). > bgp maxas-limit works on inbound updates and thus drops whatever you > feel is > oversized. > > New IOS release fail when sending OUTBOUND updates. If you've > configured bgp > maxas-limit, you're safe. If not, your DOWNSTREAM BGP session will be > dropped by your neighbor receiving invalid BGP update. > > If your customers are using old IOS, there was nothing they could do > to > prevent the BGP session reset (apart from upgrading, obviously :). > Who was > the actual culprit depends on the AS-path length ... See above. > > Does this make sense? I know it's complex :) > Ivan What is not yet clear is, what are the definitions of "Old IOS release" and "New IOS release"? There has been talk of a bug referred to as CSCdr54230. I have seen statements on another list that this was fixed in 12.1(4) and 12.0(10)S3, but yet this problem was experienced on such releases as 12.2(40). Has there been any definitive word yet on what it takes to qualify as a new IOS release? Steve - -- - --------------------------------------------------------------- Steven Saner Director of Network Operations Hubris Communications -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmbGI8ACgkQvgCxUpg3pZOfgQCeOCnoDIwX/IMF+wfnM8md2SiM LSEAoIptOHmO7yPhAGdVZ8+dlhCiOI8k =WD0q -----END PGP SIGNATURE----- From gmartine at ajax.opentransit.net Tue Feb 17 14:16:55 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Tue, 17 Feb 2009 15:16:55 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <002101c99135$60a4d840$0a00000a@nil.si> References: <20090217185434.GA9548@ajax.opentransit.net> <002101c99135$60a4d840$0a00000a@nil.si> Message-ID: <20090217201655.GB11300@ajax.opentransit.net> On Tue Feb 17, 2009, Ivan Pepelnjak wrote: > According to publicly available bug toolkit, CSCee30718 did not touch the > maxas limit. I will double check this with Cisco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rodunn at cisco.com Tue Feb 17 14:11:57 2009 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 17 Feb 2009 15:11:57 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <005201c9913a$26a1d300$0a00000a@nil.si> References: <20090217185434.GA9548@ajax.opentransit.net> <499B1384.8030201@rockynet.com> <005201c9913a$26a1d300$0a00000a@nil.si> Message-ID: <20090217201157.GP17200@rtp-cse-489.cisco.com> Ivan, It is confusing but from what I have tested you have it correct. The confusing part comes from multiple issues. a) The documentation about the default maxas limit being 75 appears to be incorrect. I'll get that fixed. b) Prior to CSCee30718 there was a hard limit of 255. After that fix AS sets of more than 255 should work. c) CSCeh13489 implemented the maxas command to mark it as invalid and not send. There does appear to be an issue when you cross the 255 boundary and the next hop router sends a notification back. I've got it recreated in the lab and we are working to clearly understand why that is. I'll post an update once we have more. The way to prevent it is the upstream device that crosses the 255 boundary on sending needs to use the maxas limit command to keep it less than 255. It doesn't work on the device that receives the update with the AS path larger than 255. Rodney On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > We were dropping ALL prefixes and the eBGP session was still > > resetting. > > Upstream or downstream? > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > on the IOS we were using. That is: it was previously verified > > to be working just fine to drop paths longer than 75, but > > once we started receiving paths > > > 255 then BGP started resetting. > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The > paths were generated by Quagga BGP daemon. > > 12.2SRC causes the downstream session to break when the installed AS-path > length is close to 255 and you use downstream AS-path prepending. > > In your case, I'm assuming you were hit with an older bug (probably at the > 128 AS-path length boundary). It would be very hard to generate just the > right AS-path length to unintentionally break your upstream EBGP session (as > I said before, it's a nice targeted attack if you know your downstream > topology). > > If your IOS is vulnerable to the older bugs that break inbound processing of > AS paths longer than 128, there's nothing you can do on your end. The > internal BGP checks reject the inbound update before the inbound filters (or > bgp maxas-limit) can touch it and reset the upstream BGP session. > > Hope this helps > Ivan > > Disclaimer: as I don't have internal access to Cisco, all of the above is a > result of lab tests. > From drc at virtualized.org Tue Feb 17 14:20:19 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 17 Feb 2009 12:20:19 -0800 Subject: IPv6 Confusion In-Reply-To: <050701c99135$df0f0ed0$9d2d2c70$@net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > Approach IPv6 as a new and different protocol. Unfortunately, I gather this isn't what end users or network operators want or expect. I suspect if we want to make real inroads towards IPv6 deployment, we'll need to spend a bit more time making IPv6 look, taste, and feel like IPv4 and less time berating folks for "IPv4- think" (not that you do this, but others here do). For example, getting over the stateless autoconfig religion (which was never fully thought out -- how does a autoconfig'd device get a DNS name associated with their address in a DNSSEC-signed world again?) and letting network operators use DHCP with IPv6 the way they do with IPv4. Or, we simply continue down the path of more NATv4. Regards, -drc From fergdawgster at gmail.com Tue Feb 17 14:24:26 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 17 Feb 2009 12:24:26 -0800 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <6cd462c00902171224t1f5b4bcdkf39ace9cf9b5ced@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Feb 17, 2009 at 12:20 PM, David Conrad wrote: > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: >> >> Approach IPv6 as a new and different protocol. > > Unfortunately, I gather this isn't what end users or network operators > want or expect. I suspect if we want to make real inroads towards IPv6 > deployment, we'll need to spend a bit more time making IPv6 look, taste, > and feel like IPv4 and less time berating folks for "IPv4-think" (not > that you do this, but others here do). For example, getting over the > stateless > autoconfig religion (which was never fully thought out -- how does a > autoconfig'd device get a DNS name associated with their address in a > DNSSEC-signed world again?) and letting network operators use DHCP with > IPv6 the way they do with IPv4. > > Or, we simply continue down the path of more NATv4. > Isn't that the basis for the "Principle of Least Astonishment"? ;-) http://en.wikipedia.org/wiki/Principle_of_least_astonishment - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJmxzsq1pz9mNUZTMRAkNLAKDHw0tWUOKjnCOqcInCp5h+L1yG2gCg+TZ1 OC+4/th4rmLSMzpV1138rrk= =pKl5 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Feb 17 14:32:03 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 18 Feb 2009 07:02:03 +1030 Subject: IPv6 Confusion In-Reply-To: <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> Message-ID: <20090218070203.cecf99da.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Hi, On Tue, 17 Feb 2009 11:48:49 -0800 Owen DeLong wrote: > > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > > While people frequently claim that auto-config is optional, there are > > implementations (including OS-X) that don't support anything else at > > this > > point. The basic message is that you should not assume that the host > > implementations will conform to what the network operator would > > prefer, and > > you need to test. > > I can configure OS-X statically, so, that simply isn't true. > > What is true is that there are many implementations which do not (yet) > support DHCPv6. That is not the same as "don't support anything > else". > Here are a couple of implementations of DHCPv6, including one that also works under Windows. I played with one of them on my Linux boxes a while back (I can't remember exactly which one), and it just worked: https://fedorahosted.org/dhcpv6/ http://klub.com.pl/dhcpv6/ Regards, Mark. From nanog at daork.net Tue Feb 17 14:45:44 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 18 Feb 2009 09:45:44 +1300 Subject: IPv6 Confusion In-Reply-To: <20090218070203.cecf99da.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> <20090218070203.cecf99da.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <77915AC1-6B57-4B12-9A98-EB705DCAA4DC@daork.net> On 18/02/2009, at 9:32 AM, Mark Smith wrote: > Here are a couple of implementations of DHCPv6, including one that > also > works under Windows. I played with one of them on my Linux boxes a > while back (I can't remember exactly which one), and it just worked: > > https://fedorahosted.org/dhcpv6/ > > http://klub.com.pl/dhcpv6/ Installable implementations don't really count if this is something my mother has to use. Perhaps an ISP gives customers a little "enabler" app to run that installs a DHCPv6 client, but that sounds nasty. Flashbacks to AOL/compuserve install disks. SLAAC works out of the box right now for dual-stack hosts (ie. they can get DNS resolvers on v4). That is fine for the mean time, if you are planning to go IPv6-only to end hosts then things are going to get hard, stick with IPv4 NAT for now until OS X gets DHCPv6, and people have moved off XP and older OS X boxes. ...or, until we have another way of getting resolvers that has widespread adoption.. -- Nathan Ward From trejrco at gmail.com Tue Feb 17 14:49:08 2009 From: trejrco at gmail.com (TJ) Date: Tue, 17 Feb 2009 15:49:08 -0500 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <001501c99141$3028c5d0$907a5170$@com> >do this, but others here do). For example, getting over the stateless >autoconfig religion (which was never fully thought out -- how does a >autoconfig'd device get a DNS name associated with their address in a DNSSEC- >signed world again?) and letting network operators use DHCP with IPv6 the way >they do with IPv4. While I wouldn't call SLAAC a religion, I will say (again) that it works in many cases for some people, today - and whether you consider SLAAC "half-baked" or "slim-by-design" is a subjective matter. In the meantime, I am also a proponent for letting ops use DHCPv6 ... especially DHCPv6-PD! From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Feb 17 14:54:39 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 18 Feb 2009 07:24:39 +1030 Subject: IPv6 Confusion In-Reply-To: <6cd462c00902171224t1f5b4bcdkf39ace9cf9b5ced@mail.gmail.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <6cd462c00902171224t1f5b4bcdkf39ace9cf9b5ced@mail.gmail.com> Message-ID: <20090218072439.d2981cd8.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Tue, 17 Feb 2009 12:24:26 -0800 Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Feb 17, 2009 at 12:20 PM, David Conrad wrote: > > > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > >> > >> Approach IPv6 as a new and different protocol. > > > > Unfortunately, I gather this isn't what end users or network operators > > want or expect. I suspect if we want to make real inroads towards IPv6 > > deployment, we'll need to spend a bit more time making IPv6 look, taste, > > and feel like IPv4 and less time berating folks for "IPv4-think" (not > > that you do this, but others here do). For example, getting over the > > stateless > > autoconfig religion (which was never fully thought out -- how does a > > autoconfig'd device get a DNS name associated with their address in a > > DNSSEC-signed world again?) and letting network operators use DHCP with > > IPv6 the way they do with IPv4. > > > > Or, we simply continue down the path of more NATv4. > > > > Isn't that the basis for the "Principle of Least Astonishment"? ;-) > > http://en.wikipedia.org/wiki/Principle_of_least_astonishment > Alternatively, you can say, "if we're going to put effort into making these one or two changes (e.g. making IPv4 addresses bigger), is there an opportunity to make other improvements." Change always has a cost, so I think maximising the benefits from that cost, by considering additional changes at the same time, is of value. Some might say this is "second system syndrome." I think that only qualifies if you aren't ruthless in deciding which additional changes you make verses their additional costs vs benefits. The Internet's success isn't really attributable to IPv4, much like a road's success isn't really attributable to whether it is made of bitumen or concrete. The Internet's success is attributable to whom and to what it has and does provide connectivity to. IPv4 has been a good material to build the Internet from over the last 20 to 30 years, but there are limitations with it, and some other improvements, such as node autoconfiguration, proven useful in protocols mostly designed since IPv4 was, such as XNS, IPX, Appletalk and DECNET, can't be accomodated in it. I think IPv6 is similar enought to IPv4 that what you know about IPv4 can help you learn IPv6, but different enough that you shoudln't just consider IPv6 to be IPv4 with bigger addresses. Some principles and models are the same, some are similar, some are different. Anyway, that's the way I think about IPv6 vs IPv4. Regards, Mark. From jbates at brightok.net Tue Feb 17 15:25:56 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 17 Feb 2009 15:25:56 -0600 Subject: anyone else seeing very long AS paths? In-Reply-To: <73AD9E1F-4359-4879-BA6E-2E3A1723B584@hubris.net> References: <20090217150555.GB73561@puck.nether.net><499AD5E3.30806@deaddrop.org><200902171107.13032.mulitskiy@acedsl.com> <20090217185434.GA9548@ajax.opentransit.net><002101c99135$60a4d840$0a00000a@nil.si> <499B1076.7030404@brightok.net> <005101c99139$055f60f0$0a00000a@nil.si> <73AD9E1F-4359-4879-BA6E-2E3A1723B584@hubris.net> Message-ID: <499B2B64.9090407@brightok.net> Steven Saner wrote: > What is not yet clear is, what are the definitions of "Old IOS release" > and "New IOS release"? There has been talk of a bug referred to as > CSCdr54230. I have seen statements on another list that this was fixed > in 12.1(4) and 12.0(10)S3, but yet this problem was experienced on such > releases as 12.2(40). Has there been any definitive word yet on what it > takes to qualify as a new IOS release? I believe we are looking at multiple bugs with similar effects at different boundaries. Cisco, per earlier in the thread, will be having lots of coffee tonight. :) Jack From oberman at es.net Tue Feb 17 15:30:04 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 17 Feb 2009 13:30:04 -0800 Subject: IPv6 Confusion In-Reply-To: Your message of "Tue, 17 Feb 2009 11:48:49 PST." <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> Message-ID: <20090217213004.281A51CC09@ptavv.es.net> > From: Owen DeLong > Date: Tue, 17 Feb 2009 11:48:49 -0800 > > > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > > While people frequently claim that auto-config is optional, there are > > implementations (including OS-X) that don't support anything else at > > this > > point. The basic message is that you should not assume that the host > > implementations will conform to what the network operator would > > prefer, and > > you need to test. > > I can configure OS-X statically, so, that simply isn't true. > > What is true is that there are many implementations which do not (yet) > support DHCPv6. That is not the same as "don't support anything > else". > > > > > > > > > One last comment (because I hear "just more bits" a lot in the *nog > > community)... Approach IPv6 as a new and different protocol. If you > > approach > > it as "IPv4 with more bits", you will trip over the differences and be > > pissed off. If you approach it as a "different protocol with a name > > that > > starts with IP" and runs alongside IPv4 (like we used to do with > > decnet, > > sna, appletalk...), you will be comforted in all the similarities. > > You will > > also hear lots of noise about 'lack of compatibility', which is just > > another > > instance of refusing to recognize that this is really a different > > protocol. > > At the end of the day, it is a packet based protocol that moves > > payloads > > around. > > > The problem here, IMHO, stems from the fact that unlike DECnet, > Appletalk, SNA, et. al., IPv6 is intended as a replacement for > IPv4. (None of the other protocols was ever intended to replace > any of the others). > > As a replacement, the IETF realized that at the current scale of the > internet when they began designing IPv6, a flag day conversion > (like what happened when we went to IPv4) was not possible. > Unfortunately, the migration plan set forth by the IETF made many > assumptions (especially on vendor preparedness and rate of > adoption prior to IPv4 runout) that have not proven out, so, the > "Everyone who has IPv4 starts running dual-stack before we > need any IPv6 only connectivity" plan is not going to prove out. > > More unfortunately, there is no real contingency plan for how > migration happens absent that scenario and we are, therefore, > in for some interesting times ahead. While this is very true, at least the IETF has recognized the problem and the BEHAVE WG is trying to come up with some way of getting out of the trap we have worked our way into. The big iron folks are proposing something called "Carrier Grade NAT". This one REALLY frightens me, but I understand a couple of hardware manufacturers are planning on building such a monster. It might actually work, but the amount of state carried strikes me as in invitation to disaster. There was a draft on CNG, but it expired last month. A copy is still available at: http://smakd.potaroo.net/ietf/all-ids/draft-nishitani-cgn-00.txt Also, a proposal for a different approach is at: http://mice.cs.columbia.edu/getTechreport.php?techreportID=560 (PDF) If you are really concerned about where we go whan v4 address space is exhausted, I strongly urge you to look at all of these issues. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From nanog at daork.net Tue Feb 17 15:05:08 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 18 Feb 2009 10:05:08 +1300 Subject: IPv6 Confusion In-Reply-To: <050701c99135$df0f0ed0$9d2d2c70$@net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: On 18/02/2009, at 8:28 AM, Tony Hain wrote: > One last comment (because I hear "just more bits" a lot in the *nog > community)... Approach IPv6 as a new and different protocol. If you > approach > it as "IPv4 with more bits", you will trip over the differences and be > pissed off. If you approach it as a "different protocol with a name > that > starts with IP" and runs alongside IPv4 (like we used to do with > decnet, > sna, appletalk...), you will be comforted in all the similarities. > You will > also hear lots of noise about 'lack of compatibility', which is just > another > instance of refusing to recognize that this is really a different > protocol. > At the end of the day, it is a packet based protocol that moves > payloads > around. Having taught a bunch of IPv6 courses opening with a photo of Gaurab and his "96 more bits, no magic" tshirt and then having dealt with the confusion once we get in to the nitty gritty details, I am inclined to agree with you here. The intention of these sorts of statements is to remove the "I will have to learn IP all over again" fear (and the associated "it's too hard" etc.), but you are right, this has been causing people to get a bit surprised when stuff does not work the same as IPv4. I suppose it is fair to say that in the core of the network, it is essentially 96 more bits, and no magic. The access network is where this becomes a bit of a confusing statement. Anyway, comments taken on board, I'll have a think about how to do this differently. -- Nathan Ward From nanog-post at rsuc.gweep.net Tue Feb 17 16:02:07 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 17 Feb 2009 17:02:07 -0500 Subject: IPv6 Confusion In-Reply-To: <050701c99135$df0f0ed0$9d2d2c70$@net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <20090217220207.GA4051@gweep.net> On Tue, Feb 17, 2009 at 11:28:11AM -0800, Tony Hain wrote: [snip] > starts with IP" and runs alongside IPv4 (like we used to do with decnet, > sna, appletalk...), you will be comforted in all the similarities. You will This is highly amusing, as for myself and many folks the experience of these 'other protocols', when trying to run in open, scalable, and commercially-viable deployments, was to encapsulate in IP(v4) at the LAN/WAN boundary. It is no wonder that is the natural reaction to IPv6 by those who have survived and been successful with such operational simplicity. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From leland at taranta.discpro.org Tue Feb 17 16:06:40 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Tue, 17 Feb 2009 22:06:40 +0000 (GMT) Subject: anyone else seeing very long AS paths? In-Reply-To: <499B09DA.9090100@rockynet.com> Message-ID: On Tue, 17 Feb 2009, Mike Lewinski wrote: > German Martinez wrote: > bgp max-as will NOT protect you from this exploit (but if you are not > vulnerable it should prevent you from propogating it). > I can confirm this statement... (unfortunately) L. From alh-ietf at tndh.net Tue Feb 17 16:14:57 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 17 Feb 2009 14:14:57 -0800 Subject: IPv6 Confusion In-Reply-To: <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> Message-ID: <056701c9914d$2ae28f50$80a7adf0$@net> Owen DeLong wrote: > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > > While people frequently claim that auto-config is optional, there are > > implementations (including OS-X) that don't support anything else at > > this > > point. The basic message is that you should not assume that the host > > implementations will conform to what the network operator would > > prefer, and > > you need to test. > > I can configure OS-X statically, so, that simply isn't true. > > What is true is that there are many implementations which do not (yet) > support DHCPv6. That is not the same as "don't support anything > else". Fair enough about OS-X, but that is not the only non-dhcpv6 implementation out there. How exactly do you configure a static address on a sensor with no UI? My point was 'don't assume', & test. > > > > > > > > > One last comment (because I hear "just more bits" a lot in the *nog > > community)... Approach IPv6 as a new and different protocol. If you > > approach > > it as "IPv4 with more bits", you will trip over the differences and > be > > pissed off. If you approach it as a "different protocol with a name > > that > > starts with IP" and runs alongside IPv4 (like we used to do with > > decnet, > > sna, appletalk...), you will be comforted in all the similarities. > > You will > > also hear lots of noise about 'lack of compatibility', which is just > > another > > instance of refusing to recognize that this is really a different > > protocol. > > At the end of the day, it is a packet based protocol that moves > > payloads > > around. > > > The problem here, IMHO, stems from the fact that unlike DECnet, > Appletalk, SNA, et. al., IPv6 is intended as a replacement for > IPv4. (None of the other protocols was ever intended to replace > any of the others). > > As a replacement, the IETF realized that at the current scale of the > internet when they began designing IPv6, a flag day conversion > (like what happened when we went to IPv4) was not possible. > Unfortunately, the migration plan set forth by the IETF made many > assumptions (especially on vendor preparedness and rate of > adoption prior to IPv4 runout) that have not proven out, so, the > "Everyone who has IPv4 starts running dual-stack before we > need any IPv6 only connectivity" plan is not going to prove out. > > More unfortunately, there is no real contingency plan for how > migration happens absent that scenario and we are, therefore, > in for some interesting times ahead. Whine, whine, whine... we are where we are, and no amount of whining will change the fact that people outside of Japan chose not to think ahead. The primary point of dual-stack was to decouple the requirement for the end systems to change all the apps at once. Most of the *nog community doesn't get, or care to get, the costs of the end system operations staff because they are focused on the costs related to moving the bits around. There are tunneling functions defined, so you don't have to get 'dual-stack everywhere' before you can take another step. Those are not as 'efficient' as dual-stack when moving the bits around, and require operational management, but that is a cost trade-off that can be made. People that insist on delivering only one version will force unnatural acts at the edge, while delivering both will allow people to move at their own pace. Like it or not, the end systems are moving without the *nog community. Fire up uTorrent and see how many 6to4 & teredo connected peers you end up with (I am generally seeing about 1/4-1/3 of the set). This is 'real dual-stack at the edge', and works around the laggard ISP deployments. The Internet was built by tunneling over the laggard telco's using the voice technology available, and the next generation of it will be built the same way if the *nog community buries its head in the same dark place that the telco's did. Tony From alh-ietf at tndh.net Tue Feb 17 16:17:13 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 17 Feb 2009 14:17:13 -0800 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <056801c9914d$7c2a0e10$747e2a30$@net> David Conrad wrote: > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > Approach IPv6 as a new and different protocol. > > Unfortunately, I gather this isn't what end users or network operators > want or expect. I suspect if we want to make real inroads towards > IPv6 deployment, we'll need to spend a bit more time making IPv6 look, > taste, and feel like IPv4 and less time berating folks for "IPv4- > think" (not that you do this, but others here do). I am not trying to berate anyone, just point out that your starting perspective will impact how you see the differences. From what I have seen, people are generally happy when they find similarities, and pissed off when the find differences. Therefore, if you start by assuming it is different, you will be much happier. > For example, > getting over the stateless autoconfig religion (which was never fully > thought out -- how does a autoconfig'd device get a DNS name > associated with their address in a DNSSEC-signed world again?) and > letting network operators use DHCP with IPv6 the way they do with IPv4. There are many religious positions here, and none are any more valid than the others. At the end of the day, each approach needs to be complete and stand-alone, but due to religious fighting, all approaches are required to exist at once for anything to work. This being a list of network engineers, there is a strong bias toward tools that allow explicit management of the network. This is a fine position, and those tools need to exist. There are others that don't want, or need to know about every bit on the wire, where 'as much automation as possible' is the right set of tools. Infighting at the IETF kept the RA from informing the end systems about DNS, and kept DHCPv6 from informing them about their router. The result is that you have to do both DHCP & RA, when each should be capable of working without the other. As far as dnssec, while the question is valid, blaming the IPv6 design for not considering something that 10+ years later is still not deployed/deployable, is a bit of a stretch. This all comes down to trust anchors, and personally I question the wisdom of anyone that considers DHCP to be a valid trust anchor. It gets that status because it is something tangible that is reasonably well understood, but there is nothing in its design, or the way that it is deployed in practice that makes it worthy of anything related to trust. An out-of-band trust cert between an auto-configured end system and a ddns service makes much more sense than a DHCP service based on believing that the end system will not bother to spoof its mac address. > > Or, we simply continue down the path of more NATv4. While this is the popular position, those that have thought about it realize that what works for natv4 at the edge, does not work when that nat is moved toward the core. If people really go down this path, the end applications will do even more levels of tunneling over the few things that work, and the network operators will lose all visibility into what is really going on (IPv6 tunnel servers are just the modern modem pools, and tunneling over http will become more common if that is the only path that works). Tony From gmartine at ajax.opentransit.net Tue Feb 17 16:31:49 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Tue, 17 Feb 2009 17:31:49 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <20090217201157.GP17200@rtp-cse-489.cisco.com> References: <20090217185434.GA9548@ajax.opentransit.net> <499B1384.8030201@rockynet.com> <005201c9913a$26a1d300$0a00000a@nil.si> <20090217201157.GP17200@rtp-cse-489.cisco.com> Message-ID: <20090217223149.GB11589@ajax.opentransit.net> On Tue Feb 17, 2009, Rodney Dunn wrote: Hello Rodney, It will be great if you can share with us your findings. It seems like we are hitting different bugs in different platforms. Thanks German > Ivan, > > It is confusing but from what I have tested you have it correct. > > The confusing part comes from multiple issues. > > a) The documentation about the default maxas limit being 75 appears to be > incorrect. I'll get that fixed. > > b) Prior to CSCee30718 there was a hard limit of 255. After that fix > AS sets of more than 255 should work. > > c) CSCeh13489 implemented the maxas command to mark it as invalid and > not send. > > > There does appear to be an issue when you cross the 255 boundary > and the next hop router sends a notification back. > > I've got it recreated in the lab and we are working to clearly understand > why that is. I'll post an update once we have more. > > The way to prevent it is the upstream device that crosses the 255 boundary > on sending needs to use the maxas limit command to keep it less than 255. > > It doesn't work on the device that receives the update with the AS path > larger than 255. > > Rodney > > On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > > We were dropping ALL prefixes and the eBGP session was still > > > resetting. > > > > Upstream or downstream? > > > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > > on the IOS we were using. That is: it was previously verified > > > to be working just fine to drop paths longer than 75, but > > > once we started receiving paths > > > > 255 then BGP started resetting. > > > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The > > paths were generated by Quagga BGP daemon. > > > > 12.2SRC causes the downstream session to break when the installed AS-path > > length is close to 255 and you use downstream AS-path prepending. > > > > In your case, I'm assuming you were hit with an older bug (probably at the > > 128 AS-path length boundary). It would be very hard to generate just the > > right AS-path length to unintentionally break your upstream EBGP session (as > > I said before, it's a nice targeted attack if you know your downstream > > topology). > > > > If your IOS is vulnerable to the older bugs that break inbound processing of > > AS paths longer than 128, there's nothing you can do on your end. The > > internal BGP checks reject the inbound update before the inbound filters (or > > bgp maxas-limit) can touch it and reset the upstream BGP session. > > > > Hope this helps > > Ivan > > > > Disclaimer: as I don't have internal access to Cisco, all of the above is a > > result of lab tests. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rodunn at cisco.com Tue Feb 17 16:27:01 2009 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 17 Feb 2009 17:27:01 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <20090217223149.GB11589@ajax.opentransit.net> References: <20090217185434.GA9548@ajax.opentransit.net> <499B1384.8030201@rockynet.com> <005201c9913a$26a1d300$0a00000a@nil.si> <20090217201157.GP17200@rtp-cse-489.cisco.com> <20090217223149.GB11589@ajax.opentransit.net> Message-ID: <20090217222701.GL21284@rtp-cse-489.cisco.com> If you want to take this offline send it unicast or we could move it to cisco-nsp. What scenarios are you seeing that appear broken other than when a notification is sent when a > 255 hop update is received? That's the one I'm working on right now. Rodney On Tue, Feb 17, 2009 at 05:31:49PM -0500, German Martinez wrote: > On Tue Feb 17, 2009, Rodney Dunn wrote: > > Hello Rodney, > It will be great if you can share with us your findings. It seems > like we are hitting different bugs in different platforms. > > Thanks > German > > > Ivan, > > > > It is confusing but from what I have tested you have it correct. > > > > The confusing part comes from multiple issues. > > > > a) The documentation about the default maxas limit being 75 appears to be > > incorrect. I'll get that fixed. > > > > b) Prior to CSCee30718 there was a hard limit of 255. After that fix > > AS sets of more than 255 should work. > > > > c) CSCeh13489 implemented the maxas command to mark it as invalid and > > not send. > > > > > > There does appear to be an issue when you cross the 255 boundary > > and the next hop router sends a notification back. > > > > I've got it recreated in the lab and we are working to clearly understand > > why that is. I'll post an update once we have more. > > > > The way to prevent it is the upstream device that crosses the 255 boundary > > on sending needs to use the maxas limit command to keep it less than 255. > > > > It doesn't work on the device that receives the update with the AS path > > larger than 255. > > > > Rodney > > > > On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > > > We were dropping ALL prefixes and the eBGP session was still > > > > resetting. > > > > > > Upstream or downstream? > > > > > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > > > on the IOS we were using. That is: it was previously verified > > > > to be working just fine to drop paths longer than 75, but > > > > once we started receiving paths > > > > > 255 then BGP started resetting. > > > > > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The > > > paths were generated by Quagga BGP daemon. > > > > > > 12.2SRC causes the downstream session to break when the installed AS-path > > > length is close to 255 and you use downstream AS-path prepending. > > > > > > In your case, I'm assuming you were hit with an older bug (probably at the > > > 128 AS-path length boundary). It would be very hard to generate just the > > > right AS-path length to unintentionally break your upstream EBGP session (as > > > I said before, it's a nice targeted attack if you know your downstream > > > topology). > > > > > > If your IOS is vulnerable to the older bugs that break inbound processing of > > > AS paths longer than 128, there's nothing you can do on your end. The > > > internal BGP checks reject the inbound update before the inbound filters (or > > > bgp maxas-limit) can touch it and reset the upstream BGP session. > > > > > > Hope this helps > > > Ivan > > > > > > Disclaimer: as I don't have internal access to Cisco, all of the above is a > > > result of lab tests. > > > From alh-ietf at tndh.net Tue Feb 17 17:50:34 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 17 Feb 2009 15:50:34 -0800 Subject: IPv6 Confusion In-Reply-To: <20090217220207.GA4051@gweep.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <20090217220207.GA4051@gweep.net> Message-ID: <059401c9915a$867d69e0$93783da0$@net> Joe Provo wrote: > This is highly amusing, as for myself and many folks the experience > of these 'other protocols', when trying to run in open, scalable, > and commercially-viable deployments, was to encapsulate in IP(v4) > at the LAN/WAN boundary. It is no wonder that is the natural reaction > to IPv6 by those who have survived and been successful with such > operational simplicity. There is nothing preventing you from doing the same thing again, ... except oh yea, lack of addresses and the bloating routing table as ever smaller address blocks are traded on eBay. Seriously, you could easily do the same thing by encapsulating IPv4 over IPv6. One might even consider using one /64 for internal IPv4 routes (embedding the IPv4 as the next 32 bits), then another /64 for each IPv4 peer, to reduce the number of IPv6 routes you need to carry everywhere. At the edges where it matters there would be a /96 routing entry, but even if all of the /96 prefixes were enumerated everywhere the table would be the same size as the IPv4 one would have been. Tony From Mark_Andrews at isc.org Tue Feb 17 17:55:30 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 18 Feb 2009 10:55:30 +1100 Subject: IPv6 Confusion In-Reply-To: Your message of "Tue, 17 Feb 2009 12:20:19 -0800." Message-ID: <200902172355.n1HNtUGZ002737@drugs.dv.isc.org> In message , David Conrad writes: > On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: > > Approach IPv6 as a new and different protocol. > > Unfortunately, I gather this isn't what end users or network operators > want or expect. I suspect if we want to make real inroads towards > IPv6 deployment, we'll need to spend a bit more time making IPv6 look, > taste, and feel like IPv4 and less time berating folks for "IPv4- > think" (not that you do this, but others here do). For example, > getting over the stateless autoconfig religion (which was never fully > thought out -- how does a autoconfig'd device get a DNS name > associated with their address in a DNSSEC-signed world again?) and > letting network operators use DHCP with IPv6 the way they do with IPv4. David you know as well as I do that DNSSEC is a orthognal issue here. The first issue is how do you assign a name to a object? The second issue is how do you add that name to the DNS? The third issue is how do you sign that change? I solve it by give the machine a name. Adding a KEY record at that name to the DNS, the private part the machine knows. I then use SIG(0) to update the address records of the machine whenever the addresses change. The DNS server that accepts that update generated new RRSIGs for the records affected by that change and the zone propogates out to the servers using NOTIFY. I update the reverse PTR records using tcp-self as the authentication mechanism. tcp-self is weak but is strong enough for the level of trust assigned to PTR records. Again the DNS server generates appropriate signatures. The machine's name is not tied to the network on which it lives. Mark > Or, we simply continue down the path of more NATv4. > > Regards, > -drc > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From randy at psg.com Tue Feb 17 18:03:10 2009 From: randy at psg.com (Randy Bush) Date: Wed, 18 Feb 2009 09:03:10 +0900 Subject: IPv6 Confusion In-Reply-To: <050701c99135$df0f0ed0$9d2d2c70$@net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: At Tue, 17 Feb 2009 11:28:11 -0800, Tony Hain wrote: > > While people frequently claim that auto-config is optional, there are > implementations (including OS-X) that don't support anything else at this > point. The basic message is that you should not assume that the host > implementations will conform to what the network operator would prefer s/network operator would prefer/specifications/ > One last comment (because I hear "just more bits" a lot in the *nog > community)... Approach IPv6 as a new and different protocol. If you approach > it as "IPv4 with more bits", you will trip over the differences and be > pissed off. If you approach it as a "different protocol with a name that > starts with IP" and runs alongside IPv4 (like we used to do with decnet, > sna, appletalk...), you will be comforted in all the similarities. You will > also hear lots of noise about 'lack of compatibility', which is just another > instance of refusing to recognize that this is really a different protocol. > At the end of the day, it is a packet based protocol that moves payloads > around. unfortunately, this view leads to two internets, and one not reachable from the other. this is not very realistic from the business and user point of view. randy From randy at psg.com Tue Feb 17 18:05:25 2009 From: randy at psg.com (Randy Bush) Date: Wed, 18 Feb 2009 09:05:25 +0900 Subject: IPv6 Confusion In-Reply-To: <20090217213004.281A51CC09@ptavv.es.net> References: <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> <20090217213004.281A51CC09@ptavv.es.net> Message-ID: > Also, a proposal for a different approach is at: > http://mice.cs.columbia.edu/getTechreport.php?techreportID=560 (PDF) which has an internet draft, draft-ymbk-aplusp-02.txt randy From Valdis.Kletnieks at vt.edu Tue Feb 17 18:42:15 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 17 Feb 2009 19:42:15 -0500 Subject: IPv6 Confusion In-Reply-To: Your message of "Wed, 18 Feb 2009 10:55:30 +1100." <200902172355.n1HNtUGZ002737@drugs.dv.isc.org> References: <200902172355.n1HNtUGZ002737@drugs.dv.isc.org> Message-ID: <14076.1234917735@turing-police.cc.vt.edu> On Wed, 18 Feb 2009 10:55:30 +1100, Mark Andrews said: > I solve it by give the machine a name. Adding a KEY record > at that name to the DNS, the private part the machine knows. I think the issue is that the machine in question may not know its own hostname to start, much less that dnssec is in use, or that a private key is supposed to be remembered on the machine. So there's a bit of a bootstrapping problem there. Of course, you can skip over that issue by letting the DHCP server do the DNS updates as a proxy for the just-DHCP'ed machine, but that has other issues... (or just pre-populate the DNS with DHCP-2001-9A98-D247-{5more}.ISP.com and be done with it like many places do for IPv4) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From drc at virtualized.org Tue Feb 17 19:20:39 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 17 Feb 2009 15:20:39 -1000 Subject: IPv6 Confusion In-Reply-To: <200902172355.n1HNtUGZ002737@drugs.dv.isc.org> References: <200902172355.n1HNtUGZ002737@drugs.dv.isc.org> Message-ID: <33415E7E-23F2-45F2-9281-AB1685DEE4CE@virtualized.org> On Feb 17, 2009, at 1:55 PM, Mark Andrews wrote: >> (which was never fully >> thought out -- how does a autoconfig'd device get a DNS name >> associated with their address in a DNSSEC-signed world again?) and >> letting network operators use DHCP with IPv6 the way they do with >> IPv4. > David you know as well as I do that DNSSEC is a orthognal > issue here. My understanding, which may well be wrong, is that: - stateless auto-configuration assumes the client will update the address to name association once it has obtained the address. - In order to do this, the DNS server needs to support Dynamic DNS. - If DNSSEC is in use, it requires the use of on-line signing keys. - Security folks get unhappy when you mention on-line signing keys. Solution? - Don't have address to name associations - Don't worry about (or accept lesser) security on address to name associations. Of course the DNSSEC bit is sort of moot, as I suspect there aren't a whole lot of ISPs in a position to support dynamic updates from clients... Regards, -drc From Mark_Andrews at isc.org Tue Feb 17 19:21:25 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 18 Feb 2009 12:21:25 +1100 Subject: IPv6 Confusion In-Reply-To: Your message of "Tue, 17 Feb 2009 19:42:15 CDT." <14076.1234917735@turing-police.cc.vt.edu> Message-ID: <200902180121.n1I1LPYA004860@drugs.dv.isc.org> In message <14076.1234917735 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1234917735_3892P > Content-Type: text/plain; charset=us-ascii > > On Wed, 18 Feb 2009 10:55:30 +1100, Mark Andrews said: > > I solve it by give the machine a name. Adding a KEY record > > at that name to the DNS, the private part the machine knows. > > I think the issue is that the machine in question may not know its own hostna > me > to start, much less that dnssec is in use, or that a private key is supposed > to > be remembered on the machine. So there's a bit of a bootstrapping problem > there. There are lots of bootstrap issues. > Of course, you can skip over that issue by letting the DHCP server do > the DNS updates as a proxy for the just-DHCP'ed machine, but that has > other issues... Indeeded. > (or just pre-populate the DNS with DHCP-2001-9A98-D247-{5more}.ISP.com and be > done with it like many places do for IPv4) Which still leaves the problem of how does the machine get its name in a trusted manner. > --==_Exmh_1234917735_3892P > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Exmh version 2.5 07/13/2001 > > iD8DBQFJm1lncC3lWbTT17ARAm8iAKCbx6hoYDgRqHMk5JyG0uKIt0Ki1ACgz7ij > z3amg/2yC8HtcnFbg03Bmw4= > =TqDw > -----END PGP SIGNATURE----- > > --==_Exmh_1234917735_3892P-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Mark_Andrews at isc.org Tue Feb 17 19:55:53 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 18 Feb 2009 12:55:53 +1100 Subject: IPv6 Confusion In-Reply-To: Your message of "Tue, 17 Feb 2009 15:20:39 -1000." <33415E7E-23F2-45F2-9281-AB1685DEE4CE@virtualized.org> Message-ID: <200902180155.n1I1tr1e005174@drugs.dv.isc.org> In message <33415E7E-23F2-45F2-9281-AB1685DEE4CE at virtualized.org>, David Conrad writes: > > On Feb 17, 2009, at 1:55 PM, Mark Andrews wrote: > >> (which was never fully > >> thought out -- how does a autoconfig'd device get a DNS name > >> associated with their address in a DNSSEC-signed world again?) and > >> letting network operators use DHCP with IPv6 the way they do with > >> IPv4. > > David you know as well as I do that DNSSEC is a orthognal > > issue here. > > My understanding, which may well be wrong, is that: > > - stateless auto-configuration assumes the client will update the > address to name association once it has obtained the address. > - In order to do this, the DNS server needs to support Dynamic DNS. > - If DNSSEC is in use, it requires the use of on-line signing keys. > - Security folks get unhappy when you mention on-line signing keys. Security is about managing risk not eleminating all risks as that is a unobtainable goal. Security folks that don't understand that don't understand their jobs. > Solution? > > - Don't have address to name associations > - Don't worry about (or accept lesser) security on address to name > associations. DNSSEC is design to work with off-line signing if that is the security level you require. It doesn't however require off-line signing. A HSM which just prevents access to the private key is more than enough for most deployment senarios. > Of course the DNSSEC bit is sort of moot, as I suspect there aren't a > whole lot of ISPs in a position to support dynamic updates from > clients... Actually I suspect they are all in a position to do so as the software to do this was deployed by the major vendors last century. What it takes is for them to move from the arcane dialup model where there was not point in doing this to the semi-static model where there is a point in letting the leasees have the ability to record the names of their machines in the DNS. In otherwords ISP's need to enter the 21st century. Mark > Regards, > -drc > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From stevel at dedicatedservers.net.au Tue Feb 17 20:04:59 2009 From: stevel at dedicatedservers.net.au (Steven Lisson) Date: Wed, 18 Feb 2009 12:04:59 +1000 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: Hi, I find it a shame that NAT-PT has become depreciated, with people talking about carrier grade NATS I think combining these with NAT-PT could help with the transition after we run out of IPv4 space. ISP gets a chunk of IPv6 address space, sets up customers with it, gets their big lovely carrier grade NAT device that NAT's from customers IPv6 address to whatever IPv4 service they need. I'm probably missing something but does this not seem like a good option? Why not use IPv6 instead of private IPv4, end user gets end-to-end connectivity with anything that is IPv6 enabled while still being able to access the legacy IPv4 network. Also see it of long term benefit to ISP's as will first have to get big expensive equipment for CGN, but over time they won't have the big expensive of continuously upgrading these units as IPv4 dwindles Just my 2c Steve -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Wednesday, 18 February 2009 10:03 AM To: Tony Hain Cc: 'Carl Rosevear'; nanog at nanog.org Subject: Re: IPv6 Confusion At Tue, 17 Feb 2009 11:28:11 -0800, Tony Hain wrote: > > While people frequently claim that auto-config is optional, there are > implementations (including OS-X) that don't support anything else at this > point. The basic message is that you should not assume that the host > implementations will conform to what the network operator would prefer s/network operator would prefer/specifications/ > One last comment (because I hear "just more bits" a lot in the *nog > community)... Approach IPv6 as a new and different protocol. If you approach > it as "IPv4 with more bits", you will trip over the differences and be > pissed off. If you approach it as a "different protocol with a name that > starts with IP" and runs alongside IPv4 (like we used to do with decnet, > sna, appletalk...), you will be comforted in all the similarities. You will > also hear lots of noise about 'lack of compatibility', which is just another > instance of refusing to recognize that this is really a different protocol. > At the end of the day, it is a packet based protocol that moves payloads > around. unfortunately, this view leads to two internets, and one not reachable from the other. this is not very realistic from the business and user point of view. randy From leen at consolejunkie.net Tue Feb 17 20:19:10 2009 From: leen at consolejunkie.net (Leen Besselink) Date: Wed, 18 Feb 2009 03:19:10 +0100 Subject: IPv6 Confusion In-Reply-To: <200902180121.n1I1LPYA004860@drugs.dv.isc.org> References: <200902180121.n1I1LPYA004860@drugs.dv.isc.org> Message-ID: <499B701E.7060005@consolejunkie.net> Mark Andrews wrote: >> >> (or just pre-populate the DNS with DHCP-2001-9A98-D247-{5more}.ISP.com and be >> >> done with it like many places do for IPv4) > > > > Which still leaves the problem of how does the machine get its > > name in a trusted manner. > > I don't know about that, but I do have an idea about how you could atleast have a start to verify the things you receive. Tell me if I'm stupid and need more sleep. And yes I didn't check, but I don't think anyone created a protocol for this yet. It's just some things that came to mind. Let's see... For a start, you might want to be able to validate through DNSSEC the PTR-records of the global-addresses you receive 'from the network'. Let's say you have a few /64 (global, fe80:: and possible also ULA) on the network, you autoconfigure an address with SLAAC, you get information about a gateway and a recursive nameserver (yes maybe from DHCPv6, doesn't really matter for this discussion). The host with the newly aquired address(es) has a forwarding DNSSEC-validating recursor on localhost with the public key for the root. Which asks the recursive nameserver on the network for all the DNSSEC-records it needs from the root down to verify any PTR-record about the global-addresses it received like gateway or that recursive nameserver. This means you can use the recursive nameserver on the network, without trusting it (at first ?), you are just using it as a cache. After that you can check the AAAA-record for the name you got from the PTR to see if they all match up (like HELO/MX/PTR-records for mailservers). If everything checks out ok, then you know everything is controlled by the same organisaion(s) and that they are legit. If you have that information you could use it to get other key-material from DNS, maybe even opportunistic IPSec-keys, so you can start encrypting all communications. I do know I don't like the complexity of DNSSEC, but if we do get it to work, maybe something like this could actually work (atleast in theory). I'm going to have a good night's sleep now, although I'll probably kick myself in the morning for mentioning something stupid. I keep wondering which we'll implement first, DNSSEC or IPv6. My guess is on IPv6, because of the implementation complexity of DNSSEC. PS I'm not a native english speaker From randy at psg.com Tue Feb 17 20:23:37 2009 From: randy at psg.com (Randy Bush) Date: Wed, 18 Feb 2009 11:23:37 +0900 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: > I find it a shame that NAT-PT has become depreciated the ietf has recanted and is hurriedly trying to get this back on track. of course, to save face, the name has to be changed. > with people talking about carrier grade NATS I think combining > these with NAT-PT could help with the transition cgn is not a transition tool. it is a dangerous hack to deal with the problems of a few very large consumer isps who lack sufficient space to number their customer edge. randy From brandon.galbraith at gmail.com Tue Feb 17 20:27:44 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 17 Feb 2009 20:27:44 -0600 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> On 2/17/09, Randy Bush wrote: > > > I find it a shame that NAT-PT has become depreciated > > the ietf has recanted and is hurriedly trying to get this back on > track. of course, to save face, the name has to be changed. > > > with people talking about carrier grade NATS I think combining > > these with NAT-PT could help with the transition > > cgn is not a transition tool. it is a dangerous hack to deal with > the problems of a few very large consumer isps who lack sufficient > space to number their customer edge. > > randy > > Sounds like those consumer ISPs better get started on rolling out dual stacks to the CPE. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From randy at psg.com Tue Feb 17 20:45:33 2009 From: randy at psg.com (Randy Bush) Date: Wed, 18 Feb 2009 11:45:33 +0900 Subject: IPv6 Confusion In-Reply-To: <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> Message-ID: > cgn is not a transition tool. it is a dangerous hack to deal with > the problems of a few very large consumer isps who lack sufficient > space to number their customer edge. > Sounds like those consumer ISPs better get started on rolling out > dual stacks to the CPE. except that, if you do not have enough ipv4 pace to number your cpe perimeter, you can't do that. again, take a look at draft-ymbk-aplusp-02.txt randy From nanog at daork.net Tue Feb 17 21:07:06 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 18 Feb 2009 16:07:06 +1300 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> On 18/02/2009, at 3:23 PM, Randy Bush wrote: >> I find it a shame that NAT-PT has become depreciated > > the ietf has recanted and is hurriedly trying to get this back on > track. of course, to save face, the name has to be changed. Sort of - except it is only for IPv6 "clients" to connect to named IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 "clients" connecting to IPv6 "servers" - NAT64 does not. The server must have an A record in DNS, and the client must use that name to connect to - just like NAT-PT. -- Nathan Ward From brandon.galbraith at gmail.com Tue Feb 17 21:13:59 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 17 Feb 2009 21:13:59 -0600 Subject: IPv6 Confusion In-Reply-To: <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> Message-ID: <366100670902171913q11c2d6a4ub78bb78b145400bb@mail.gmail.com> So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? -brandon On 2/17/09, Nathan Ward wrote: > On 18/02/2009, at 3:23 PM, Randy Bush wrote: > >>> I find it a shame that NAT-PT has become depreciated >> >> the ietf has recanted and is hurriedly trying to get this back on >> track. of course, to save face, the name has to be changed. > > Sort of - except it is only for IPv6 "clients" to connect to named > IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 > "clients" connecting to IPv6 "servers" - NAT64 does not. > > The server must have an A record in DNS, and the client must use that > name to connect to - just like NAT-PT. > > -- > Nathan Ward > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From nanog at daork.net Tue Feb 17 21:16:47 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 18 Feb 2009 16:16:47 +1300 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <53ED1A9B-C528-46A2-B42C-979DE5ACB135@daork.net> On 18/02/2009, at 3:04 PM, Steven Lisson wrote: > ISP gets a chunk of IPv6 address space, sets up customers with it, > gets > their big lovely carrier grade NAT device that NAT's from customers > IPv6 > address to whatever IPv4 service they need. > > I'm probably missing something but does this not seem like a good > option? Why not use IPv6 instead of private IPv4, end user gets > end-to-end connectivity with anything that is IPv6 enabled while still > being able to access the legacy IPv4 network. Or, you do dual-stack, so their applications do not have to be modified to support IPv6 - they only need to support IPv4 (with NAT) like they always have. They have IPv6 to do end-to-end, and IPv4 to do client-to-server, or for legacy application support. How many of your customers are likely to be running Windows XP in 2 years? Probably still quite a few - they will not be able to function on IPv6-only, as they do not have DHCPv6. In the current state of things, IPv4 to the edge is going to be required for some time still I believe. Sure, over time applications will need IPv6 support. That is not going to be likely to be done by the time we run out of IPv4 resources for the edge. -- Nathan Ward From drc at virtualized.org Tue Feb 17 21:47:34 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 17 Feb 2009 17:47:34 -1000 Subject: IPv6 Confusion In-Reply-To: <056801c9914d$7c2a0e10$747e2a30$@net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> Message-ID: Tony, On Feb 17, 2009, at 12:17 PM, Tony Hain wrote: > This being a list of network engineers, there is a strong bias > toward tools > that allow explicit management of the network. This is a fine > position, and > those tools need to exist. There are others that don't want, or need > to know > about every bit on the wire, where 'as much automation as possible' > is the > right set of tools. No question. However, as this is a list of network engineers who are the folks who need to deploy IPv6 in order for others who may not care about every bit on the wire to make (non-internal) use of it, I'd think the bias displayed here something that might carry some weight. > Infighting at the IETF kept the RA from informing the > end systems about DNS, and kept DHCPv6 from informing them about their > router. The result is that you have to do both DHCP & RA, when each > should > be capable of working without the other. Yeah. Rants about the IETF should probably be directed elsewhere. > As far as dnssec, while the question is valid, blaming the IPv6 > design for > not considering something that 10+ years later is still not > deployed/deployable, is a bit of a stretch. Uh, no. That's not what I was saying. I was saying that stateless auto-configuration made certain assumptions about how naming and addressing worked that weren't necessarily well thought out (clients updating the reverse directly in a DNSSEC-signed environment was just an example). Perhaps it's just me, but it feels like there was a massive case of NIH syndrome in the IPv6 working groups that network operators are now paying the price for. However, as I said, rants about the IETF should probably be directed elsewhere. >> Or, we simply continue down the path of more NATv4. > While this is the popular position, those that have thought about it > realize > that what works for natv4 at the edge, does not work when that nat > is moved > toward the core. Yeah, multi-layer NAT sucks. I was amazed when I was speaking with some African ISPs that had to go this way today because their telecoms regulatory regime required them to obtain addresses from the national PTT and that PTT only gave them a single address. I would argue that if we want to avoid this outcome (and make no mistake, there are those who like this outcome as it means end users are only content consumers, which fits into their desired business models much more nicely), we need to make IPv6 look more like IPv4 so that network operators, end users, content providers, network application developers, etc., have minimal change in what they do, how they do it, or how they pay for it. Part of that is getting familiar tools (e.g., DHCP, customer provisioning, management, etc.) working the way it works in IPv4. Taking advantage of all the neato features IPv6 might provide can come later. However, I have a sneaking suspicion it might already be too late... Regards, -drc From stevel at dedicatedservers.net.au Tue Feb 17 22:03:07 2009 From: stevel at dedicatedservers.net.au (Steven Lisson) Date: Wed, 18 Feb 2009 14:03:07 +1000 Subject: IPv6 Confusion In-Reply-To: <366100670902171913q11c2d6a4ub78bb78b145400bb@mail.gmail.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> <366100670902171913q11c2d6a4ub78bb78b145400bb@mail.gmail.com> Message-ID: Basically that is what I was thinking, not sure could say problem solved as would still be using big nat boxes, but if we are going to 'have' to have nat, why not in a form that encourages adoption of IPv6? Having have said that, from someone else's comment would have to agree with them about using ipv4 nat dual stacked with ipv6 instead. Would likely be more realistic due to how little time have before ipv6 exhaustion and end systems that need additional configuration to enable ipv6 (and I know how much support people hate having to help end users setup things they don't understand... like email settings, they at least know what e-mail is and why they are setting it up, how many don't know what IP is and would just get frustrated at doing something they don't understand why?) -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Wednesday, 18 February 2009 1:14 PM To: Nathan Ward; nanog list Subject: Re: IPv6 Confusion So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? -brandon On 2/17/09, Nathan Ward wrote: > On 18/02/2009, at 3:23 PM, Randy Bush wrote: > >>> I find it a shame that NAT-PT has become depreciated >> >> the ietf has recanted and is hurriedly trying to get this back on >> track. of course, to save face, the name has to be changed. > > Sort of - except it is only for IPv6 "clients" to connect to named > IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 > "clients" connecting to IPv6 "servers" - NAT64 does not. > > The server must have an A record in DNS, and the client must use that > name to connect to - just like NAT-PT. > > -- > Nathan Ward > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From Skywing at valhallalegends.com Tue Feb 17 22:03:25 2009 From: Skywing at valhallalegends.com (Skywing) Date: Tue, 17 Feb 2009 22:03:25 -0600 Subject: IPv6 Confusion In-Reply-To: <366100670902171913q11c2d6a4ub78bb78b145400bb@mail.gmail.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> <366100670902171913q11c2d6a4ub78bb78b145400bb@mail.gmail.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6C01BB6E5C5@caralain.haven.nynaeve.net> Except for the fact that it's actually not so uncommon for "clients" to act as servers some of the time. Things have long ago left the days of clients were only clients and have since moved on to a muddier state of affairs. - S -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Tuesday, February 17, 2009 10:14 PM To: Nathan Ward; nanog list Subject: Re: IPv6 Confusion So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? -brandon On 2/17/09, Nathan Ward wrote: > On 18/02/2009, at 3:23 PM, Randy Bush wrote: > >>> I find it a shame that NAT-PT has become depreciated >> >> the ietf has recanted and is hurriedly trying to get this back on >> track. of course, to save face, the name has to be changed. > > Sort of - except it is only for IPv6 "clients" to connect to named > IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 > "clients" connecting to IPv6 "servers" - NAT64 does not. > > The server must have an A record in DNS, and the client must use that > name to connect to - just like NAT-PT. > > -- > Nathan Ward > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From nanog at daork.net Tue Feb 17 22:12:32 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 18 Feb 2009 17:12:32 +1300 Subject: IPv6 Confusion In-Reply-To: <366100670902171913q11c2d6a4ub78bb78b145400bb@mail.gmail.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> <366100670902171913q11c2d6a4ub78bb78b145400bb@mail.gmail.com> Message-ID: On 18/02/2009, at 4:13 PM, Brandon Galbraith wrote: > So we deploy v6 addresses to clients, and save the remaining v4 > addresses for servers. Problem solved? I have been suggesting that for a long time. However I am not suggesting IPv6-only to clients. See my other email on this from a minute or so ago. The way I see things going in the medium term: * IPv4 SP-NAT * IPv6 native to clients Clients with no DHCPv6 can get DNS resolvers etc, and they can get to IPv4 hosts through IPv4 NAT which they already understand, and does not require application changes. They can use the native IPv6 transit from their ISPs to get to other IPv6 hosts. I do not expect the other IPv6 hosts I mention to be IPv6-only - but chances are they will be behind IPv4 NAT. That doesn't matter of course, because we are reaching them on native IPv6. I also recommend that you hold on to a /22 or something, and use that for customer assignment - but replicate it many times in your network. This way, your numbers assigned to customers will never conflict with their internal RFC1918 addressing, and their "deny RFC1918 to/from outside" automatic firewall things will not have any problems. Public IPv4 addresses behind NAT is quite common, so applications are used to dealing with it by now, for the most part - there are a few bugs with this and some implementations of 6to4 so I will write up a work around for this. We now have a bunch of IPv4 addresses we can re-purpose for servers and things, because we require less IPv4 addresses to serve our end user customers base. We will not be able to put servers on IPv6-only for a long time - we will have legacy applications, client hosts, and access networks that do not support IPv6. IPv4 will be required for public servers until these client hosts are a smaller percentage than they are now. Dirty trick - if you are an access-only provider, wait until the IPv4 pools are depleted, and then push all your customers in to SP-NAT, and then sell your now unused addresses[1] to other providers who cannot make do with hosts behind IPv4 NAT (ie, colocation, business Internet services, etc.). Use this income to pay for your IPv6 rollout, so your customers can continue to do end-to-end stuff. I forget what Geoff's speculation of what an IP address would cost - I seem to recall around about $1M per /16, but I could be wrong. -- Nathan Ward [1] Yes I know that this is not allowed under current policy at any RIR. From drc at virtualized.org Tue Feb 17 22:18:33 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 17 Feb 2009 18:18:33 -1000 Subject: IPv6 Confusion In-Reply-To: <200902180155.n1I1tr1e005174@drugs.dv.isc.org> References: <200902180155.n1I1tr1e005174@drugs.dv.isc.org> Message-ID: <6F7BA817-320B-414F-9811-03B476990800@virtualized.org> On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote: > In otherwords ISP's need to enter the 21st century. Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around every day, kicking back, eating Bon Bons(tm), and thinking of all the new and interesting ways they can burn the vast tracts of ill-gotten profits they're obviously rolling in. Reality check: change in large scale production networks is hard and expensive. There needs to be a business case to justify making substantive changes. You are arguing that ISPs should make changes without any obvious mechanism to guarantee some return on the investment necessary to pay for those changes. This is a waste of time. In general, NAT is paid for by the end user, not the network provider. Migrating to IPv6 on the other hand is paid for entirely by the network provider. Guess which is easier to make a business case for? Note that I'm not saying I like the current state of affairs, rather I'm suggesting that jumping up and down demanding ISPs change because you think they're stuck in the last century is unlikely to get you very far. You want a concrete suggestion? Make configuring DDNS on BIND _vastly_ simpler, scalable to tens or hundreds of thousands of clients, and manageable by your average NOC staff. Regards, -drc From zaid at zaidali.com Tue Feb 17 22:40:39 2009 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 17 Feb 2009 20:40:39 -0800 (PST) Subject: IPv6 Confusion In-Reply-To: <6F7BA817-320B-414F-9811-03B476990800@virtualized.org> Message-ID: <9174763.2381234932035414.JavaMail.zaid@turing-2.local> >You are arguing that ISPs should make changes >without any obvious mechanism to guarantee some return on the >investment necessary to pay for those changes. Nail on the head and the 800 pound gorilla in the room. Japan gave tax incentives which helped their ISP's to move to IPv6. Find a lazy lobbyist who can educate a senator to say that there will be no more tubes left on the internet and slide a tax incentive into the next stimulus package :) Zaid ----- Original Message ----- From: "David Conrad" To: "Mark Andrews" Cc: "NANOG list" Sent: Tuesday, February 17, 2009 8:18:33 PM GMT -08:00 US/Canada Pacific Subject: Re: IPv6 Confusion On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote: > In otherwords ISP's need to enter the 21st century. Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around every day, kicking back, eating Bon Bons(tm), and thinking of all the new and interesting ways they can burn the vast tracts of ill-gotten profits they're obviously rolling in. Reality check: change in large scale production networks is hard and expensive. There needs to be a business case to justify making substantive changes. You are arguing that ISPs should make changes without any obvious mechanism to guarantee some return on the investment necessary to pay for those changes. This is a waste of time. In general, NAT is paid for by the end user, not the network provider. Migrating to IPv6 on the other hand is paid for entirely by the network provider. Guess which is easier to make a business case for? Note that I'm not saying I like the current state of affairs, rather I'm suggesting that jumping up and down demanding ISPs change because you think they're stuck in the last century is unlikely to get you very far. You want a concrete suggestion? Make configuring DDNS on BIND _vastly_ simpler, scalable to tens or hundreds of thousands of clients, and manageable by your average NOC staff. Regards, -drc From randy at psg.com Tue Feb 17 22:49:52 2009 From: randy at psg.com (Randy Bush) Date: Wed, 18 Feb 2009 13:49:52 +0900 Subject: IPv6 Confusion In-Reply-To: <9174763.2381234932035414.JavaMail.zaid@turing-2.local> References: <6F7BA817-320B-414F-9811-03B476990800@virtualized.org> <9174763.2381234932035414.JavaMail.zaid@turing-2.local> Message-ID: > Japan gave tax incentives which helped their ISP's to move to IPv6. i am writing this from my home office in tokyo. i have the latest fanciest wizbang ftth bflets 100/100 from ntt. native ipv6 is not offered on it. if i connect a v6 device to it, it gives me a v6 AC and RA. but that is for the closed walled garden voip phone service. randy From justin at justinshore.com Tue Feb 17 23:08:21 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 17 Feb 2009 23:08:21 -0600 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> Message-ID: <499B97C5.9020601@justinshore.com> Steven Lisson wrote: > Hi, > > I find it a shame that NAT-PT has become depreciated, with people > talking about carrier grade NATS I think combining these with NAT-PT > could help with the transition after we run out of IPv4 space. For me the bigger problem is how do I enable IPv6 on my assorted CE-facing edges when management is still buying edge hardware that can not and will not ever support IPv6. Our CATV solution can't support IPv6 (it's not a DOCSIS 3 thing; it's that the specific model of CMTS we're buying can not do IPv6). Our shiny new ADSL2+ solution can't do IPv6 and support in hardware can't be added down the road. For that matter our FTTH solution which is L2 only doesn't really support IPv6 with their pseudo L3 security options. So 1) how does one get management of a US SP to realize that IPv6 is coming well within the lifetime of the brand-new equipment that we're purchasing and should be a major show-stopping purchasing decision, and 2) how do we get common equipment manufacturers to build in IPv6 support to the equipment we're buying? During our FTTH dog and pony show process with half a dozen different vendors, I asked each of them about their IPv6 support and they all unanimously claimed that there was no demand for it from their customers. At this point I'm looking at doing 6to4 tunnels far into the future. Justin From Mark_Andrews at isc.org Tue Feb 17 23:09:11 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 18 Feb 2009 16:09:11 +1100 Subject: IPv6 Confusion In-Reply-To: Your message of "Tue, 17 Feb 2009 18:18:33 -1000." <6F7BA817-320B-414F-9811-03B476990800@virtualized.org> Message-ID: <200902180509.n1I59BNc006558@drugs.dv.isc.org> In message <6F7BA817-320B-414F-9811-03B476990800 at virtualized.org>, David Conrad writes: > On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote: > > In otherwords ISP's need to enter the 21st century. > > Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around > every day, kicking back, eating Bon Bons(tm), and thinking of all the > new and interesting ways they can burn the vast tracts of ill-gotten > profits they're obviously rolling in. > > Reality check: change in large scale production networks is hard and > expensive. There needs to be a business case to justify making > substantive changes. You are arguing that ISPs should make changes > without any obvious mechanism to guarantee some return on the > investment necessary to pay for those changes. This is a waste of time. Adding support to accept dynamic updates is a small configuration change. > In general, NAT is paid for by the end user, not the network > provider. Migrating to IPv6 on the other hand is paid for entirely by > the network provider. Guess which is easier to make a business case > for? No. It also requires the end user to also upgrade equipment. Mind you a lot of that upgrading has already been paid for by both the ISP and the end user. I'll most probably need to upgrade to a DOCSIS 3 modem for native IPv6 support. I own my current modem. > Note that I'm not saying I like the current state of affairs, rather > I'm suggesting that jumping up and down demanding ISPs change because > you think they're stuck in the last century is unlikely to get you > very far. You want a concrete suggestion? Make configuring DDNS on > BIND _vastly_ simpler, scalable to tens or hundreds of thousands of > clients, and manageable by your average NOC staff. For the reverse namespace we have tcp-self and 6to4-self we could trivially add a 56-self for ISP's that want to deploy on the /56 boundary rather than the /48 boundary that 6to4-self uses. TCP is used as the authenticator for these updates. zone "23.2.1.in-addr.arpa" { type master; ... update-policy { grant * tcp-self * PTR; }; }; TSIG or SIG(0) can be used in the forward direction. zone "example.net" { type master; ... update-policy { grant * self *; }; }; It doesn't get much simpler than that. Mark > Regards, > -drc > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Valdis.Kletnieks at vt.edu Tue Feb 17 23:24:39 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 18 Feb 2009 00:24:39 -0500 Subject: IPv6 Confusion In-Reply-To: Your message of "Tue, 17 Feb 2009 23:08:21 CST." <499B97C5.9020601@justinshore.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> Message-ID: <27157.1234934679@turing-police.cc.vt.edu> On Tue, 17 Feb 2009 23:08:21 CST, Justin Shore said: > For me the bigger problem is how do I enable IPv6 on my assorted > CE-facing edges when management is still buying edge hardware that can > not and will not ever support IPv6. Find out if Randy Bush's companies are still buying non-IPv6-capable gear, and ask if you're a competitor to those companies... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From swmike at swm.pp.se Tue Feb 17 23:40:07 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 18 Feb 2009 06:40:07 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <499B97C5.9020601@justinshore.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> Message-ID: On Tue, 17 Feb 2009, Justin Shore wrote: > different vendors, I asked each of them about their IPv6 support and > they all unanimously claimed that there was no demand for it from their > customers. Well, this is just ignorance or a kind of a lie. There might be few customers who are willing to treat IPv6 support as a showstopper, but saying that there is no demand simply isn't true, it's just that they can get away without IPv6 support right now. We all hear the same thing when we ask for IPv6 support. Most of the time the vendors don't educate their sales force (both the droids and the sales engineers) about IPv6 because they themselves have made the strategic decision that IPv6 isn't important to them (personal view). I've seen IPv6 show up on presentations more and more though, so it's going in the right direction. But as you say, any new equipment decisions done today should include lack of IPv6 support as a show stopper (it should at least be committed in roadmap), plus it needs to be specified exactly what kind of IPv6 support should be in it. I agree with you that 6to4 seems to be the tunneling mechanism of choice for the forseeable future. It's easy to implement in the home gateways, but there too, you need to force the CPE vendors to include 6to4 into their CPE software. If any CPE NAT box vendor comes around and has 6to4 with proper IPv6, I'll happily recommend all our customers who want IPv6 to buy that perticular box. -- Mikael Abrahamsson email: swmike at swm.pp.se From drc at virtualized.org Wed Feb 18 00:18:51 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 17 Feb 2009 20:18:51 -1000 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> Message-ID: <5699373B-7F5B-4CD6-BF28-F9190D39AD72@virtualized.org> On Feb 17, 2009, at 7:40 PM, Mikael Abrahamsson wrote: > Most of the time the vendors don't educate their sales force (both > the droids and the sales engineers) about IPv6 because they > themselves have made the strategic decision that IPv6 isn't > important to them (personal view). Suggestion: next time you buy equipment from competing vendors, tell the sales folk from the losing vendors that one deciding factor was (vendor or product) IPv6 support. That (and perhaps only that) will get their attention... :-) > If any CPE NAT box vendor comes around and has 6to4 with proper > IPv6, I'll happily recommend all our customers who want IPv6 to buy > that perticular box. Apple Airport Extreme? (Seems to work, but I don't know how standards conformant it is) Regards, -drc From swmike at swm.pp.se Wed Feb 18 01:18:17 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 18 Feb 2009 08:18:17 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <5699373B-7F5B-4CD6-BF28-F9190D39AD72@virtualized.org> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> <5699373B-7F5B-4CD6-BF28-F9190D39AD72@virtualized.org> Message-ID: On Tue, 17 Feb 2009, David Conrad wrote: > Suggestion: next time you buy equipment from competing vendors, tell the > sales folk from the losing vendors that one deciding factor was (vendor > or product) IPv6 support. That (and perhaps only that) will get their > attention... :-) Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. Even the companies who do support IPv6 very well in some products, not all their BUs do on their own products (you know who you are :P ). I'm hopeful though, I see more and more references to IPv6 show up in product powerpoint presentations, so it's moving in the right direction. >> If any CPE NAT box vendor comes around and has 6to4 with proper IPv6, I'll >> happily recommend all our customers who want IPv6 to buy that perticular >> box. > > Apple Airport Extreme? (Seems to work, but I don't know how standards > conformant it is) Too expensive. -- Mikael Abrahamsson email: swmike at swm.pp.se From adrian at creative.net.au Wed Feb 18 01:32:50 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 18 Feb 2009 16:32:50 +0900 Subject: IPv6 Confusion In-Reply-To: References: <499B97C5.9020601@justinshore.com> <5699373B-7F5B-4CD6-BF28-F9190D39AD72@virtualized.org> Message-ID: <20090218073249.GF14136@skywalker.creative.net.au> On Wed, Feb 18, 2009, Mikael Abrahamsson wrote: > >>If any CPE NAT box vendor comes around and has 6to4 with proper IPv6, ^^^^^ > >>I'll happily recommend all our customers who want IPv6 to buy that > >>perticular box. > > > >Apple Airport Extreme? (Seems to work, but I don't know how standards > >conformant it is) > > Too expensive. Oh, so you want the $50 almost-but-not-quite-functional CPE device which causes headaches for you and your techies, complete with almost-but-not-quite "upgrade" firmware updates which somewhat-wierdly subtly break existing functionality for a small-but-statistically-annoying portion of your userbase. Gotcha! :) Adrian (Yeah I know, Apple have shipped busted updates too..) From swmike at swm.pp.se Wed Feb 18 01:41:08 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 18 Feb 2009 08:41:08 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <20090218073249.GF14136@skywalker.creative.net.au> References: <499B97C5.9020601@justinshore.com> <5699373B-7F5B-4CD6-BF28-F9190D39AD72@virtualized.org> <20090218073249.GF14136@skywalker.creative.net.au> Message-ID: On Wed, 18 Feb 2009, Adrian Chadd wrote: > Oh, so you want the $50 almost-but-not-quite-functional CPE device which > causes headaches for you and your techies, complete with > almost-but-not-quite "upgrade" firmware updates which somewhat-wierdly > subtly break existing functionality for a > small-but-statistically-annoying portion of your userbase. > Gotcha! For my USD30 a month 24 megabit ADSL2 residential broadband service, yes, you got it right, apart from that the cost should probably be more in the USD20-30 range. But at this point in the development cycle, I was more expecting this functionality in the USD100+ high-end consumer NAT/wifi-gateways. For the corporate offering with managed service, no, I do want something better there. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Wed Feb 18 03:12:28 2009 From: randy at psg.com (Randy Bush) Date: Wed, 18 Feb 2009 18:12:28 +0900 Subject: IPv6 Confusion In-Reply-To: <27157.1234934679@turing-police.cc.vt.edu> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> <27157.1234934679@turing-police.cc.vt.edu> Message-ID: >> For me the bigger problem is how do I enable IPv6 on my assorted >> CE-facing edges when management is still buying edge hardware that >> can not and will not ever support IPv6. > Find out if Randy Bush's companies are still buying non-IPv6-capable > gear, and ask if you're a competitor to those companies... :) lol. fwiw, iij makes our own cpe which does dual stack, ipsec, ... see for the high end of the seil line. and there is an assortment of dual stack cpe available here, china, ... randy From david.freedman at uk.clara.net Wed Feb 18 08:05:19 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 18 Feb 2009 14:05:19 +0000 Subject: IPv6 Confusion In-Reply-To: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> Message-ID: > > It's a 128 bit address. Routing is done on VLSM, but, generally for DNS > purposes, these > are expected to be at least on nibble boundaries. > > There is an intent to support what is known as EUI-64, which means every > subnet should > be a /64, however, there are people who number smaller subnets and that > is supposed > to work, but, it will break certain IPv6 things like stateless > autoconfiguration (which is > optional). We are one of these people who opted to use smaller subnet sizes for point-to-point networks (i.e router transfer nets), If you are interested in what we did and want to see some examples of what other people are doing check out a presentation that I gave some time ago about our deployment http://www.convergence.cx/ipv6clara.ppt (apologies for the lack of PDF) Slides 2-15 Dave. From trejrco at gmail.com Wed Feb 18 08:14:07 2009 From: trejrco at gmail.com (TJ) Date: Wed, 18 Feb 2009 09:14:07 -0500 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> <366100670902171913q11c2d6a4ub78bb78b145400bb@mail.gmail.com> Message-ID: <014001c991d3$2a607020$7f215060$@com> >> So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? >I have been suggesting that for a long time. > >However I am not suggesting IPv6-only to clients. See my other email on this >from a minute or so ago. > >The way I see things going in the medium term: >* IPv4 SP-NAT >* IPv6 native to clients +1 Wait, can I vote more than once? If so, +(more). <> From jbates at brightok.net Wed Feb 18 08:23:34 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 18 Feb 2009 08:23:34 -0600 Subject: IPv6 Confusion In-Reply-To: <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <65EE9B0D-70C3-4953-A17B-1D2F3F0DEE7F@daork.net> Message-ID: <499C19E6.1070705@brightok.net> Nathan Ward wrote: > Sort of - except it is only for IPv6 "clients" to connect to named IPv4 > "servers". NAT-PT allowed for the opposite direction, IPv4 "clients" > connecting to IPv6 "servers" - NAT64 does not. > Which is a serious mistake in my opinion. Corporate world will not or can not shift out of IPv4 for many years. They will use firewalls to handle conversions (4 inside, 6 outside). The legacy software that runs within corporations always astounds me, but it is what it is. I honestly doubt that a single vendor out there cares one lick about the IETF, and they will provide whatever their customers demand; or lose the customer. -Jack From bvlmv5 at gmail.com Wed Feb 18 08:51:21 2009 From: bvlmv5 at gmail.com (Bryant Valencia) Date: Wed, 18 Feb 2009 09:51:21 -0500 Subject: Cisco NOS Message-ID: Has anybody hired Cisco for their NOS (Network Optimization Services)? I would like to hear about your experience (good or bad). I'm particularly interested in their CNC box. Bryant. From tkapela at gmail.com Wed Feb 18 09:28:11 2009 From: tkapela at gmail.com (Anton Kapela) Date: Wed, 18 Feb 2009 16:28:11 +0100 Subject: Cisco NOS In-Reply-To: References: Message-ID: <2e9d8ae50902180728m685524eatef297d2c9018b766@mail.gmail.com> On Wed, Feb 18, 2009 at 3:51 PM, Bryant Valencia wrote: > Has anybody hired Cisco for their NOS (Network Optimization Services)? I > would like to hear about your experience (good or bad). > I'm particularly interested in their CNC box. Either this is merely exquisite acronym collision, or someone from marketing was been slamming too much www.drinknos.com and reading about botnets on the FUNSEC list. As for the service, one of my old clients has been engaging Cisco for some years now for a variety of needs. The reports are, in their subjective use, basically positive. My opinion is simply that it's a formalization of stuff Cisco has been doing for years. That is, doing the good engineering and planning work that many organizations are not (for any number of reasons) doing themselves. When it comes to the sale of box A, B, and C, (where the value of the set is not obvious to, say, a rural co-op ILEC management team) a vendor providing 'staff embedded' engineering can easily be a determining factor in winning or losing. -Tk From drc at virtualized.org Wed Feb 18 11:57:12 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 18 Feb 2009 07:57:12 -1000 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> <5699373B-7F5B-4CD6-BF28-F9190D39AD72@virtualized.org> Message-ID: Mikael, On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote: >> Suggestion: next time you buy equipment from competing vendors, >> tell the sales folk from the losing vendors that one deciding >> factor was (vendor or product) IPv6 support. That (and perhaps only >> that) will get their attention... :-) > Well, considering how very few vendors actually support IPv6, it's > hard to find proper competition. You don't have to tell the truth to the losing sales folk... :-) Regards, -drc From mcalhoun at iodatacenters.com Wed Feb 18 11:58:33 2009 From: mcalhoun at iodatacenters.com (Calhoun, Matthew) Date: Wed, 18 Feb 2009 10:58:33 -0700 Subject: McAfee/AT&T Issue In-Reply-To: <2e9d8ae50902180728m685524eatef297d2c9018b766@mail.gmail.com> References: <2e9d8ae50902180728m685524eatef297d2c9018b766@mail.gmail.com> Message-ID: <57F018B226E004449B318DAF71A6014656E25F69E7@IO-SCD-EX-M-01.corp.iodatacenters.com> We are seeing intermittent connectivity issues via AT&T to McAfee's Update service network (208.69.152.0/21). Attempts to contact McAfee Support and AT&T support have gotten standard responses. If there is a McAfee Net Admin on list, maybe you can initiate a ticket with AT&T? We've got several downstream customers that are being affected by the issue. 3 3 ms 3 ms 2 ms iodc-69-71-48-2.ioconnect.net [69.71.48.2] 4 3 ms 3 ms 3 ms 12.89.121.177 5 26 ms 25 ms 25 ms cr1.phmaz.ip.att.net [12.123.206.138] 6 26 ms 25 ms 25 ms cr1.dlstx.ip.att.net [12.122.28.181] 7 26 ms 26 ms 27 ms tbr1.dlstx.ip.att.net [12.122.18.138] 8 25 ms 25 ms 25 ms gar4.dlstx.ip.att.net [12.123.16.97] 9 212 ms 200 ms * 12.118.225.22 <--------Problem occurring here. Sometimes traffic gets through, sometimes it doesn't 10 29 ms 26 ms 26 ms 216.143.71.219 11 26 ms 26 ms 26 ms www.mcafeeasap.com [208.69.153.135] Thanks, Matt Calhoun i/o Data Centers From kris.foster at gmail.com Wed Feb 18 12:02:24 2009 From: kris.foster at gmail.com (kris foster) Date: Wed, 18 Feb 2009 10:02:24 -0800 Subject: McAfee/AT&T Issue In-Reply-To: <57F018B226E004449B318DAF71A6014656E25F69E7@IO-SCD-EX-M-01.corp.iodatacenters.com> References: <2e9d8ae50902180728m685524eatef297d2c9018b766@mail.gmail.com> <57F018B226E004449B318DAF71A6014656E25F69E7@IO-SCD-EX-M-01.corp.iodatacenters.com> Message-ID: <20A179F1-A1F5-4FF1-BF57-4B5A0DB16031@gmail.com> On Feb 18, 2009, at 9:58 AM, Calhoun, Matthew wrote: > We are seeing intermittent connectivity issues via AT&T to McAfee's > Update service network (208.69.152.0/21). > 9 212 ms 200 ms * 12.118.225.22 <--------Problem > occurring here. Sometimes traffic gets through, sometimes it doesn't > 10 29 ms 26 ms 26 ms 216.143.71.219 > 11 26 ms 26 ms 26 ms www.mcafeeasap.com [208.69.153.135] Richard Steenbergen did an excellent presentation at NANOG 45 on interpreting traceroutes. The final hop here looks quite healthy in terms of latency and packetloss. http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTE4NSZuYW5vZzQ1&nm=nanog45 Kris From kgasso-lists at visp.net Wed Feb 18 12:03:26 2009 From: kgasso-lists at visp.net (Kameron Gasso) Date: Wed, 18 Feb 2009 10:03:26 -0800 Subject: McAfee/AT&T Issue In-Reply-To: <57F018B226E004449B318DAF71A6014656E25F69E7@IO-SCD-EX-M-01.corp.iodatacenters.com> References: <2e9d8ae50902180728m685524eatef297d2c9018b766@mail.gmail.com> <57F018B226E004449B318DAF71A6014656E25F69E7@IO-SCD-EX-M-01.corp.iodatacenters.com> Message-ID: <499C4D6E.7040103@visp.net> Calhoun, Matthew wrote: > 9 212 ms 200 ms * 12.118.225.22 <--------Problem occurring here. Sometimes traffic gets through, sometimes it doesn't > 10 29 ms 26 ms 26 ms 216.143.71.219 > 11 26 ms 26 ms 26 ms www.mcafeeasap.com [208.69.153.135] Looks a lot like that hop is rate-limiting ICMP to itself. Everything beyond it seems to be good from the looks of it. -Kam From jkrejci at usinternet.com Wed Feb 18 12:14:41 2009 From: jkrejci at usinternet.com (Justin Krejci) Date: Wed, 18 Feb 2009 12:14:41 -0600 Subject: McAfee/AT&T Issue In-Reply-To: <499C4D6E.7040103@visp.net> References: <2e9d8ae50902180728m685524eatef297d2c9018b766@mail.gmail.com><57F018B226E004449B318DAF71A6014656E25F69E7@IO-SCD-EX-M-01.corp.iodatacenters.com> <499C4D6E.7040103@visp.net> Message-ID: <80CDE2A08C944212B6670743FC43388D@usicorp.usinternet.com> We've also seen that busy routers are slower to respond to requests directed at them as opposed to traffic routing thru them which can continue to work without issue or performance loss. -----Original Message----- From: Kameron Gasso [mailto:kgasso-lists at visp.net] Sent: Wednesday, February 18, 2009 12:03 PM To: Calhoun, Matthew Cc: NANOG list Subject: Re: McAfee/AT&T Issue Calhoun, Matthew wrote: > 9 212 ms 200 ms * 12.118.225.22 <--------Problem occurring here. Sometimes traffic gets through, sometimes it doesn't > 10 29 ms 26 ms 26 ms 216.143.71.219 > 11 26 ms 26 ms 26 ms www.mcafeeasap.com [208.69.153.135] Looks a lot like that hop is rate-limiting ICMP to itself. Everything beyond it seems to be good from the looks of it. -Kam From oberman at es.net Wed Feb 18 12:19:51 2009 From: oberman at es.net (Kevin Oberman) Date: Wed, 18 Feb 2009 10:19:51 -0800 Subject: IPv6 Confusion In-Reply-To: Your message of "Wed, 18 Feb 2009 07:57:12 -1000." Message-ID: <20090218181951.EEC111CC09@ptavv.es.net> > From: David Conrad > Date: Wed, 18 Feb 2009 07:57:12 -1000 > > Mikael, > > On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote: > >> Suggestion: next time you buy equipment from competing vendors, > >> tell the sales folk from the losing vendors that one deciding > >> factor was (vendor or product) IPv6 support. That (and perhaps only > >> that) will get their attention... :-) > > Well, considering how very few vendors actually support IPv6, it's > > hard to find proper competition. > > You don't have to tell the truth to the losing sales folk... :-) Yes, I saw the smiley, but what you suggested could cause a lot of suffering if it is a formal bid. (If a mom-n-pop buys a 2960, probably not an issue.) Ethical issues aside, giving incorrect information to a losing vendor is fraud and, at least in the public sector, can get you in more trouble than you would ever want to think about being in. Our procurement officers are scrupulous in detailing the required information for the losing bidder's debrief on contracts of any size. This means putting in just as much information as is required and nothing more and making sure that what is included is correct. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From mcalhoun at iodatacenters.com Wed Feb 18 12:25:02 2009 From: mcalhoun at iodatacenters.com (Calhoun, Matthew) Date: Wed, 18 Feb 2009 11:25:02 -0700 Subject: McAfee/AT&T Issue In-Reply-To: <80CDE2A08C944212B6670743FC43388D@usicorp.usinternet.com> References: <2e9d8ae50902180728m685524eatef297d2c9018b766@mail.gmail.com><57F018B226E004449B318DAF71A6014656E25F69E7@IO-SCD-EX-M-01.corp.iodatacenters.com> <499C4D6E.7040103@visp.net> <80CDE2A08C944212B6670743FC43388D@usicorp.usinternet.com> Message-ID: <57F018B226E004449B318DAF71A6014656E25F69FB@IO-SCD-EX-M-01.corp.iodatacenters.com> While I agree with all of your assessments, this traceroute was being provided to illustrate where traffic *appears* to be stopping when we are seeing the issue. It's intermittent, so some times we can reach the destination hosts (via HTTP, HTTPS, etc.) and sometimes we can't. When we can reach the destination hosts (via HTTP), the traceroute completes When we can't reach the destination hosts (via HTTP), the traceroute won't complete and the last hop is the host that I indicated in my previous post (12.118.225.22) Thanks, Matt -----Original Message----- From: Justin Krejci [mailto:jkrejci at usinternet.com] Sent: Wednesday, February 18, 2009 11:15 AM To: kgasso at visp.net; Calhoun, Matthew Cc: 'NANOG list' Subject: RE: McAfee/AT&T Issue We've also seen that busy routers are slower to respond to requests directed at them as opposed to traffic routing thru them which can continue to work without issue or performance loss. -----Original Message----- From: Kameron Gasso [mailto:kgasso-lists at visp.net] Sent: Wednesday, February 18, 2009 12:03 PM To: Calhoun, Matthew Cc: NANOG list Subject: Re: McAfee/AT&T Issue Calhoun, Matthew wrote: > 9 212 ms 200 ms * 12.118.225.22 <--------Problem occurring here. Sometimes traffic gets through, sometimes it doesn't > 10 29 ms 26 ms 26 ms 216.143.71.219 > 11 26 ms 26 ms 26 ms www.mcafeeasap.com [208.69.153.135] Looks a lot like that hop is rate-limiting ICMP to itself. Everything beyond it seems to be good from the looks of it. -Kam From dave.nanog at alfordmedia.com Wed Feb 18 12:58:19 2009 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Wed, 18 Feb 2009 12:58:19 -0600 Subject: IPv6 Confusion In-Reply-To: Message-ID: >> Well, considering how very few vendors actually support IPv6, it's >> hard to find proper competition. > > You don't have to tell the truth to the losing sales folk... : Or you could be truthful and say "we decided to go with the XYZ product, despite the fact that they don't support IPv6; if your product HAD supported IPv6 you would have been in a much stronger position when the contract was awarded." -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From drc at virtualized.org Wed Feb 18 13:05:50 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 18 Feb 2009 09:05:50 -1000 Subject: IPv6 Confusion In-Reply-To: <20090218181951.EEC111CC09@ptavv.es.net> References: <20090218181951.EEC111CC09@ptavv.es.net> Message-ID: <7CE89ED4-E20A-47DF-8EA7-5217B7141AF4@virtualized.org> Kevin, On Feb 18, 2009, at 8:19 AM, Kevin Oberman wrote: >> You don't have to tell the truth to the losing sales folk... :-) > Yes, I saw the smiley, but Sigh. Perhaps there needs to be an emoticon for "really joking, really. no, really.". > Ethical issues aside, giving incorrect information to a losing vendor > is fraud and, at least in the public sector, can get you in more > trouble > than you would ever want to think about being in. If a vendor sales person indicates they are getting no requests for IPv6 support in their products (which would clearly be false since presumably you are requesting IPv6 support), then stating one reason the vendor did not win a bid was because of that vendor's stance on IPv6 may be accurate (YMMV). I have some skepticism such a claim would be considered unethical or fraud, even in the squeaky clean world of US government procurement. Regards, -drc From kloch at kl.net Wed Feb 18 13:39:04 2009 From: kloch at kl.net (Kevin Loch) Date: Wed, 18 Feb 2009 14:39:04 -0500 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> Message-ID: <499C63D8.2070100@kl.net> David Conrad wrote: > Yeah. Rants about the IETF should probably be directed elsewhere. Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? - Kevin From nick at foobar.org Wed Feb 18 13:45:46 2009 From: nick at foobar.org (Nick Hilliard) Date: Wed, 18 Feb 2009 19:45:46 +0000 Subject: IPv6 Confusion In-Reply-To: <499C63D8.2070100@kl.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> Message-ID: <499C656A.2040304@foobar.org> On 18/02/2009 19:39, Kevin Loch wrote: > Just how DO we get the message to the IETF that we need all the tools we > have in v4 (DHCP, VRRP, etc) to work with RA turned off? Easy. Disable all ipv4 at ietf meetings and change the address of the DNS server on the LAN every couple of minutes. Eating one's own dog food can concentrate the mind like nothing else. Nick From schnizlein at isoc.org Wed Feb 18 13:51:48 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Wed, 18 Feb 2009 14:51:48 -0500 Subject: IPv6 Confusion In-Reply-To: <499C656A.2040304@foobar.org> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> Message-ID: Humor aside, the only practical answer is to show up at meetings and and on mailing lists and express your technical reasons. There are people there (in addition to me) who want the perspective of network operators. John On 2009Feb18, at 2:45 PM, Nick Hilliard wrote: > On 18/02/2009 19:39, Kevin Loch wrote: >> Just how DO we get the message to the IETF that we need all the >> tools we >> have in v4 (DHCP, VRRP, etc) to work with RA turned off? > > Easy. Disable all ipv4 at ietf meetings and change the address of > the DNS server on the LAN every couple of minutes. > > Eating one's own dog food can concentrate the mind like nothing else. From jbates at brightok.net Wed Feb 18 13:53:41 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 18 Feb 2009 13:53:41 -0600 Subject: IPv6 Confusion In-Reply-To: <499C63D8.2070100@kl.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> Message-ID: <499C6745.3000709@brightok.net> Kevin Loch wrote: > Just how DO we get the message to the IETF that we need all the tools we > have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. RA is used as a starting point. It can push you to DHCPv6 or any number of other options (such as SLAAC). The same argument goes for multicast versus broadcast. The idea is to add an extra level that allows for better manipulation and versatility. Of course, better support and vendor implementation of all the different options would be nice. Most networks have broadcast controls that are mostly vendor specific hacks. Now they'll have multicast controls, which is good to have anyways. If you want to get into something irksome, please point out that looking at a much of link local addresses/interfaces for next hopes in IGP's is rather annoying. Only reason to even have global routed IP's on the router is for traceroutes, but you can't just "look up route, ping next hop IP from remote location to verify next hop was reachable". -Jack From aredridel at nbtsc.org Wed Feb 18 13:55:19 2009 From: aredridel at nbtsc.org (Aria Stewart) Date: Wed, 18 Feb 2009 12:55:19 -0700 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> Message-ID: <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> > > On 18/02/2009 19:39, Kevin Loch wrote: >> Just how DO we get the message to the IETF that we need all the >> tools we >> have in v4 (DHCP, VRRP, etc) to work with RA turned off? What operational reasons are there for working with RA turned off? Aria Stewart aredridel at nbtsc.org -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2318 bytes Desc: not available URL: From cra at WPI.EDU Wed Feb 18 14:08:54 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 18 Feb 2009 15:08:54 -0500 Subject: IPv6 Confusion In-Reply-To: <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: <20090218200854.GR24542@angus.ind.WPI.EDU> On Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: >> >> On 18/02/2009 19:39, Kevin Loch wrote: >>> Just how DO we get the message to the IETF that we need all the >>> tools we >>> have in v4 (DHCP, VRRP, etc) to work with RA turned off? > > What operational reasons are there for working with RA turned off? I don't want any system to be able to get IPv6 addressing information until the system has been identified in our central management system. I also want the IPv6 address assignment to be made centrally. From sthaug at nethelp.no Wed Feb 18 14:10:57 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 18 Feb 2009 21:10:57 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <499C6745.3000709@brightok.net> References: <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> Message-ID: <20090218.211057.74714287.sthaug@nethelp.no> > > Just how DO we get the message to the IETF that we need all the tools we > > have in v4 (DHCP, VRRP, etc) to work with RA turned off? > > You don't, because there isn't really a technical reason for turning off > RA. I'm glad to see that several of the big vendors seem to disagree with you. - Cisco does RA as soon as an interface has an IPv6 address, but has a knob to disable RA (ipv6 nd ra suppress). - Juniper does *not* do RA as soon as an interface has an IPv6 address, it must be explicitly configured. So we are part way there - IPv6 can be used without RA. We just need DHCPv6 to work properly without RA. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From randy at psg.com Wed Feb 18 14:15:05 2009 From: randy at psg.com (Randy Bush) Date: Thu, 19 Feb 2009 05:15:05 +0900 Subject: IPv6 Confusion In-Reply-To: <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: > What operational reasons are there for working with RA turned off? networks with visitors have shown a serious problem with rouge RAs randy From Valdis.Kletnieks at vt.edu Wed Feb 18 14:17:56 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 18 Feb 2009 15:17:56 -0500 Subject: IPv6 Confusion In-Reply-To: Your message of "Wed, 18 Feb 2009 12:55:19 MST." <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: <22995.1234988276@turing-police.cc.vt.edu> On Wed, 18 Feb 2009 12:55:19 MST, Aria Stewart said: > What operational reasons are there for working with RA turned off? If the intent is to feed the just-booted box all its network config via DHCPv6, including the network/netmask/default router, the *last* thing you want is a second box blabbing a packet in the middle and potentially confusing things in one of two ways: 1) Some chuckleheaded banana-eater made a typo and the RA bits don't match the bits supplied by DHCP, resulting in a non-deterministic bug depending which packet gets there first (at least with DHCPv4 or standalone RA, a misconfigure busts *everything* on the subnet and makes debugging easier). 2) Some end-node box with a IPv6 stack from "Joe's Software Emporium and Bait-n-Tackle" sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. (Yes, both sorts of errors happen all the time, and people who have been burnt once usually want to avoid a second one...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From adrian at creative.net.au Wed Feb 18 14:18:51 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 19 Feb 2009 05:18:51 +0900 Subject: IPv6 Confusion In-Reply-To: <499C6745.3000709@brightok.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> Message-ID: <20090218201851.GJ14136@skywalker.creative.net.au> On Wed, Feb 18, 2009, Jack Bates wrote: > Kevin Loch wrote: > >Just how DO we get the message to the IETF that we need all the tools we > >have in v4 (DHCP, VRRP, etc) to work with RA turned off? > > You don't, because there isn't really a technical reason for turning off > RA. RA is used as a starting point. It can push you to DHCPv6 or any Welcome to the 2009 internet. I hate to say it, but the "technical only" argument belongs back in the era I got involved in this junk, mid-1990's. If the things stopping corporate adoption are A, B, and C (eg, DHCPv6 style host management, firewall and l2/l3 filter set parity (eg, cisco port lockdown features, I forget all of the crap involved there), and lack of parity in various application support) and the academic community keeps shouting out "but damnit, our dogfood is better!", then you're going to lose. Being told by a group of network-y people that "our dogfood is better" sounds to me like the days where telco's kept saying "this IP stuff is crap, our ATM/FR "dogfood" is better, why would you deploy IP end to end?" Its amusing. Seriously. Someone needs to draw up some parallels between IPv6 adoption/advocacy and ATM/FR/ISDN "stuff" versus IP(v4) "adoption" back in the mid to late 1990's. I'd certainly have a laugh. my 2c, or 1.24c AUD; Adrian From aredridel at nbtsc.org Wed Feb 18 14:22:03 2009 From: aredridel at nbtsc.org (Aria Stewart) Date: Wed, 18 Feb 2009 13:22:03 -0700 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: On Feb 18, 2009, at 1:15 PM, Randy Bush wrote: >> What operational reasons are there for working with RA turned off? > > networks with visitors have shown a serious problem with rouge RAs Does that get better with RAs from the good routers turned off? Aria Stewart aredridel at nbtsc.org -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2318 bytes Desc: not available URL: From owen at delong.com Wed Feb 18 14:22:04 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Feb 2009 12:22:04 -0800 Subject: IPv6 Confusion In-Reply-To: <499C6745.3000709@brightok.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> Message-ID: <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> On Feb 18, 2009, at 11:53 AM, Jack Bates wrote: > Kevin Loch wrote: >> Just how DO we get the message to the IETF that we need all the >> tools we >> have in v4 (DHCP, VRRP, etc) to work with RA turned off? > > You don't, because there isn't really a technical reason for turning > off RA. RA is used as a starting point. It can push you to DHCPv6 or > any number of other options (such as SLAAC). The same argument goes > for multicast versus broadcast. The idea is to add an extra level > that allows for better manipulation and versatility. > There is a reason for turning off RA and the IETF (and you) just don't seem to get it. There are real world situations in which not all routers are created equal and it is important for the DHCP server to tell the correct host which router to use for default. There are also a number of security issues available in the "Just trust some unsolicited broadcast about where to send all your network traffic." approach to host bootstrapping that bother some people. We can argue all you want about how pathological these cases are, but, the fact remains that trusting some unsolicited broadcast from a device claiming to be a router as your starting point isn't viable in a number of real world installations and an alternative needs to be made available. > Of course, better support and vendor implementation of all the > different options would be nice. > Sure, but, so would DHCP functionality equivalent to what we have in IPv4. If you want SLAAC or RA or whatever, more power to you. Some installations do not. They want DHCP equivalent functionality with the same security model. > Most networks have broadcast controls that are mostly vendor > specific hacks. Now they'll have multicast controls, which is good > to have anyways. > This assumes a lot, but, even if it's true, it doesn't change the fact that some organizations like the existing DHCP model and there's no reason not to provide equivalent functionality in IPv6. Owen From nanog at daork.net Wed Feb 18 14:23:59 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 09:23:59 +1300 Subject: IPv6 Confusion In-Reply-To: <20090218200854.GR24542@angus.ind.WPI.EDU> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218200854.GR24542@angus.ind.WPI.EDU> Message-ID: <34E91D93-0EAB-4AD9-AB9C-A2B385FD92DD@daork.net> On 19/02/2009, at 9:08 AM, Chuck Anderson wrote: > On Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: >>> >>> On 18/02/2009 19:39, Kevin Loch wrote: >>>> Just how DO we get the message to the IETF that we need all the >>>> tools we >>>> have in v4 (DHCP, VRRP, etc) to work with RA turned off? >> >> What operational reasons are there for working with RA turned off? > > I don't want any system to be able to get IPv6 addressing information > until the system has been identified in our central management system. > I also want the IPv6 address assignment to be made centrally. You must have missed my post asking people to be clear in their distinction between RA and SLAAC. I will re-cap: - RA does NOT give your host IPv6 addressing information. - SLAAC gives your host IPv6 addressing information. SLAAC data is carried in RA messages, as an OPTION. - Another RA OPTION is "use DHCPv6 to get addressing information". DHCPv6 can operate without RA now. You can send DHCPv6 requests to your local LAN before you get an RA message telling you to do so. This requires you to manually configure your host to do that. That sounds like a waste of time, when you can use RA messages to tell your hosts to use DHCPv6 to get addressing information. Of course, you DHCPv6 does not currently have an option for default router, so your need RA for that. Again, RA is not giving out addressing information, only "Hi, I am a router". I suspect this removes the desire for getting "VRRP" without RA as well for those of you wanting to use DHCPv6 for addressing - RA is not giving out addressing information, and is only giving out "Use DHCPv6" bits and a router address. -- Nathan Ward From nanog at daork.net Wed Feb 18 14:26:30 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 09:26:30 +1300 Subject: IPv6 Confusion In-Reply-To: <22995.1234988276@turing-police.cc.vt.edu> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <22995.1234988276@turing-police.cc.vt.edu> Message-ID: <1744F5DC-5E02-41DA-9473-4753A2898B8F@daork.net> On 19/02/2009, at 9:17 AM, Valdis.Kletnieks at vt.edu wrote: > 2) Some end-node box with a IPv6 stack from "Joe's Software Emporium > and > Bait-n-Tackle" sees an RA packet, and concludes that since RA and > DHCPv6 > are mutually exclusive, to ignore any DHCPv6 packets it sees, and > hilarity > ensues. They are not mutually exclusive, DHCPv6 *requires* RA. Or did you mean SLAAC? If you did, I am not sure that they are mutually exclusive - I see no reason for telling hosts a prefix to number out of (SLAAC), and also telling hosts to use DHCPv6. That actually seems like a good solution to a number of problems. -- Nathan Ward From raymond at prolocation.net Wed Feb 18 14:29:22 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 18 Feb 2009 21:29:22 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: Hi! >> networks with visitors have shown a serious problem with rouge RAs > Does that get better with RAs from the good routers turned off? > > Aria Stewart > aredridel at nbtsc.org Is there something like RA filtering on switches yet, so end users can be filtered? Just like the dhcp stuff thats available on most switches nowdays... ? Its as annoying as fake DHCP servers... Bye, Raymond. From bicknell at ufp.org Wed Feb 18 14:34:06 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Feb 2009 15:34:06 -0500 Subject: IPv6 Confusion In-Reply-To: <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: <20090218203406.GB4391@ussenterprise.ufp.org> In a message written on Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: > What operational reasons are there for working with RA turned off? Not picking on the original poster, as I have no idea if they would have any personal experience with this or not..... There was a kinder, gentler time when your Cisco IGS would run RIPv1 and spew forth a default route. Your SunOS boxes all ran routed by default, and received the default route. Which, quite frankly, looks a lot like how RA's work. After many people had entire campus networks brought down by misconfigured boxes, prankster students, rogue network intruders and boxes plugged into the wrong ports the operators of the world universally turned this junk off. It appears the IETF did not study these history lessons when designing IPv6 RA's. Now, even with our limited IPv6 deployment we find plenty of stories where the NANOG and IETF test networks are unusable for hours at a time due to misconfigured boxes, prankster students, rogue network intruders and boxes plugged into the wrong port. Allowing an UNAUTHENTICATED BROADCAST packet to determine where you send your traffic is insane. Rather than moving forward, this is a giantantic step backwards for security and reliability. It wouldn't be so bad if we could just turn it off. Indeed, in part you can. On a static LAN there is no need for RA's. Static IP the box, static default route, done and done. But, when DHCPv6 was developed the "great minds of the world" decided less functionality was better. There /IS NO OPTION/ to send a default route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! So the IETF and other great minds have totally removed the capability for operators to work around this problem. Thus we are doomed, for now, to IPv6 networks that regularly become unworkable for hours at a time. Brilliant design! -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From nanog at daork.net Wed Feb 18 14:39:10 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 09:39:10 +1300 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: <43043619-CC2E-4EAE-A150-5FD69CB6E525@daork.net> On 19/02/2009, at 9:15 AM, Randy Bush wrote: >> What operational reasons are there for working with RA turned off? > > networks with visitors have shown a serious problem with rouge RAs Networks with visitors have shown a serious problem with rogue DHCP servers. Networks with visitors that use DHCPv6 for address assignment will have the exact same problem if someone comes along with a rogue DHCPv6 server. You need to push your vendors for features to limit where RA messages and DHCPv6 messages can be sent from. Coming up with new ways to solve a problem with an already obvious solution (a solution that we have for an identical problem in IPv4) sounds like it would take longer to solve, and sounds like it would introduce even more confusion in to this space. If your ethernet equipment has the ability to filter on ethernet source/destination then you should be able to do this a little bit now. - Only allow messages to the all routers multicast address to go to the switch interfaces that have routers on them. - Only allow messages to the all DHCPv6 servers multicast address to go to the switch interfaces that have DHCPv6 servers or relays on them. If your ethernet equipment can do IPv6 L4 ACLs then that is even better, you can allow RA messages only from routers, and DHCPv6 responses only from DHCPv6 servers. Again, this is the same problem we have with DHCP in IPv4. The only difference is switch vendor support for filtering these messages. -- Nathan Ward From mike at mtcc.com Wed Feb 18 14:39:20 2009 From: mike at mtcc.com (Michael Thomas) Date: Wed, 18 Feb 2009 12:39:20 -0800 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> Message-ID: <499C71F8.4030800@mtcc.com> Mikael Abrahamsson wrote: > On Tue, 17 Feb 2009, Justin Shore wrote: > >> different vendors, I asked each of them about their IPv6 support and >> they all unanimously claimed that there was no demand for it from >> their customers. > > Well, this is just ignorance or a kind of a lie. There might be few > customers who are willing to treat IPv6 support as a showstopper, but > saying that there is no demand simply isn't true, it's just that they > can get away without IPv6 support right now. We all hear the same thing > when we ask for IPv6 support. From my experience in the v6 wars, the express aversion to "No Flag Day for Operators" makes an implicit "Flag Day for Vendors Instead". That is, the ipv4/networking world doesn't stop, so even a well intentioned business unit/group/whatever of pick-your-network-vendor is constantly treading the v6 water furiously and usually sinking. And of course, most BU's are at best sort of ambivalent about v6 unless it translates to $$$ the next quarter. Also: the operators from what I've seen are also sort of ambivalent too, so there's a catch-22: the operators don't want to deploy something that they can't deploy or manage, and vendors don't want to drop everything to get parity for something that isn't going to make next quarter's numbers. And as if it were just one quarter; you'd really be talking about a year of quarters to get to real parity. So, round it goes. As far as I can tell, we're pretty much destined to drive right over the address depletion cliff. It should make for great theater for those of us not in the vendor/operator community anymore, in that train-wreck kind of way. Has somebody made an IPv4 address depletion marque? Maybe we could put it next to the National Debt counter in Times Square. Mike From sthaug at nethelp.no Wed Feb 18 14:42:05 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 18 Feb 2009 21:42:05 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <1744F5DC-5E02-41DA-9473-4753A2898B8F@daork.net> References: <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <22995.1234988276@turing-police.cc.vt.edu> <1744F5DC-5E02-41DA-9473-4753A2898B8F@daork.net> Message-ID: <20090218.214205.41670905.sthaug@nethelp.no> > > 2) Some end-node box with a IPv6 stack from "Joe's Software Emporium > > and > > Bait-n-Tackle" sees an RA packet, and concludes that since RA and > > DHCPv6 > > are mutually exclusive, to ignore any DHCPv6 packets it sees, and > > hilarity > > ensues. > > > They are not mutually exclusive, DHCPv6 *requires* RA. In your previous Nanog message you said: > DHCPv6 can operate without RA now. Please make up your mind. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nanog at daork.net Wed Feb 18 14:44:38 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 09:44:38 +1300 Subject: IPv6 Confusion In-Reply-To: <20090218203406.GB4391@ussenterprise.ufp.org> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> Message-ID: <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> On 19/02/2009, at 9:34 AM, Leo Bicknell wrote: > Allowing an UNAUTHENTICATED BROADCAST packet to determine where you > send > your traffic is insane. Rather than moving forward, this is a > giantantic step backwards for security and reliability. I guess you don't use DHCP in IPv4 then. It seems there are lots of people who want auto configuration in IPv6 but who clearly do not do this in IPv4. That seems strange, to me. -- Nathan Ward From swmike at swm.pp.se Wed Feb 18 14:52:29 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 18 Feb 2009 21:52:29 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> Message-ID: On Thu, 19 Feb 2009, Nathan Ward wrote: > It seems there are lots of people who want auto configuration in IPv6 > but who clearly do not do this in IPv4. That seems strange, to me. "Everybody" uses DHCP in IPv4, it's just that there is functionality in the equipment we use to make sure it can only be received from certain places and we apply security based on snooping the DHCP traffic. So, the fact that "RA guard" isn't widely available is a showstopper for deploying native IPv6 in a lot of environments because it just can't be done in a secure manner. I am sure the equivalent measures can be implemented for IPv6, it's just that someone needs to do it, and it's a mystery to me how all these security functions aren't available from the IETF already. As said before, a lot of the security mechanisms involved in securing IPv4 hasn't been implemented in IPv6. -- Mikael Abrahamsson email: swmike at swm.pp.se From bicknell at ufp.org Wed Feb 18 14:53:54 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Feb 2009 15:53:54 -0500 Subject: IPv6 Confusion In-Reply-To: <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> Message-ID: <20090218205354.GA14504@ussenterprise.ufp.org> In a message written on Thu, Feb 19, 2009 at 09:44:38AM +1300, Nathan Ward wrote: > I guess you don't use DHCP in IPv4 then. No, you seem to think the failure mode is the same, and it is not. Let's walk through this: 1) 400 people get on the NANOG wireless network. 2) Mr 31337 comes along and puts up a rogue DHCP server. 3) All 400 people continue working just fine until their lease expires, which is likely after the conference ends. The 10 people who came in late get info from the rogue server, and troubleshooting ensues. Let's try with IPv6. 1) 400 people get on the NANOG wireless network. 2) Mr 31337 sends a rouge RA. 3) 400 people instantly loose network access. The 10 who come in late don't even bother to try and get on. So, with DHCP handing out a default route we have 10/400 down, with RA's we have 410/410 down. Bravo! Let me clear up something from the start; this is not security. If security is what you are after none of the solutions proffered so far work. Rather this is robust network design. A working device shouldn't run off and follow a new router in miliseconds like a lost puppy looking for a treat. This actually offers a lot of protection from stupidity though. Ever plug an IPv4 router into the wrong switch port accidently? What happened? Probably nothing; no one on the LAN used the port IP'ed in the wrong subnet. They ignored it. Try that with an IPv6 router. About 10 ms after you plug into the wrong port out goes an RA, the entire subnet ceases to function, and your phone lights up like a christmas tree. Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From nanog at daork.net Wed Feb 18 14:55:09 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 09:55:09 +1300 Subject: IPv6 Confusion In-Reply-To: <20090218.214205.41670905.sthaug@nethelp.no> References: <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <22995.1234988276@turing-police.cc.vt.edu> <1744F5DC-5E02-41DA-9473-4753A2898B8F@daork.net> <20090218.214205.41670905.sthaug@nethelp.no> Message-ID: On 19/02/2009, at 9:42 AM, sthaug at nethelp.no wrote: >>> 2) Some end-node box with a IPv6 stack from "Joe's Software Emporium >>> and >>> Bait-n-Tackle" sees an RA packet, and concludes that since RA and >>> DHCPv6 >>> are mutually exclusive, to ignore any DHCPv6 packets it sees, and >>> hilarity >>> ensues. >> >> >> They are not mutually exclusive, DHCPv6 *requires* RA. > > In your previous Nanog message you said: > >> DHCPv6 can operate without RA now. > > Please make up your mind. You are right, sorry for any confusion, I will clarify my comments. DHCPv6 can operate without RA, but you cannot get default route information right now. I believe there is a draft to add this option though. In most networks this is not practical, as many hosts with a DHCPv6 stack will send DHCPv6 requests only when RA messages tell them to us a DHCPv6 server. The DHCPv6 protocol does not require RA, however practical implementation of DHCPv6 for address assignment does. Better? :-) -- Nathan Ward From randy at psg.com Wed Feb 18 14:57:09 2009 From: randy at psg.com (Randy Bush) Date: Thu, 19 Feb 2009 05:57:09 +0900 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: >> networks with visitors have shown a serious problem with rogue RAs > Does that get better with RAs from the good routers turned off? no, need to turn off listeners in this case the problems in the discovery space are sufficient to be causing a bit of effort to go into painting security on ex post facto. randy From nanog at daork.net Wed Feb 18 15:00:48 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 10:00:48 +1300 Subject: IPv6 Confusion In-Reply-To: <20090218205354.GA14504@ussenterprise.ufp.org> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> <20090218205354.GA14504@ussenterprise.ufp.org> Message-ID: <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: > In a message written on Thu, Feb 19, 2009 at 09:44:38AM +1300, > Nathan Ward wrote: >> I guess you don't use DHCP in IPv4 then. > > No, you seem to think the failure mode is the same, and it is not. > > Let's walk through this: > > 1) 400 people get on the NANOG wireless network. > > 2) Mr 31337 comes along and puts up a rogue DHCP server. > > 3) All 400 people continue working just fine until their lease > expires, > which is likely after the conference ends. > > The 10 people who came in late get info from the rogue server, and > troubleshooting ensues. > > Let's try with IPv6. > > 1) 400 people get on the NANOG wireless network. > > 2) Mr 31337 sends a rouge RA. > > 3) 400 people instantly loose network access. > > The 10 who come in late don't even bother to try and get on. > > So, with DHCP handing out a default route we have 10/400 down, with > RA's > we have 410/410 down. Bravo! > > Let me clear up something from the start; this is not security. If > security is what you are after none of the solutions proffered so > far work. Rather this is robust network design. A working device > shouldn't run off and follow a new router in miliseconds like a > lost puppy looking for a treat. > > This actually offers a lot of protection from stupidity though. Ever > plug an IPv4 router into the wrong switch port accidently? What > happened? Probably nothing; no one on the LAN used the port IP'ed in > the wrong subnet. They ignored it. > > Try that with an IPv6 router. About 10 ms after you plug into the > wrong > port out goes an RA, the entire subnet ceases to function, and your > phone lights up like a christmas tree. > > Let me repeat, none of these solutions are secure. The IPv4/DHCP > model > is ROBUST, the RA/DHCPv6 model is NOT. Yup, understood. The point I am making is that the solution is still the same - filtering in ethernet devices. Perhaps there needs to be something written about detailed requirements for this so that people have something to point their switch/etc. vendors at when asking for compliance. I will write this up in the next day or two. I guess IETF is the right forum for publication of that. Is there something like this already that anyone knows of? -- Nathan Ward From dwcarder at wisc.edu Wed Feb 18 15:05:43 2009 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 18 Feb 2009 15:05:43 -0600 Subject: IPv6 Confusion In-Reply-To: <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> <20090218205354.GA14504@ussenterprise.ufp.org> <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> Message-ID: <3A0AD7D0-FBBB-4713-A1A2-49DE512AF7E7@wisc.edu> On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: > On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: >> >> Let me repeat, none of these solutions are secure. The IPv4/DHCP >> model >> is ROBUST, the RA/DHCPv6 model is NOT. > > The point I am making is that the solution is still the same - > filtering in ethernet devices. > > Perhaps there needs to be something written about detailed > requirements for this so that people have something to point their > switch/etc. vendors at when asking for compliance. I will write this > up in the next day or two. I guess IETF is the right forum for > publication of that. > > Is there something like this already that anyone knows of? http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt This is the last message I recall seeing in v6ops about it: "It seems to me that the L2 devices are welcome to perform whatever filtering they like regardless of any documents that might come from the IETF. Therefore, I'd like to see more pros/cons on this." http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01733.html Cheers, Dale From bicknell at ufp.org Wed Feb 18 15:07:39 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Feb 2009 16:07:39 -0500 Subject: IPv6 Confusion In-Reply-To: <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> References: <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> <20090218205354.GA14504@ussenterprise.ufp.org> <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> Message-ID: <20090218210739.GB14504@ussenterprise.ufp.org> In a message written on Thu, Feb 19, 2009 at 10:00:48AM +1300, Nathan Ward wrote: > The point I am making is that the solution is still the same - > filtering in ethernet devices. No. I agree that in some enviornments DHCPv4/DHCPv6/RA filtering are going to be a requirement. If I was running the NANOG network, or a campus network for college students I would insist on such. However, there are many enviornments where that is not a justified expense. At home I have a dumb, unmanaged switch which serves my family just fine. I'd rather like it that if I plug in an unconfigured router to configure it for something that it not take my wife offline. The DHCPv4 model works great for this, there are no issues and I don't need a managed switch. IPv6 takes that option away from me. My only option is an expensive upgrade to the switch and a bunch of manual configuration. DHCPv6 needs to be fixed before it is deployed. Dependance on RA's needs to be removed, and a standard option for a default route needs to be added. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From leen at consolejunkie.net Wed Feb 18 15:08:04 2009 From: leen at consolejunkie.net (Leen Besselink) Date: Wed, 18 Feb 2009 22:08:04 +0100 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: <499C78B4.80604@consolejunkie.net> Raymond Dijkxhoorn wrote: > Hi! > Hi, >>> networks with visitors have shown a serious problem with rouge RAs > >> Does that get better with RAs from the good routers turned off? >> >> Aria Stewart >> aredridel at nbtsc.org > > Is there something like RA filtering on switches yet, so end users can > be filtered? Just like the dhcp stuff thats available on most switches > nowdays... ? > > Its as annoying as fake DHCP servers... > When I asked about this on an other list someone suggested RA-guard is what is supposed to be the solution: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 ? Not sure about implementations though, haven't had the time to check yet. > Bye, > Raymond. > > See you again, Leen. From kloch at kl.net Wed Feb 18 15:11:40 2009 From: kloch at kl.net (Kevin Loch) Date: Wed, 18 Feb 2009 16:11:40 -0500 Subject: IPv6 Confusion In-Reply-To: <20090218203406.GB4391@ussenterprise.ufp.org> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> Message-ID: <499C798C.6050001@kl.net> Leo Bicknell wrote: > > It wouldn't be so bad if we could just turn it off. Indeed, in > part you can. On a static LAN there is no need for RA's. Static > IP the box, static default route, done and done. > VRRPv6 however is relevant to static environments and also needs to (optionally) work with RA turned off. - Kevin From joelja at bogus.com Wed Feb 18 15:11:36 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 18 Feb 2009 13:11:36 -0800 Subject: IPv6 Confusion In-Reply-To: <3A0AD7D0-FBBB-4713-A1A2-49DE512AF7E7@wisc.edu> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> <20090218205354.GA14504@ussenterprise.ufp.org> <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> <3A0AD7D0-FBBB-4713-A1A2-49DE512AF7E7@wisc.edu> Message-ID: <499C7988.70803@bogus.com> Dale W. Carder wrote: > > On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: >> On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: >>> >>> Let me repeat, none of these solutions are secure. The IPv4/DHCP model >>> is ROBUST, the RA/DHCPv6 model is NOT. >> >> The point I am making is that the solution is still the same - >> filtering in ethernet devices. >> >> Perhaps there needs to be something written about detailed >> requirements for this so that people have something to point their >> switch/etc. vendors at when asking for compliance. I will write this >> up in the next day or two. I guess IETF is the right forum for >> publication of that. >> >> Is there something like this already that anyone knows of? > > > http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt > > This is the last message I recall seeing in v6ops about it: > > "It seems to me that the L2 devices are welcome to perform > whatever filtering they like regardless of any documents > that might come from the IETF. Therefore, I'd like to see > more pros/cons on this." > http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01733.html There is also: http://tools.ietf.org/html/draft-vandevelde-v6ops-ra-guard-01 > Cheers, > Dale > From alh-ietf at tndh.net Wed Feb 18 15:13:50 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 18 Feb 2009 13:13:50 -0800 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> Message-ID: <072401c9920d$cb823cb0$6286b610$@net> David Conrad wrote: > Tony, > > On Feb 17, 2009, at 12:17 PM, Tony Hain wrote: > > This being a list of network engineers, there is a strong bias > > toward tools > > that allow explicit management of the network. This is a fine > > position, and > > those tools need to exist. There are others that don't want, or need > > to know > > about every bit on the wire, where 'as much automation as possible' > > is the > > right set of tools. > > No question. However, as this is a list of network engineers who are > the folks who need to deploy IPv6 in order for others who may not care > about every bit on the wire to make (non-internal) use of it, I'd > think the bias displayed here something that might carry some weight. Automated tunneling works around those who choose not to deploy native support. > > > Infighting at the IETF kept the RA from informing the > > end systems about DNS, and kept DHCPv6 from informing them about > their > > router. The result is that you have to do both DHCP & RA, when each > > should > > be capable of working without the other. > > Yeah. Rants about the IETF should probably be directed elsewhere. That was not a rant, just an informational observation. > > > As far as dnssec, while the question is valid, blaming the IPv6 > > design for > > not considering something that 10+ years later is still not > > deployed/deployable, is a bit of a stretch. > > Uh, no. That's not what I was saying. I was saying that stateless > auto-configuration made certain assumptions about how naming and > addressing worked that weren't necessarily well thought out (clients > updating the reverse directly in a DNSSEC-signed environment was just > an example). Perhaps it's just me, but it feels like there was a > massive case of NIH syndrome in the IPv6 working groups that network > operators are now paying the price for. However, as I said, rants > about the IETF should probably be directed elsewhere. Actually this should be flipped as a rant against the *nog community. If you didn't participate in defining it, you can't complain about the outcome. The only way the IETF works well is with an active feedback loop that injects operational reality into the process. That used to exist in the joman WG, but stopped when the *nogs splintered off and stopped participating. I can already hear Randy complaining about being shouted down, and yes that happens, but that is really a call for -more- active voices, not disengagement. The bottom line is, if you want something to be defined in a way that works for you, you have to participate in the definition. > > >> Or, we simply continue down the path of more NATv4. > > While this is the popular position, those that have thought about it > > realize > > that what works for natv4 at the edge, does not work when that nat > > is moved > > toward the core. > > Yeah, multi-layer NAT sucks. I was amazed when I was speaking with > some African ISPs that had to go this way today because their telecoms > regulatory regime required them to obtain addresses from the national > PTT and that PTT only gave them a single address. I would argue that > if we want to avoid this outcome (and make no mistake, there are those > who like this outcome as it means end users are only content > consumers, which fits into their desired business models much more > nicely), we need to make IPv6 look more like IPv4 so that network > operators, end users, content providers, network application > developers, etc., have minimal change in what they do, how they do it, > or how they pay for it. Part of that is getting familiar tools (e.g., > DHCP, customer provisioning, management, etc.) working the way it > works in IPv4. Taking advantage of all the neato features IPv6 might > provide can come later. People have to stand up and put money on the table if they expect things to get fixed. The working parts of IPv6 that exist are due to the ISPs in Japan and the US DoD putting their money where their mouth is, and they got what they needed. The *nog community appears to be holding their breath waiting for 1:1 parity before they start, which will never happen. > > However, I have a sneaking suspicion it might already be too late... CGN will be deployed, but can be used as a tool to wean customers off of IPv4. If the world goes the way of current-price==IPv6+CGN, with IPv6+publicIPv4 costing substantially more, there will be a drop off in use of IPv4 because the CGN breaks lots of stuff and people won't pay extra to work around it for any longer than they need to. Tony From bicknell at ufp.org Wed Feb 18 15:15:53 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Feb 2009 16:15:53 -0500 Subject: IPv6 Confusion In-Reply-To: <499C798C.6050001@kl.net> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <499C798C.6050001@kl.net> Message-ID: <20090218211553.GC14504@ussenterprise.ufp.org> In a message written on Wed, Feb 18, 2009 at 04:11:40PM -0500, Kevin Loch wrote: > Leo Bicknell wrote: > >It wouldn't be so bad if we could just turn it off. Indeed, in > >part you can. On a static LAN there is no need for RA's. Static > >IP the box, static default route, done and done. > > > > VRRPv6 however is relevant to static environments and also needs to > (optionally) work with RA turned off. Ah yes, another tagent, but absolutely. VRRPv6 is needed not only because you may want to go 100% static, but also because VRRP can do things like tracking upstream interfaces that RA cannot do. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From alh-ietf at tndh.net Wed Feb 18 15:20:59 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 18 Feb 2009 13:20:59 -0800 Subject: IPv6 Confusion In-Reply-To: <499B97C5.9020601@justinshore.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> Message-ID: <072501c9920e$cba7f7b0$62f7e710$@net> Justin Shore wrote: > ... > At this point I'm looking at doing 6to4 tunnels far into the future. You can forget that, as CGN will break 6to4. Get used to teredo (miredo), and if that is impeded don't be surprised when IPv6 over SOAP shows up. Tony From jbates at brightok.net Wed Feb 18 15:29:27 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 18 Feb 2009 15:29:27 -0600 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> Message-ID: <499C7DB7.2040009@brightok.net> Raymond Dijkxhoorn wrote: > Is there something like RA filtering on switches yet, so end users can > be filtered? Just like the dhcp stuff thats available on most switches > nowdays... ? > > Its as annoying as fake DHCP servers... Per customer VLAN isolation (common to solve DHCP server issues). You can also perform *some* filtering today for multicast addresses, but not the specific packets themselves from what I've seen. This is a big implementation change. I've had lengthy discussions with the DSLAM vendors who said, "VLANs are stupid and as bad as PVCs," about their ability to filter RAs and DHCPv6. -Jack From alh-ietf at tndh.net Wed Feb 18 15:36:13 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 18 Feb 2009 13:36:13 -0800 Subject: IPv6 Confusion In-Reply-To: <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> Message-ID: <074e01c99210$ec6c6ab0$c5454010$@net> Owen DeLong wrote: > ... > If you want SLAAC or RA or whatever, more power to you. Some > installations > do not. They want DHCP equivalent functionality with the same > security model. It is always amusing when people equate DHCP with security... Outside of that, I do agree with you that the operational model around DHCP needs to be complete and stand-alone, just as the RA model needs to be. Right now neither works stand-alone. FWIW: there is SEND (RFC 3971) to deal with rouge RA's and other miscreant behavior. Implementations have been slow to come to market because network operators are not demanding it from their vendors. Tony From alh-ietf at tndh.net Wed Feb 18 15:39:57 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 18 Feb 2009 13:39:57 -0800 Subject: IPv6 Confusion In-Reply-To: <20090218203406.GB4391@ussenterprise.ufp.org> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> Message-ID: <075b01c99211$71aa3810$54fea830$@net> Leo Bicknell wrote: > ... > But, when DHCPv6 was developed the "great minds of the world" decided > less functionality was better. There /IS NO OPTION/ to send a default > route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! > So the IETF and other great minds have totally removed the capability > for operators to work around this problem. No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Tony From adrian at creative.net.au Wed Feb 18 15:46:15 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 19 Feb 2009 06:46:15 +0900 Subject: IPv6 Confusion In-Reply-To: <075b01c99211$71aa3810$54fea830$@net> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> Message-ID: <20090218214615.GL14136@skywalker.creative.net.au> On Wed, Feb 18, 2009, Tony Hain wrote: > No, the decision was to not blindly import all the excess crap from IPv4. If > anyone has a reason to have a DHCPv6 option, all they need to do is specify > it. The fact that the *nog community stopped participating in the IETF has > resulted in the situation where functionality is missing, because nobody > stood up and did the work to make it happen. Please explain where you think "*nog" community is today representative at all of the wider scale IPv6 deployment issues across the world? I'm assuming IETF and ARIN/RIPE/APNIC/etc are busy talking to end-users rather than just ISPs about the issues facing IPv6 adoption. Am I mistaken or not? Adrian From joelja at bogus.com Wed Feb 18 15:55:07 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 18 Feb 2009 13:55:07 -0800 Subject: IPv6 Confusion In-Reply-To: <20090218214615.GL14136@skywalker.creative.net.au> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218214615.GL14136@skywalker.creative.net.au> Message-ID: <499C83BB.4070906@bogus.com> Adrian Chadd wrote: > On Wed, Feb 18, 2009, Tony Hain wrote: > >> No, the decision was to not blindly import all the excess crap from IPv4. If >> anyone has a reason to have a DHCPv6 option, all they need to do is specify >> it. The fact that the *nog community stopped participating in the IETF has >> resulted in the situation where functionality is missing, because nobody >> stood up and did the work to make it happen. > > Please explain where you think "*nog" community is today representative > at all of the wider scale IPv6 deployment issues across the world? > > I'm assuming IETF and ARIN/RIPE/APNIC/etc are busy talking to end-users > rather than just ISPs about the issues facing IPv6 adoption. Am I > mistaken or not? The end-users who come too three meetings a year and pay $635 to attend are a small and self-selecting bunch (there are some I would note)... The IETF is not in the business of product development of the sort that end-users would normally relate to. The RIRs have there respective stakeholders, some are end-users most are not. > > > Adrian > > From nanog at daork.net Wed Feb 18 16:06:10 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 11:06:10 +1300 Subject: IPv6 Confusion In-Reply-To: <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> Message-ID: On 19/02/2009, at 9:22 AM, Owen DeLong wrote: > There are also a number of security issues available in the "Just > trust some > unsolicited broadcast about where to send all your network traffic." > approach > to host bootstrapping that bother some people. So, those people don't use DHCP in IPv4 if this is a concern, so I'm guessing they are not hoping to use DHCPv6 either. Static configuration of IP addressing information and other configuration will work just fine for them. I wonder, do they use ARP? The things you are talking about are about protecting against misconfiguration, not about protecting against malicious people. > We can argue all you want about how pathological these cases are, but, > the fact remains that trusting some unsolicited broadcast from a > device > claiming to be a router as your starting point isn't viable in a > number of > real world installations and an alternative needs to be made > available. > >> Of course, better support and vendor implementation of all the >> different options would be nice. >> > Sure, but, so would DHCP functionality equivalent to what we have in > IPv4. > > If you want SLAAC or RA or whatever, more power to you. Some > installations > do not. They want DHCP equivalent functionality with the same > security model. SLAAC and DHCPv6 do not have different security models in the "host trusting the network" area. In terms of "network trusting the host", there is a bit I suppose, assuming you trust whatever MAC address and client identifier the host uses. >> Most networks have broadcast controls that are mostly vendor >> specific hacks. Now they'll have multicast controls, which is good >> to have anyways. >> > This assumes a lot, but, even if it's true, it doesn't change the > fact that some > organizations like the existing DHCP model and there's no reason not > to > provide equivalent functionality in IPv6. I would agree, if we did not have SLAAC. RA is needed to tell hosts which of SLAAC and DHCPv6 to use though. Perhaps a solution here is a DHCPv6 option that says "do not listen to RAs any more", so that once a host is on a network and has an address from DHCPv6, it does not get affected by devices sending rogue RAs. Perhaps there is an additional option that says "send an RS message and listen to RA when your renewing your DHCPv6 lease" to allow transition from DHCPv6 to SLAAC if the network wants to do that. That way, we get DHCPv6 vs. SLAAC selection when a host connects to the network without having to manually configure, and we get "IPv4 DHCP"-like behaviour. -- Nathan Ward From surfer at mauigateway.com Wed Feb 18 16:10:40 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 18 Feb 2009 14:10:40 -0800 Subject: McAfee/AT&T Issue Message-ID: <20090218141040.6E7D3E22@resin09.mta.everyone.net> --- mcalhoun at iodatacenters.com wrote: From: "Calhoun, Matthew" While I agree with all of your assessments, this traceroute was being provided to illustrate where traffic *appears* to be stopping when we are seeing the issue. It's intermittent, so some times we can reach the destination hosts (via HTTP, HTTPS, etc.) and sometimes we can't. When we can reach the destination hosts (via HTTP), the traceroute completes When we can't reach the destination hosts (via HTTP), the traceroute won't complete and the last hop is the host that I indicated in my previous post (12.118.225.22) ------------------------------------------------- It may be best to use tcptraceroute when it is and when it isn't working. It may help you evaluate where the trouble is occurring more efficiently. scott From nanog at daork.net Wed Feb 18 16:11:00 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 11:11:00 +1300 Subject: IPv6 Confusion In-Reply-To: <20090218210739.GB14504@ussenterprise.ufp.org> References: <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> <20090218205354.GA14504@ussenterprise.ufp.org> <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> <20090218210739.GB14504@ussenterprise.ufp.org> Message-ID: <385AF900-74D7-46C2-AD83-4973C928F31D@daork.net> On 19/02/2009, at 10:07 AM, Leo Bicknell wrote: > In a message written on Thu, Feb 19, 2009 at 10:00:48AM +1300, > Nathan Ward wrote: >> The point I am making is that the solution is still the same - >> filtering in ethernet devices. > > No. > > I agree that in some enviornments DHCPv4/DHCPv6/RA filtering are > going to be a requirement. If I was running the NANOG network, or > a campus network for college students I would insist on such. > > However, there are many enviornments where that is not a justified > expense. At home I have a dumb, unmanaged switch which serves my > family just fine. I'd rather like it that if I plug in an > unconfigured > router to configure it for something that it not take my wife > offline. The DHCPv4 model works great for this, there are no issues > and I don't need a managed switch. Perhaps, and I am thinking out loud here, "SOHO" switches could include code to allow RA messages only from their "uplink" port, and wireless APs only from their "Ethernet" port. That doesn't require full understanding of IPv6, it would be trivial to code matching about 6 different bytes. Maybe throw a physical switch labelled "Router this way" on the side of the box just like the "crossover" toggle switches. Sure, this would not work for every situation, but it would do fine for a large number of home networking environments. Also perhaps the DHCPv6 thing I talked about in my message I just sent - the ignore RA option. > IPv6 takes that option away from me. My only option is an expensive > upgrade to the switch and a bunch of manual configuration. > > DHCPv6 needs to be fixed before it is deployed. Dependance on RA's > needs to be removed, and a standard option for a default route needs > to be added. It will be good to see your support in IETF for drafts that are proposing this! -- Nathan Ward From bicknell at ufp.org Wed Feb 18 16:11:01 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Feb 2009 17:11:01 -0500 Subject: IPv6 Confusion In-Reply-To: <075b01c99211$71aa3810$54fea830$@net> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> Message-ID: <20090218221101.GA17868@ussenterprise.ufp.org> In a message written on Wed, Feb 18, 2009 at 01:39:57PM -0800, Tony Hain wrote: > No, the decision was to not blindly import all the excess crap from IPv4. If > anyone has a reason to have a DHCPv6 option, all they need to do is specify > it. The fact that the *nog community stopped participating in the IETF has > resulted in the situation where functionality is missing, because nobody > stood up and did the work to make it happen. The last time I "participated" a working group chair told me "operators don't know what they are talking about" and went on to say they should be ignored. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Rod.Beck at hiberniaatlantic.com Wed Feb 18 16:12:02 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 18 Feb 2009 22:12:02 -0000 Subject: Greedy Routing References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net><499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net><0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB9F6B71@bert.HiberniaAtlantic.local> http://www.physorg.com/news154093231.html Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com From dts at senie.com Wed Feb 18 16:13:08 2009 From: dts at senie.com (Daniel Senie) Date: Wed, 18 Feb 2009 17:13:08 -0500 Subject: IPv6 Confusion In-Reply-To: <075b01c99211$71aa3810$54fea830$@net> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> Message-ID: <499C87F4.2000401@senie.com> Tony Hain wrote: > Leo Bicknell wrote: >> ... >> But, when DHCPv6 was developed the "great minds of the world" decided >> less functionality was better. There /IS NO OPTION/ to send a default >> route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! >> So the IETF and other great minds have totally removed the capability >> for operators to work around this problem. > > No, the decision was to not blindly import all the excess crap from IPv4. If > anyone has a reason to have a DHCPv6 option, all they need to do is specify > it. The fact that the *nog community stopped participating in the IETF has > resulted in the situation where functionality is missing, because nobody > stood up and did the work to make it happen. Because clearly everything done in IPv4 space was crap, or should be assumed to be crap. Therefore, everything that's been worked out and made to function well in the last 25+ years in IPv4 space should be tossed and re-engineered. OSI anyone? The point, which seems to elude many, is that rightly or wrongly there is an assumption that going from IPv4 to IPv6 should not involve a step back in time, not on security, not on central configuration capability, not on the ability to multihome, and so forth. The rude awakening is that the IPv6 evangelists insisting everyone should "get with the program" failed to understand that the community at large would expect equivalent or better functionality. Ultimately the only bit of light emerging above all the heat generated by this thread is a simple observation: "Engineers make lousy salespeople." -- ----------------------------------------------------------------- Daniel Senie dts at senie.com Amaranth Networks Inc. http://www.amaranth.com Kindness in words creates confidence. Kindness in thinking creates profoundness. Kindness in giving creates love. -- Lao Tsu From adrian at creative.net.au Wed Feb 18 16:20:41 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 19 Feb 2009 07:20:41 +0900 Subject: IPv6 Confusion In-Reply-To: References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> Message-ID: <20090218222041.GM14136@skywalker.creative.net.au> On Thu, Feb 19, 2009, Nathan Ward wrote: > So, those people don't use DHCP in IPv4 if this is a concern, so I'm > guessing they are not hoping to use DHCPv6 either. > Static configuration of IP addressing information and other > configuration will work just fine for them. > > I wonder, do they use ARP? In the corporate world, you get wonderful L2/L3 features in switches, such as: * helper address stuff, to run centralised DHCP servers * dhcp sniffing/filtering * per port L2/L3 filters * dynamic arp inspection which are used on corporate LANs to both build out scalable address management platforms (ie, no need to run a DHCP server on each subnet, nor one DHCP server with seperate vlan if's to provide service), control access and mitigate security risks. I don't know what the IPv6 LAN "snooping" functionality is across vendors but the last time I checked this out (say, 2-3 years ago) it was pretty lacking. > The things you are talking about are about protecting against > misconfiguration, not about protecting against malicious people. See above. Adrian From schnizlein at isoc.org Wed Feb 18 16:21:30 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Wed, 18 Feb 2009 17:21:30 -0500 Subject: IPv6 Confusion In-Reply-To: <20090218221101.GA17868@ussenterprise.ufp.org> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218221101.GA17868@ussenterprise.ufp.org> Message-ID: <802FDB38-D481-45D2-8889-2CBEA0695C3B@isoc.org> On 2009Feb18, at 5:11 PM, Leo Bicknell wrote: > In a message written on Wed, Feb 18, 2009 at 01:39:57PM -0800, Tony > Hain wrote: >> No, the decision was to not blindly import all the excess crap from >> IPv4. If >> anyone has a reason to have a DHCPv6 option, all they need to do is >> specify >> it. The fact that the *nog community stopped participating in the >> IETF has >> resulted in the situation where functionality is missing, because >> nobody >> stood up and did the work to make it happen. > > The last time I "participated" a working group chair told me > "operators don't know what they are talking about" and went on to > say they should be ignored. This is a problem to be fixed. If you like we can discuss the details of how to fix it in San Francisco next month. John From wavetossed at googlemail.com Wed Feb 18 16:29:53 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 18 Feb 2009 22:29:53 +0000 Subject: IPv6 Confusion In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> Message-ID: <877585b00902181429r2e4d424do43817a369bc3abf0@mail.gmail.com> > I have Googled and read RFCs about IPv6 for HOURS. Hours? Is that all? > How does IPv6 addressing work? The best overview that I know of is here: It is mostly summarised from a thread on the NANOG mailing list. Don't assume that an IPv4 expert can give you good advice on IPv6. Many IPv4 experts have only a marginal understanding of v6. Do your own research. Go to Barnes and Noble, spend a couple of months with Google, and check out the other pages on the website above. --Michael Dillon From alh-ietf at tndh.net Wed Feb 18 16:30:38 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 18 Feb 2009 14:30:38 -0800 Subject: IPv6 Confusion In-Reply-To: <499C87F4.2000401@senie.com> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <499C87F4.2000401@senie.com> Message-ID: <07cd01c99218$865975d0$930c6170$@net> Daniel Senie wrote: > >... > > No, the decision was to not blindly import all the excess crap from > IPv4. If > > anyone has a reason to have a DHCPv6 option, all they need to do is > specify > > it. The fact that the *nog community stopped participating in the > IETF has > > resulted in the situation where functionality is missing, because > nobody > > stood up and did the work to make it happen. > > Because clearly everything done in IPv4 space was crap, or should be > assumed to be crap. Therefore, everything that's been worked out and > made to function well in the last 25+ years in IPv4 space should be > tossed and re-engineered. OSI anyone? That is not what the decision said. The point was that the DHCP WG was not going to decide for you what was necessary or appropriate to carry forward. Rather than add baggage that nobody actually uses, there is nothing until someone says 'I need that'. Never mind that DHCP wasn't defined when the IPng work started, and wasn't in widespread use yet when DHCPv6 was being started ... > > The point, which seems to elude many, is that rightly or wrongly there > is an assumption that going from IPv4 to IPv6 should not involve a step > back in time, not on security, not on central configuration > capability, > not on the ability to multihome, and so forth. The rude awakening is > that the IPv6 evangelists insisting everyone should "get with the > program" failed to understand that the community at large would expect > equivalent or better functionality. Yes people expect 1:1 functionality, but how many of them are stepping up to the table with $$$ to make that happen... In the US, it is only the DoD. In the ISP space, most of it comes from Japan. If you are not finding what you want, put money in front of a vendor and see what happens... ;) > > Ultimately the only bit of light emerging above all the heat generated > by this thread is a simple observation: "Engineers make lousy > salespeople." ;) Tony From alh-ietf at tndh.net Wed Feb 18 16:32:24 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 18 Feb 2009 14:32:24 -0800 Subject: IPv6 Confusion In-Reply-To: <20090218221101.GA17868@ussenterprise.ufp.org> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218221101.GA17868@ussenterprise.ufp.org> Message-ID: <07d401c99218$c5811010$50833030$@net> Leo Bicknell wrote: > ... > The last time I "participated" a working group chair told me "operators > don't know what they are talking about" and went on to say they should > be ignored. So did you believe him and stop participating? Seriously, the -ONLY- way the IETF can be effective is for the ops community to provide active feedback. If you don't provide input, don't be surprised when the output is not what you want. Tony From Valdis.Kletnieks at vt.edu Wed Feb 18 16:35:15 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 18 Feb 2009 17:35:15 -0500 Subject: Greedy Routing In-Reply-To: Your message of "Wed, 18 Feb 2009 22:12:02 GMT." <1E8B940C5E21014AB8BE70B975D40EDB9F6B71@bert.HiberniaAtlantic.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <1E8B940C5E21014AB8BE70B975D40EDB9F6B71@bert.HiberniaAtlantic.local> Message-ID: <31096.1234996515@turing-police.cc.vt.edu> On Wed, 18 Feb 2009 22:12:02 GMT, Rod Beck said: > http://www.physorg.com/news154093231.html >From the fine article: "In greedy routing, a node passes information to the neighboring node that is closest to the final destination in an abstract space called hidden metric space." Sounds suspiciously like "throw the packet at the router that's got the shortest AS path to the destination" doesn't it? You don't need to know the entire topology to know router X is 2 AS's closer to the dest than router Y once X and Y have been loaded with the "hidden metric space" known as a BGP update ;) I'm not sure this article is actually telling us anything we didn't already know. Now if there was a way to compute those distance metrics without global knowledge - if there was only an algorithm that only cared about what was "upstream" from a locally connected link and whether it was connected. Say, we could call it a link-state routing protocol.... Now if they were able to actually develop a link-state protocol that involved *only* local adjacency announcements and not flooded announcements, *that* would be something... But what I see here is "if somebody developed that, we'd be able to route more efficiently". Maybe there's some critical insight in the paper that Physorg managed to totally not mention, I dunno. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From nanog at daork.net Wed Feb 18 16:39:24 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 11:39:24 +1300 Subject: IPv6 Confusion In-Reply-To: <20090218222041.GM14136@skywalker.creative.net.au> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <20090218222041.GM14136@skywalker.creative.net.au> Message-ID: On 19/02/2009, at 11:20 AM, Adrian Chadd wrote: > On Thu, Feb 19, 2009, Nathan Ward wrote: > >> So, those people don't use DHCP in IPv4 if this is a concern, so I'm >> guessing they are not hoping to use DHCPv6 either. >> Static configuration of IP addressing information and other >> configuration will work just fine for them. >> >> I wonder, do they use ARP? > > In the corporate world, you get wonderful L2/L3 features in switches, > such as: > > * helper address stuff, to run centralised DHCP servers > * dhcp sniffing/filtering > * per port L2/L3 filters > * dynamic arp inspection > > which are used on corporate LANs to both build out scalable address > management platforms (ie, no need to run a DHCP server on each subnet, > nor one DHCP server with seperate vlan if's to provide service), > control > access and mitigate security risks. > > I don't know what the IPv6 LAN "snooping" functionality is across > vendors but the last time I checked this out (say, 2-3 years ago) > it was pretty lacking. Yep. You asked your vendors to support equivalent IPv6 things at the time though, so when you roll out IPv6 the support is ready, right? The point is that these deficiencies exist in IPv4, and I'm not sure how you would solve them in IPv6 (assuming you can make all the changes you want, and get instant industry-wide support) any better than you solve them in IPv4. My view is that this is an ethernet switch thing, not a problem with the L3 protocols. Are there IETF documents on the above L2/L3 features for dealing with these problems in IPv4? I have not seen any. There probably should be some though.. >> The things you are talking about are about protecting against >> misconfiguration, not about protecting against malicious people. > > See above. Yep. -- Nathan Ward From bicknell at ufp.org Wed Feb 18 16:40:02 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Feb 2009 17:40:02 -0500 Subject: IPv6 Confusion In-Reply-To: <07d401c99218$c5811010$50833030$@net> References: <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218221101.GA17868@ussenterprise.ufp.org> <07d401c99218$c5811010$50833030$@net> Message-ID: <20090218224001.GA19041@ussenterprise.ufp.org> In a message written on Wed, Feb 18, 2009 at 02:32:24PM -0800, Tony Hain wrote: > So did you believe him and stop participating? Seriously, the -ONLY- way > the IETF can be effective is for the ops community to provide active > feedback. If you don't provide input, don't be surprised when the output is > not what you want. Oh yes, because he's not the only one who's said that to me (although he was the most direct), and because others I know in the operator community have gotten the same response. The sad fact is for most operators it is easier to convince your vendor to generate a propretary feature and solve your problem; hoping they will back port it through the IETF so it is a standard. How many years did HSRP have to exist before VRRP was defined? And let me ask you this question, why do the operators have to go to the IETF? Many of us have, and tried. I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. If the IETF wants this to be a two way street actions would speak louder than words. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stephen at sprunk.org Wed Feb 18 16:45:13 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 18 Feb 2009 16:45:13 -0600 Subject: IPv6 Confusion In-Reply-To: <7CE89ED4-E20A-47DF-8EA7-5217B7141AF4@virtualized.org> References: <20090218181951.EEC111CC09@ptavv.es.net> <7CE89ED4-E20A-47DF-8EA7-5217B7141AF4@virtualized.org> Message-ID: <499C8F79.2000801@sprunk.org> David Conrad wrote: > If a vendor sales person indicates they are getting no requests for > IPv6 support in their products (which would clearly be false since > presumably you are requesting IPv6 support), It's hard to imagine a vendor that is getting _no_ requests for IPv6 support these days; every RFP I see has it listed as an "optional requirement". However, development priorities are set not by requests but by the amount of business they'll lose if they /don't/ do something. Since IPv6 is not _mandatory_ to win deals in most cases, it's simply not getting done. And, of course, customers can't make it mandatory in an RFP until at least one vendor has implemented it, or they risk getting no qualified responses... I bet the latter is why the US DoD gave up on their hard IPv6 requirements and now simply mandates that products be "software upgradeable" to support IPv6... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From adrian at creative.net.au Wed Feb 18 16:50:54 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 19 Feb 2009 07:50:54 +0900 Subject: IPv6 Confusion In-Reply-To: References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <20090218222041.GM14136@skywalker.creative.net.au> Message-ID: <20090218225054.GA13120@skywalker.creative.net.au> On Thu, Feb 19, 2009, Nathan Ward wrote: > Yep. You asked your vendors to support equivalent IPv6 things at the > time though, so when you roll out IPv6 the support is ready, right? > > The point is that these deficiencies exist in IPv4, and I'm not sure > how you would solve them in IPv6 (assuming you can make all the > changes you want, and get instant industry-wide support) any better > than you solve them in IPv4. Who says the IPv6 solutions need to be better than IPv4? Adrian From joelja at bogus.com Wed Feb 18 16:57:48 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 18 Feb 2009 14:57:48 -0800 Subject: IPv6 Confusion In-Reply-To: <20090218224001.GA19041@ussenterprise.ufp.org> References: <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218221101.GA17868@ussenterprise.ufp.org> <07d401c99218$c5811010$50833030$@net> <20090218224001.GA19041@ussenterprise.ufp.org> Message-ID: <499C926C.8090400@bogus.com> Leo Bicknell wrote: > I can't think of a single working > group chair/co-chair that's ever presented at NANOG and asked for > feedback. Then were busy staring at your laptop and not watching the program. > If the IETF wants this to be a two way street actions would > speak louder than words. In that I could not agree more. From smb at cs.columbia.edu Wed Feb 18 17:00:34 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 18 Feb 2009 18:00:34 -0500 Subject: IPv6 Confusion In-Reply-To: <20090218224001.GA19041@ussenterprise.ufp.org> References: <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218221101.GA17868@ussenterprise.ufp.org> <07d401c99218$c5811010$50833030$@net> <20090218224001.GA19041@ussenterprise.ufp.org> Message-ID: <20090218180034.4e734e58@cs.columbia.edu> On Wed, 18 Feb 2009 17:40:02 -0500 Leo Bicknell wrote: > And let me ask you this question, why do the operators have to go to > the IETF? Many of us have, and tried. I can't think of a single > working group chair/co-chair that's ever presented at NANOG and asked > for feedback. If the IETF wants this to be a two way street actions > would speak louder than words. > Without going into details, I have spoken at NANOG, and I've been a WG chair, an IAB member, and an AD. Randy has been an AD. I can think of several other ADs and IAB members who have frequently attended NANOG. I'm not saying it's perfect -- far from it! -- but the issue isn't nearly that one-sided. --Steve Bellovin, http://www.cs.columbia.edu/~smb From deepak at ai.net Wed Feb 18 17:01:06 2009 From: deepak at ai.net (Deepak Jain) Date: Wed, 18 Feb 2009 18:01:06 -0500 Subject: Greedy Routing In-Reply-To: <31096.1234996515@turing-police.cc.vt.edu> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <1E8B940C5E21014AB8BE70B975D40EDB9F6B71@bert.HiberniaAtlantic.local> <31096.1234996515@turing-police.cc.vt.edu> Message-ID: > > Maybe there's some critical insight in the paper that Physorg managed > to totally not mention, I dunno. I saw it the same way... " As the researchers explain, some types of networks are not navigable. For instance, if the probability that two nodes are linked doesn't depend on the metric distance between them, then such networks are difficult to navigate, as there is no way to choose one node over another based on distance. But when there is a connection between the link existence probability and the hidden distance between nodes, metric distances can help to navigate the network, i.e., such networks are "navigable."" If your network doesn't calculate or use metrics or weights, or AS path lengths... then you are not able to throw packets like fairy dust to their intended destination. Worse, if you use metrics unrelated to distance (like link cost) you could actually send your packets the wrong way. It's funny, but I think they said that their math shows that the Internet works to generally route packets (to a shorter path) than other possible paths. I'm sure that will come as a surprise to all of us. Deepak Jain AiNET From jsw at inconcepts.biz Wed Feb 18 17:26:27 2009 From: jsw at inconcepts.biz (Jeff S Wheeler) Date: Wed, 18 Feb 2009 18:26:27 -0500 Subject: IPv6 Confusion In-Reply-To: <499C8F79.2000801@sprunk.org> References: <20090218181951.EEC111CC09@ptavv.es.net> <7CE89ED4-E20A-47DF-8EA7-5217B7141AF4@virtualized.org> <499C8F79.2000801@sprunk.org> Message-ID: <1234999587.17985.867.camel@guardian.inconcepts.net> On Wed, 2009-02-18 at 16:45 -0600, Stephen Sprunk wrote: > I bet the latter is why the US DoD gave up on their hard IPv6 > requirements and now simply mandates that products be "software > upgradeable" to support IPv6... I think you will agree that vendor support for IPv6 has come a long way in the past few years. Even Force10 is shipping v6 capable hardware! ;) The price of software licenses for v6 (when required) is now a figure we think about when proposing new equipment. Even customers who do not have a v6 strategy are at least conscious of the fact that they will need it eventually, and may rather pay a little more for a box that includes the feature now, than spend more on a license that includes things they don't need later on. I think, for example, that Juniper is making a mistake by rolling v6 capability into a license that also includes BGP and ISIS on some platforms. Cisco is guilty of this as well. I am not necessarily advocating that v6 must be a basic feature on every new box; but I don't think it is correct to force customers to buy a license that includes a lot of other bells and whistles just to get v6. It could be a separate cost. - j From tme at multicasttech.com Wed Feb 18 17:35:58 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 18 Feb 2009 18:35:58 -0500 Subject: IPv6 Confusion In-Reply-To: <499C926C.8090400@bogus.com> References: <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218221101.GA17868@ussenterprise.ufp.org> <07d401c99218$c5811010$50833030$@net> <20090218224001.GA19041@ussenterprise.ufp.org> <499C926C.8090400@bogus.com> Message-ID: On Feb 18, 2009, at 5:57 PM, Joel Jaeggli wrote: > Leo Bicknell wrote: >> I can't think of a single working >> group chair/co-chair that's ever presented at NANOG and asked for >> feedback. > > Then were busy staring at your laptop and not watching the program. > >> If the IETF wants this to be a two way street actions would >> speak louder than words. > > In that I could not agree more. > I am co-chair of Mboned, L3VPN and FecFrame and would be glad to present on any or all of these if there a desire for a status report or to provide feedback on these areas. Regards Marshall From mmc at internode.com.au Wed Feb 18 17:37:30 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 19 Feb 2009 10:07:30 +1030 Subject: IPv6 Confusion In-Reply-To: <20090218225054.GA13120@skywalker.creative.net.au> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <20090218222041.GM14136@skywalker.creative.net.au> <20090218225054.GA13120@skywalker.creative.net.au> Message-ID: <69DA0224-69AD-4D58-8097-5BC2946FA0E6@internode.com.au> On 19/02/2009, at 9:20 AM, Adrian Chadd wrote: >> > > Who says the IPv6 solutions need to be better than IPv4? Actually, with IPv6 I'd like _a_ solution that at least is viable and works - it's doesn't have to be the final one, it doesn't have to even be as good as IPv4, it just has to be able to be productized for delivery to real customers like my mum and dad and not the 1337-g33ks from Planet Geekdom. Given it's 2009 and IPv6 has been around, for, well, sometime, I find it as someone trying to implement IPv6 on a large general scale for broadband that there's still a lot of "proposals", "drafts", general misunderstanding and turf wars over basic stuff like how the heck we're going to give IPv6 addresses to broadband customers. I understand that there are lot of people reading this who've spent time and effort trying to make forward progress and I salute you all, but come on - let's try and make this work so that all the lovely IPv6 stuff can be given to the masses rather than forcing us to spend our lives squabbling about how evil NAT is at an SP level. Does anyone here _really_ want Geoff Houston to be right about deploying IPv6? MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks From jake at nobistech.net Wed Feb 18 17:39:44 2009 From: jake at nobistech.net (Jake Mertel) Date: Wed, 18 Feb 2009 17:39:44 -0600 Subject: Greedy Routing In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <1E8B940C5E21014AB8BE70B975D40EDB9F6B71@bert.HiberniaAtlantic.local> <31096.1234996515@turing-police.cc.vt.edu> Message-ID: <18DCD1A1EB78DF41B564964698425DE201207D3E69@srv372.exchange.nobistech.net> I had to laugh when reading... This is how I think someone who doesn't "get" how the Internet works may try to re-explain what a researcher explained to them about how metrics influence the flow of traffic in BGP path selection. Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Wednesday, February 18, 2009 5:01 PM To: Valdis.Kletnieks at vt.edu; Rod Beck Cc: nanog list Subject: RE: Greedy Routing > > Maybe there's some critical insight in the paper that Physorg managed > to totally not mention, I dunno. I saw it the same way... " As the researchers explain, some types of networks are not navigable. For instance, if the probability that two nodes are linked doesn't depend on the metric distance between them, then such networks are difficult to navigate, as there is no way to choose one node over another based on distance. But when there is a connection between the link existence probability and the hidden distance between nodes, metric distances can help to navigate the network, i.e., such networks are "navigable."" If your network doesn't calculate or use metrics or weights, or AS path lengths... then you are not able to throw packets like fairy dust to their intended destination. Worse, if you use metrics unrelated to distance (like link cost) you could actually send your packets the wrong way. It's funny, but I think they said that their math shows that the Internet works to generally route packets (to a shorter path) than other possible paths. I'm sure that will come as a surprise to all of us. Deepak Jain AiNET From jbates at brightok.net Wed Feb 18 17:45:47 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 18 Feb 2009 17:45:47 -0600 Subject: IPv6 Confusion In-Reply-To: <20090218225054.GA13120@skywalker.creative.net.au> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <20090218222041.GM14136@skywalker.creative.net.au> <20090218225054.GA13120@skywalker.creative.net.au> Message-ID: <499C9DAB.9060706@brightok.net> Adrian Chadd wrote: > > Who says the IPv6 solutions need to be better than IPv4? > I think that IPv6 solutions will automatically be better than IPv4 based on the switch to multicast for handling things. That being said, I haven't seen the normal IPv4 solutions migrated to IPv6 as of yet in the products I currently use. I honestly believe that a majority of the debate is mute, in that IPv6 *has* some L2 security stuff written up (which I don't believe they did with IPv4). Once vendors implement them, things will be on par. The only issue I've heard of is that DHCPv6 doesn't support handing out a router, which is in draft (and DHCPv6 is very clear that it only covers a base set and additional RFCs will be necessary for more options). RA should still be the switch that says SLAAC or DHCPv6, even if it isn't used for the option of routing. As said elsewhere in the thread, vendors will do what they feel they need to do, with or without an RFC. IOS, for example, doesn't support IA_TA or IA_NA at this time. It's in the DHCPv6 spec, though. -Jack From aredridel at nbtsc.org Wed Feb 18 18:03:27 2009 From: aredridel at nbtsc.org (Aria Stewart) Date: Wed, 18 Feb 2009 17:03:27 -0700 Subject: IPv6 Confusion In-Reply-To: <20090218205354.GA14504@ussenterprise.ufp.org> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> <20090218205354.GA14504@ussenterprise.ufp.org> Message-ID: <72721CFD-6FF0-4C71-B4E2-2E3CB34E7334@nbtsc.org> On Feb 18, 2009, at 1:53 PM, Leo Bicknell wrote: > > Try that with an IPv6 router. About 10 ms after you plug into the > wrong > port out goes an RA, the entire subnet ceases to function, and your > phone lights up like a christmas tree. > > Let me repeat, none of these solutions are secure. The IPv4/DHCP > model > is ROBUST, the RA/DHCPv6 model is NOT. Depends -- the DHCP model also ceases to work, and some time later, when there's no cause and effect. When I've added a misconfigured router to my IPv6 network, I added a few prefixes, but since it never worked, it never got used. Multihoming and good address selection seems to be a real win there. Good router authentication would be a nice thing to have in both cases, though. Aria Stewart aredridel at nbtsc.org -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2318 bytes Desc: not available URL: From thegameiam at yahoo.com Wed Feb 18 18:05:14 2009 From: thegameiam at yahoo.com (David Barak) Date: Wed, 18 Feb 2009 16:05:14 -0800 (PST) Subject: IPv6 Confusion In-Reply-To: <20090218225054.GA13120@skywalker.creative.net.au> Message-ID: <420354.11589.qm@web31807.mail.mud.yahoo.com> If the IPv6 solutions are not going to be 'better' than v4, how about simply making sure that they are 'as good as' ipv4? Right now, I'd be hard pressed to think of a v6 function which is 'better' and I can think of a lot which are 'not as good as.' -David Barak Adrian Chadd wrote: > On Thu, Feb 19, 2009, Nathan Ward wrote: >> Yep. You asked your vendors to support equivalent IPv6 things at the >> time though, so when you roll out IPv6 the support is ready, right? >> >> The point is that these deficiencies exist in IPv4, and I'm not sure >> how you would solve them in IPv6 (assuming you can make all the >> changes you want, and get instant industry-wide support) any better >> than you solve them in IPv4. > Who says the IPv6 solutions need to be better than IPv4? > Adrian From justin at justinshore.com Wed Feb 18 18:50:55 2009 From: justin at justinshore.com (Justin Shore) Date: Wed, 18 Feb 2009 18:50:55 -0600 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> <5699373B-7F5B-4CD6-BF28-F9190D39AD72@virtualized.org> Message-ID: <499CACEF.10507@justinshore.com> Mikael Abrahamsson wrote: > Well, considering how very few vendors actually support IPv6, it's hard > to find proper competition. Even the companies who do support IPv6 very > well in some products, not all their BUs do on their own products (you > know who you are :P ). Even worse is when the BU charges an insane price ($40k for 20 GigE ports for example) for a license to give a piece of their equipment IPv6 capabilities. I'm looking at you ES20 linecards. Adoption of IPv6 would be better in my opinion if vendors didn't force us to pay a premium to use IPv6. It's hard enough to convince management that there is a need to implement IPv6. It's even harder when you tell them how much it costs. And when they ask what they're getting for their dollars, they are none to pleased to hear that the bulk of it is going to a damn license. Justin From nanog at daork.net Wed Feb 18 19:57:53 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Feb 2009 14:57:53 +1300 Subject: IPv6 Confusion In-Reply-To: <69DA0224-69AD-4D58-8097-5BC2946FA0E6@internode.com.au> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <20090218222041.GM14136@skywalker.creative.net.au> <20090218225054.GA13120@skywalker.creative.net.au> <69DA0224-69AD-4D58-8097-5BC2946FA0E6@internode.com.au> Message-ID: <68974159-E01C-4A2F-B4F6-17582F722BAF@daork.net> On 19/02/2009, at 12:37 PM, Matthew Moyle-Croft wrote: > > On 19/02/2009, at 9:20 AM, Adrian Chadd wrote: >>> >> >> Who says the IPv6 solutions need to be better than IPv4? > > Actually, with IPv6 I'd like _a_ solution that at least is viable > and works - it's doesn't have to be the final one, it doesn't have > to even be as good as IPv4, it just has to be able to be productized > for delivery to real customers like my mum and dad and not the 1337- > g33ks from Planet Geekdom. > > Given it's 2009 and IPv6 has been around, for, well, sometime, I > find it as someone trying to implement IPv6 on a large general scale > for broadband that there's still a lot of "proposals", "drafts", > general misunderstanding and turf wars over basic stuff like how the > heck we're going to give IPv6 addresses to broadband customers. > > I understand that there are lot of people reading this who've spent > time and effort trying to make forward progress and I salute you > all, but come on - let's try and make this work so that all the > lovely IPv6 stuff can be given to the masses rather than forcing us > to spend our lives squabbling about how evil NAT is at an SP level. > > Does anyone here _really_ want Geoff Houston to be right about > deploying IPv6? From other discussion with you, your main concern is vendor support for a few things, right? It might be a good idea to socialise these problems so we can get lots of people pushing vendors - even if they do not have as immediate requirements as you do, they will want to have the problems removed so when they *do* have immediate requirements they can go ahead and get it working. -- Nathan Ward From nrauhauser at gmail.com Wed Feb 18 20:06:55 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Wed, 18 Feb 2009 20:06:55 -0600 Subject: more AS prepend antics? Message-ID: <9515c62d0902181806n26ea551i3f767745a04555ce@mail.gmail.com> Why so many prepends from these folks? Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 received from 209.253.101.9: More than configured MAXAS-LIMIT Feb 18 20:03:07.361 CST: %BGP-6-ASPATH: Long AS path 1785 2516 2516 2516 2516 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 9597 9597 9597 9597 received from 209.253.101.9: More than configured MAXAS-LIMIT Feb 18 20:04:07.849 CST: %BGP-6-ASPATH: Long AS path 1785 3549 8966 8961 38193 38264 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 received from 209.253.101.9: More than configured MAXAS-LIMIT -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From randy at psg.com Wed Feb 18 20:46:34 2009 From: randy at psg.com (Randy Bush) Date: Thu, 19 Feb 2009 11:46:34 +0900 Subject: IPv6 Confusion In-Reply-To: <075b01c99211$71aa3810$54fea830$@net> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> Message-ID: > The fact that the *nog community stopped participating in the IETF has > resulted in the situation where functionality is missing, because nobody > stood up and did the work to make it happen. the ops gave up on the ietf because it did no good to participate. so the choice was spend the time accomplishing nothing or do something else with one's time. this is a slight exaggeration. it took me less than five years to get rid of NLAs, TLAs, ... wooo wooo! randy From randy at psg.com Wed Feb 18 20:52:26 2009 From: randy at psg.com (Randy Bush) Date: Thu, 19 Feb 2009 11:52:26 +0900 Subject: IPv6 Confusion In-Reply-To: <20090218224001.GA19041@ussenterprise.ufp.org> References: <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218221101.GA17868@ussenterprise.ufp.org> <07d401c99218$c5811010$50833030$@net> <20090218224001.GA19041@ussenterprise.ufp.org> Message-ID: > I can't think of a single working group chair/co-chair that's ever > presented at NANOG and asked for feedback. i did a number of times. so have others. otoh, all that gets pretty destroyed by a few self-inflated ietf wannabes presenting org charts of the ietf and explaining what the grown-ups do for the benefit of us poor peons. randy From kaeo at merike.com Wed Feb 18 20:58:08 2009 From: kaeo at merike.com (Merike Kaeo) Date: Wed, 18 Feb 2009 18:58:08 -0800 Subject: IPv6 Confusion In-Reply-To: <20090218180034.4e734e58@cs.columbia.edu> References: <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <20090218221101.GA17868@ussenterprise.ufp.org> <07d401c99218$c5811010$50833030$@net> <20090218224001.GA19041@ussenterprise.ufp.org> <20090218180034.4e734e58@cs.columbia.edu> Message-ID: <6EC15056-3B3F-4468-B510-679208A1878C@merike.com> Opsec wg also....about 2 years ago Ross Callon went to most NOGs to solicit input and I suppose now with Joel it'll be ongoing :) - merike On Feb 18, 2009, at 3:00 PM, Steven M. Bellovin wrote: > On Wed, 18 Feb 2009 17:40:02 -0500 > Leo Bicknell wrote: > >> And let me ask you this question, why do the operators have to go to >> the IETF? Many of us have, and tried. I can't think of a single >> working group chair/co-chair that's ever presented at NANOG and asked >> for feedback. If the IETF wants this to be a two way street actions >> would speak louder than words. >> > Without going into details, I have spoken at NANOG, and I've been a WG > chair, an IAB member, and an AD. Randy has been an AD. I can > think of > several other ADs and IAB members who have frequently attended NANOG. > > I'm not saying it's perfect -- far from it! -- but the issue isn't > nearly that one-sided. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From pbg at cs.berkeley.edu Wed Feb 18 21:09:33 2009 From: pbg at cs.berkeley.edu (Brighten Godfrey) Date: Wed, 18 Feb 2009 19:09:33 -0800 Subject: Greedy routing In-Reply-To: References: Message-ID: > On Wed, 18 Feb 2009 22:12:02 GMT, Rod Beck said: >> http://www.physorg.com/news154093231.html > >> From the fine article: > > "In greedy routing, a node passes information to the neighboring > node that is > closest to the final destination in an abstract space called hidden > metric > space." > > Sounds suspiciously like "throw the packet at the router that's got > the shortest > AS path to the destination" doesn't it? You don't need to know the > entire > topology to know router X is 2 AS's closer to the dest than router > Y once > X and Y have been loaded with the "hidden metric space" known as a > BGP update ;) No, it's quite different from BGP. The high level point is that BGP needs to know a lot of information about the network in order to route, while greedy routing (when it works) requires very little state. To make it concrete: You're right that BGP doesn't need to know the entire topology, but it comes quite close, in terms of the total amount of information it has. To throw the packet at the router that's got the shortest AS path to the destination, you need to have information from every neighbor about every destination. A BGP router in general needs one FIB entry for every destination (IP prefix) in the Internet, i.e., about 300,000 entries, and in the RIB it has potentially 300K from every BGP neighbor.... potentially, millions of entries. In contrast, greedy routing would require probably less than a dozen entries for the average router. This is because the router only needs to know its own "identifier", and those of its immediate neighbors. The routing algorithm has some "distance function" dist (ID1, ID2). A packet comes with some destination identifier D, and the router compares the distance dist(N, D) for each neighbor N, and forwards the packet to the neighbor with smallest distance. For example, suppose you know the topology is a two-dimensional grid. Then the "identifier" is the router's (X,Y) coordinates and the distance function can be Euclidean distance. The main catch is of course that most networks don't have such nice regular structure like the grid. Essentially, greedy routing tries to "summarize" the structure of the network using a very small amount of information. And there are topologies whose pattern of links is "too complicated" (in a certain sense) for greedy routing to be able to summarize it. Therefore it is interesting when you find a network in which greedy routing works, especially if that network is vaguely realistic. The most well-known example is Jon Kleinberg's work on small world networks (http://tinyurl.com/dye7ub), which gives some theoretical backing to Milgram's "six degrees of separation" experiment from the 1960s (which basically used a kind of greedy routing). This physorg paper seems to be very much in the same style, showing that greedy routing works on an Internet-like graph. (Disclaimer: I have only read the above article, not the paper.) Of course there are plenty of reasons you would not use this in practice, e.g., it gives the router little control over routing policy, traffic engineering, etc. > I'm not sure this article is actually telling us anything we didn't > already > know. Now if there was a way to compute those distance metrics without > global knowledge - if there was only an algorithm that > only cared about what was "upstream" from a locally connected link > and whether > it was connected. Say, we could call it a link-state routing > protocol.... > > Now if they were able to actually develop a link-state protocol > that involved > *only* local adjacency announcements and not flooded announcements, > *that* > would be something... But what I see here is "if somebody > developed that, > we'd be able to route more efficiently". This is essentially what they are doing. The distance is computed based on only local knowledge, not global knowledge. Each router needs to know only local adjacencies. Caveat: I haven't read the paper and don't know how they assign the router identifiers, so I am answering only about greedy routing in general. ~Brighten Godfrey From mmc at internode.com.au Wed Feb 18 21:10:35 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 19 Feb 2009 13:40:35 +1030 Subject: IPv6 Confusion In-Reply-To: <68974159-E01C-4A2F-B4F6-17582F722BAF@daork.net> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C6745.3000709@brightok.net> <0C57E3C1-24D7-4A80-823B-9C9C2DB1C428@delong.com> <20090218222041.GM14136@skywalker.creative.net.au> <20090218225054.GA13120@skywalker.creative.net.au> <69DA0224-69AD-4D58-8097-5BC2946FA0E6@internode.com.au> <68974159-E01C-4A2F-B4F6-17582F722BAF@daork.net> Message-ID: <36D75BC4-B41B-40B9-ACE0-50F5F3DFA07C@internode.com.au> On 19/02/2009, at 12:27 PM, Nathan Ward wrote: > > From other discussion with you, your main concern is vendor support > for a few things, right? The issue is that the vendors aren't actually sure what to implement because there's a distinct lack of standards as opposed to competing drafts, p***ing contests, turf wars etc. What exactly do I ask vendors (as a group) to implement so that when I do, it's what everyone else is going to be following the same path? Is there actually a set of things that can be put together to work so that customer can experience hassle free internet in the same way as they do with IPv4? My discussions with people in the last few weeks regarding where it's all at and how I might do IPv6 broadband have made me feel despair not happiness about the future with this. It's people inside the standards bodies that also seem frustrated with this situation. MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks From hank at efes.iucc.ac.il Wed Feb 18 23:37:15 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 19 Feb 2009 07:37:15 +0200 Subject: more AS prepend antics? In-Reply-To: <9515c62d0902181806n26ea551i3f767745a04555ce@mail.gmail.com > Message-ID: <5.1.0.14.2.20090219073601.00ac5bd0@efes.iucc.ac.il> At 08:06 PM 18-02-09 -0600, neal rauhauser wrote: > Why so many prepends from these folks? Cuz you set maxas=20? Just plain noise. -Hank >Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267 >41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 >41827 41827 41827 41827 41827 41827 41827 41827 41827 received from >209.253.101.9: More than configured MAXAS-LIMIT > >Feb 18 20:03:07.361 CST: %BGP-6-ASPATH: Long AS path 1785 2516 2516 2516 >2516 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 >17697 9597 9597 9597 9597 received from 209.253.101.9: More than configured >MAXAS-LIMIT > >Feb 18 20:04:07.849 CST: %BGP-6-ASPATH: Long AS path 1785 3549 8966 8961 >38193 38264 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 >45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 >45127 45127 45127 45127 45127 received from 209.253.101.9: More than >configured MAXAS-LIMIT > > >-- >mailto:Neal at layer3arts.com // >GoogleTalk: nrauhauser at gmail.com >IM: nealrauhauser From nrauhauser at gmail.com Wed Feb 18 23:54:14 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Wed, 18 Feb 2009 23:54:14 -0600 Subject: more AS prepend antics? In-Reply-To: <5.1.0.14.2.20090219073601.00ac5bd0@efes.iucc.ac.il> References: <5.1.0.14.2.20090219073601.00ac5bd0@efes.iucc.ac.il> Message-ID: <9515c62d0902182154y663914d2m108c58e8590817bf@mail.gmail.com> What in the world is someone doing with that many prepends? I'm trying to envision what would drive such a decision - small, regional player on one side and well connected international on the other? I see major players just three hops away via both of their peers. http://www.robtex.com/as/as41827.html On Wed, Feb 18, 2009 at 11:37 PM, Hank Nussbacher wrote: > At 08:06 PM 18-02-09 -0600, neal rauhauser wrote: > >> Why so many prepends from these folks? >> > > Cuz you set maxas=20? Just plain noise. > > -Hank > > > > > Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267 >> 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 >> 41827 41827 41827 41827 41827 41827 41827 41827 41827 received from >> 209.253.101.9: More than configured MAXAS-LIMIT >> >> Feb 18 20:03:07.361 CST: %BGP-6-ASPATH: Long AS path 1785 2516 2516 2516 >> 2516 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 >> 17697 >> 17697 9597 9597 9597 9597 received from 209.253.101.9: More than >> configured >> MAXAS-LIMIT >> >> Feb 18 20:04:07.849 CST: %BGP-6-ASPATH: Long AS path 1785 3549 8966 8961 >> 38193 38264 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 >> 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 >> 45127 45127 45127 45127 45127 received from 209.253.101.9: More than >> configured MAXAS-LIMIT >> >> >> -- >> mailto:Neal at layer3arts.com // >> GoogleTalk: nrauhauser at gmail.com >> IM: nealrauhauser >> > > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From carlos at race.com Thu Feb 19 00:30:08 2009 From: carlos at race.com (Carlos Alcantar) Date: Wed, 18 Feb 2009 22:30:08 -0800 Subject: issues with msn Message-ID: <859604546CD1FF488BDB6EA94C896AFB592E80@racexchange.race.local> Hey guys any of you guys seeing some issues getting to msn on the west coast here? I seem to be having issues via level3 abovenet and Comcast. -carlos From chaim.rieger at gmail.com Thu Feb 19 00:33:38 2009 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Thu, 19 Feb 2009 06:33:38 +0000 Subject: issues with msn Message-ID: <1684813114-1235025238-cardhu_decombobulator_blackberry.rim.net-1386627767-@bxe1146.bisx.prod.on.blackberry> Issues with att socal as well. ------Original Message------ From: Carlos Alcantar To: nanog at nanog.org Subject: issues with msn Sent: Feb 18, 2009 22:30 Hey guys any of you guys seeing some issues getting to msn on the west coast here? I seem to be having issues via level3 abovenet and Comcast. -carlos Sent via BlackBerry from T-Mobile From swmike at swm.pp.se Thu Feb 19 01:03:28 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 19 Feb 2009 08:03:28 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <499CACEF.10507@justinshore.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local><4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com><6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local><050701c99135$df0f0ed0$9d2d2c70$@net> <499B97C5.9020601@justinshore.com> <5699373B-7F5B-4CD6-BF28-F9190D39AD72@virtualized.org> <499CACEF.10507@justinshore.com> Message-ID: On Wed, 18 Feb 2009, Justin Shore wrote: > Adoption of IPv6 would be better in my opinion if vendors didn't force > us to pay a premium to use IPv6. It's hard enough to convince > management that there is a need to implement IPv6. It's even harder > when you tell them how much it costs. And when they ask what they're > getting for their dollars, they are none to pleased to hear that the > bulk of it is going to a damn license. Well, at least some BUs decided that IPv6 should now be included in IPBASE which lowers the cost of getting basic IPv6 routing up and running. -- Mikael Abrahamsson email: swmike at swm.pp.se From drc at virtualized.org Thu Feb 19 01:27:16 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 18 Feb 2009 21:27:16 -1000 Subject: IPv6 Confusion In-Reply-To: <072401c9920d$cb823cb0$6286b610$@net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <072401c9920d$cb823cb0$6286b610$@net> Message-ID: Tony, On Feb 18, 2009, at 11:13 AM, Tony Hain wrote: > The bottom line is, if you want something to be defined in a way > that works for you, you have to participate in the definition. Well, yes. But there is an impedance mismatch here. The IETF still seems to operate under the assumption that the folks who run the networks are the same folks who implement the code the network runs on top of. I figure this (mostly) stopped being the case (at least for the "production Internet") sometime in the mid-90s. Today, network operators and end users are the folks who are specifying requirements. Folks who go to IETFs are the ones who are trying to figure out the protocols to meet those requirements, or at least what they believe those requirements to be. Unfortunately, that's not what we have. We have network operators in their own little world, trying to keep the network running and protocol developers in their own little world, trying to come up with cool features that will make their protocols relevant, based on their own beliefs as to what is important or not. These two camps seem to intersect rarely. As such, it isn't particularly surprising when IETF protocol developers tell network operators who go to the IETF they aren't relevant. In the specific definition of protocol bits on the wire, network operators actually aren't that relevant. Network operators care about the functionality and multi-vendor interoperability, whether it is bit 8 in the second octet or bit 4 in the third octet that results in that functionality isn't a big concern (as long as everyone agrees). The network operators tell the vendors what sort of functionality they need, and the vendors go to the IETF to push their particular approach to address those requirements (or block another vendor's approach). This may be where Randy Bush derives his "IVTF" label. The problem is, since around the mid-90s, it seems we've taken it too far. The fact that the IETF has demonstrably ignored network operator input in stuff like DHCP or routing scalability means the IETF has developed protocols that don't meet network operator requirements. And because network operators can't be bothered to learn and argue the bit patterns, their ability to provide input into protocol definition is reduced to yelling from the sidelines or communicating via proxies with their own agendas. Yes, there have been attempts to bridge the two camps, but I suspect the only way to really address this is a fundamental shift in the way the IETF does business, taking into account the fact that network operators and end users, by and large, are not the implementors of protocols and don't actually care how they are implemented, but rather the folks who define what the protocols need to do. I'll admit some skepticism that such a change is actually feasible. Regards, -drc From randy at psg.com Thu Feb 19 01:55:15 2009 From: randy at psg.com (Randy Bush) Date: Thu, 19 Feb 2009 16:55:15 +0900 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <072401c9920d$cb823cb0$6286b610$@net> Message-ID: > This may be where Randy Bush derives his "IVTF" label. not exactly. see . > Yes, there have been attempts to bridge the two camps, but I suspect > the only way to really address this is a fundamental shift in the way > the IETF does business, taking into account the fact that network > operators and end users, by and large, are not the implementors of > protocols and don't actually care how they are implemented, but rather > the folks who define what the protocols need to do. I'll admit some > skepticism that such a change is actually feasible. standards bodies used to be composed of users meeting to drive vendors to common specs so the users had freedom of choice and inter-operation. the ietf has become vendors inventing new and ever more complex features to drive users to minimal margins. randy From a.slastenov at gmail.com Thu Feb 19 03:06:26 2009 From: a.slastenov at gmail.com (Andrey Slastenov) Date: Thu, 19 Feb 2009 12:06:26 +0300 Subject: Single fiber 10Gb/s X2 or Xenpak transceiver Message-ID: <9be3e6fd0902190106s5ef4f061nd80921aee28b9480@mail.gmail.com> Hi Guys. Do you ever see single fiber 10Gb/s X2 or Xenpak transceiver? (I know about SFP, but never see X2 or Xenpak before) From a.slastenov at gmail.com Thu Feb 19 04:18:29 2009 From: a.slastenov at gmail.com (Andrey Slastenov) Date: Thu, 19 Feb 2009 13:18:29 +0300 Subject: single fiber 10Gb/s X2 or Xenpak transceiver Message-ID: <9be3e6fd0902190218x49ea0ee6t9ce935db9cca6466@mail.gmail.com> Hi Guys. Do you ever see single fiber 10Gb/s X2 or Xenpak transceiver? (I know about SFP, but never see X2 or Xenpak before) From frnkblk at iname.com Thu Feb 19 05:07:29 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 19 Feb 2009 05:07:29 -0600 Subject: IPv6 Confusion In-Reply-To: <20090217213004.281A51CC09@ptavv.es.net> References: Your message of "Tue, 17 Feb 2009 11:48:49 PST." <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> <20090217213004.281A51CC09@ptavv.es.net> Message-ID: The really scary thing is that deploying carrier-grade NAT might be cheaper to the service provider than rolling IPv6 to its residential subscribers. Frank -----Original Message----- From: Kevin Oberman [mailto:oberman at es.net] Sent: Tuesday, February 17, 2009 3:30 PM To: Owen DeLong Cc: 'Carl Rosevear'; nanog at nanog.org Subject: Re: IPv6 Confusion The big iron folks are proposing something called "Carrier Grade NAT". This one REALLY frightens me, but I understand a couple of hardware manufacturers are planning on building such a monster. It might actually work, but the amount of state carried strikes me as in invitation to disaster. There was a draft on CNG, but it expired last month. A copy is still available at: http://smakd.potaroo.net/ietf/all-ids/draft-nishitani-cgn-00.txt Also, a proposal for a different approach is at: http://mice.cs.columbia.edu/getTechreport.php?techreportID=560 (PDF) If you are really concerned about where we go whan v4 address space is exhausted, I strongly urge you to look at all of these issues. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From swmike at swm.pp.se Thu Feb 19 05:15:13 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 19 Feb 2009 12:15:13 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: References: Your message of "Tue, 17 Feb 2009 11:48:49 PST." <43C94354-8F96-4082-B082-CB5B91EB71E4@delong.com> <20090217213004.281A51CC09@ptavv.es.net> Message-ID: On Thu, 19 Feb 2009, Frank Bulk wrote: > The really scary thing is that deploying carrier-grade NAT might be cheaper > to the service provider than rolling IPv6 to its residential subscribers. The really scary thing is that in areas where there are only two major ISPs, both might go for CGN and then you have no choice. The important thing is to have proper competition, that's the way innovation gets into the market. On the other hand, I have little problem in seeing a future with different service offerings, one being "IPv4 only behind CGN" and another being "globally routable IPv4 address with 6to4 support" and a third being "globally routable IPv4 address with native IPv6 and a /56 (or /48)". -- Mikael Abrahamsson email: swmike at swm.pp.se From frnkblk at iname.com Thu Feb 19 05:23:05 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 19 Feb 2009 05:23:05 -0600 Subject: IPv6 Confusion In-Reply-To: <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> Message-ID: Most service providers aren't in the business of maintaining their customer's home network, and if you have to place an ONT/DSL modem/cable modem at the customer premise, most of that gear operates at L2 with little L3 in the way (except perhaps if you place the PPPoA/E functionality on the DSL modem or service-provided broadband router). Considering that the only real IPv6-ready CPE at your favorite N.A. electronics store is Apple's AirPort, it seems to me that it will be several years before the majority (50% plus 1) of our respective customer bases has IPv6-ready or dual-stack equipment. Frank -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Tuesday, February 17, 2009 8:28 PM To: Randy Bush Cc: nanog at nanog.org Subject: Re: IPv6 Confusion Sounds like those consumer ISPs better get started on rolling out dual stacks to the CPE. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From trejrco at gmail.com Thu Feb 19 05:34:39 2009 From: trejrco at gmail.com (TJ) Date: Thu, 19 Feb 2009 06:34:39 -0500 Subject: IPv6 Confusion (back to technical conversation) In-Reply-To: <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> References: <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> <20090218205354.GA14504@ussenterprise.ufp.org> <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> Message-ID: <002101c99286$0d689340$2839b9c0$@com> >>> I guess you don't use DHCP in IPv4 then. >> No, you seem to think the failure mode is the same, and it is not. >> Let's walk through this: >> 1) 400 people get on the NANOG wireless network. >> 2) Mr 31337 comes along and puts up a rogue DHCP server. >> 3) All 400 people continue working just fine until their lease expires, >> which is likely after the conference ends. The 10 people who came in >> late get info from the rogue server, and troubleshooting ensues. So a delayed failure makes it easier to troubleshoot? I'd rather know right away. Also - I'd rather not make the mistake in the first place ... but life isn't perfect. >> Let's try with IPv6. >> 1) 400 people get on the NANOG wireless network. >> 2) Mr 31337 sends a rouge RA. >> 3) 400 people instantly loose network access. >> The 10 who come in late don't even bother to try and get on. >> So, with DHCP handing out a default route we have 10/400 down, with >> RA's we have 410/410 down. Bravo! Right, so a timing difference is all you are talking about - and the malicious person would probably know his/her limitations, and therefore show up early. Same end result. Also - there are questions over what type of RA was sent (or, more correctly, what type of payload), the timing of the good RAs, etc. BUT, the point is taken - yes, rouge RAs are a problem and there is a solution being developed. >> Let me clear up something from the start; this is not security. If >> security is what you are after none of the solutions proffered so far >> work. Rather this is robust network design. A working device >> shouldn't run off and follow a new router in miliseconds like a lost >> puppy looking for a treat. >> >> This actually offers a lot of protection from stupidity though. Ever >> plug an IPv4 router into the wrong switch port accidently? What >> happened? Probably nothing; no one on the LAN used the port IP'ed in >> the wrong subnet. They ignored it. >> >> Try that with an IPv6 router. About 10 ms after you plug into the >> wrong port out goes an RA, the entire subnet ceases to function, and >> your phone lights up like a christmas tree. Right ... but you unplug it, NUD flushes and assuming you have your environment set right all is well in short order. >> Let me repeat, none of these solutions are secure. The IPv4/DHCP >> model is ROBUST, the RA/DHCPv6 model is NOT. I would still disagree. More readily supporting multiple routers seems like a measure of robustness, to me anyway. >Yup, understood. >The point I am making is that the solution is still the same - filtering in >ethernet devices. YES! >Perhaps there needs to be something written about detailed requirements for >this so that people have something to point their switch/etc. vendors at when >asking for compliance. I will write this up in the next day or two. I guess >IETF is the right forum for publication of that. > >Is there something like this already that anyone knows of? YES! http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 Push vendors for support, please. (For wireless, something like PSPF would work just fine AFAIK ... please correct me if I am wrong!) From nick at foobar.org Thu Feb 19 06:03:00 2009 From: nick at foobar.org (Nick Hilliard) Date: Thu, 19 Feb 2009 12:03:00 +0000 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <072401c9920d$cb823cb0$6286b610$@net> Message-ID: <499D4A74.5020600@foobar.org> On 19/02/2009 07:27, David Conrad wrote: > those requirements to be. Unfortunately, that's not what we have. We > have network operators in their own little world, trying to keep the > network running and protocol developers in their own little world, > trying to come up with cool features that will make their protocols > relevant, based on their own beliefs as to what is important or not. > These two camps seem to intersect rarely. Naah, it's worse than that. It's an unholy triad of protocol developers, software developers and operators, each of which operates in their own playpen, and none of which actually communicate with anyone else. While not wanting to stereotype things, some would say that the protocol developers think that the operators don't know crap about what's good for them, and that the three most important things in the world are correctness, committee approval and their own particular protocol. On the other side are the operators, trying to build and maintain real world networks, and who when presented with the sort of trashy mess that we see with RA/DHCPv6, make decisions which makes sense for themselves at that particular time, even if it involves. Being human, they spend considerable amounts of time frothing at the mouth at whoever thought, for example, that RA was a good idea in the first place, or that DHCPv6 should lack a default-route option. Stuck in the middle are the developers. The poor developers. Despised equally by both sides: one the one hand for butchering these beautiful, elegant protocols and churning out bug-ridden heaps of trash; on the other hand, for, well, butchering these bizarre, half-baked protocols and churning out bug-ridden heaps of trash. Life truly sucks for them. Sorry, did someone say that we all work in the communications industry? Nick From david.freedman at uk.clara.net Thu Feb 19 06:41:33 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 19 Feb 2009 12:41:33 +0000 Subject: IPv6 Confusion In-Reply-To: <1234999587.17985.867.camel@guardian.inconcepts.net> References: <20090218181951.EEC111CC09@ptavv.es.net> <7CE89ED4-E20A-47DF-8EA7-5217B7141AF4@virtualized.org> <499C8F79.2000801@sprunk.org> <1234999587.17985.867.camel@guardian.inconcepts.net> Message-ID: > > I think, for example, that Juniper is making a mistake by rolling v6 > capability into a license that also includes BGP and ISIS on some > platforms. Cisco is guilty of this as well. > > I am not necessarily advocating that v6 must be a basic feature on every > new box; but I don't think it is correct to force customers to buy a > license that includes a lot of other bells and whistles just to get v6. > It could be a separate cost. I mean, surely the intellectual property has been developed now, are the vendors /still/ paying developers off for this? hasn't most of the money already been spent? From rdroms at cisco.com Thu Feb 19 07:41:49 2009 From: rdroms at cisco.com (Ralph Droms) Date: Thu, 19 Feb 2009 08:41:49 -0500 Subject: IPv6 Confusion Message-ID: <719754E1-C44C-4860-9165-369D079B02B1@cisco.com> Independent of this conversation, there has been some parallel interest in this problem area in the IETF. There is enough interest to suggest writing a draft defining additional options for DHCPv6 to allow "DHCPv6-only" operation. I'm writing as chair of the dhc WG to ask you, the operators who are asking for these extensions to DHCPv6, to provide clear technical requirements. What problem are you trying to solve and how do you want to solve it? Reply directly to me - no need for further congestion on this mailing list - and we can discuss those requirements. The deadline for draft publication prior to the upcoming IETF meeting in SF is March 3, so please respond soon. Thanks in advance... - Ralph From jbates at brightok.net Thu Feb 19 07:42:15 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 19 Feb 2009 07:42:15 -0600 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> Message-ID: <499D61B7.1080000@brightok.net> Frank Bulk wrote: > Considering that the only real IPv6-ready CPE at your favorite N.A. electronics store is Apple's AirPort, it seems to me that it will be several years before the majority (50% plus 1) of our respective customer bases has IPv6-ready or dual-stack equipment. On the other hand, a majority of the routers purchased are for wireless connectivity, followed quickly by the necessity for multiple computers sharing a common subnet. Security and firewalls are not something most end users attribute to routers, but instead to their host based solutions. As such, I have no problem with pointing out that they can have 4.3 billion squared devices sitting off a cheap switch; all sharing the same subnet. Of course, wireless peeps will either have to use wireless bridges or have supported routers. Really, the AirPort is pretty stable and functional as a wireless AP. Most say it's worth the extra $$$. -Jack From tjc at ecs.soton.ac.uk Thu Feb 19 07:57:39 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 19 Feb 2009 13:57:39 +0000 Subject: IPv6 Confusion In-Reply-To: <3A0AD7D0-FBBB-4713-A1A2-49DE512AF7E7@wisc.edu> References: <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <28611E30-245F-4BB7-97C0-EF7B60B0D9A3@daork.net> <20090218205354.GA14504@ussenterprise.ufp.org> <4A0C60E7-235A-4EFE-B619-02022CAAFA72@daork.net> <3A0AD7D0-FBBB-4713-A1A2-49DE512AF7E7@wisc.edu> <20090219135739.GH16197@login.ecs.soton.ac.uk> Message-ID: On Wed, Feb 18, 2009 at 03:05:43PM -0600, Dale W. Carder wrote: > > On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: > > > >Is there something like this already that anyone knows of? > > http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt There will be an update of this prior to March's IETF. If anyone has any comments please send them directly to me and we'll try to work them in. Hopefully with this text as a 'why' and the RA Guard text as a 'how' we have some things to point vendors at. Though as some have pointed out RA Guard isn't applicable everywhere (just as SeND isn't too). -- Tim From deric.kwok2000 at gmail.com Thu Feb 19 08:30:16 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 19 Feb 2009 09:30:16 -0500 Subject: real hardware router VS linux router Message-ID: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Hi All Actually, what is the different hardware router VS linux router? Have you had experience to compare real router eg: cisco VS linux router? eg: streaming speed... tcp / udp Thank you for your information From hardenrm at uiuc.edu Thu Feb 19 08:37:13 2009 From: hardenrm at uiuc.edu (Ryan Harden) Date: Thu, 19 Feb 2009 08:37:13 -0600 Subject: real hardware router VS linux router In-Reply-To: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Message-ID: <499D6E99.1090706@uiuc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While you could probably build a linux router that is just as fast as a real hardware router, you're always going to run into the moving pieces part of the equation. In almost all scenarios, moving parts are more prone to failure than non-moving parts. Regardless of what you find out in your research, consider the above in your cost-benefit analysis. /Ryan Deric Kwok wrote: > Hi All > > Actually, what is the different hardware router VS linux router? > > Have you had experience to compare real router eg: cisco VS linux router? > > eg: streaming speed... tcp / udp > > Thank you for your information - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: hardenrm at illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign University of Illinois - ICCN -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmdbpcACgkQtuPckBBbXboREgCguTikt2UwEIRHNfoNzASreLD/ YLcAoKdr/Gbw8CQuY9dTitvGQdD3+H0s =bsHP -----END PGP SIGNATURE----- From bruce at yoafrica.com Thu Feb 19 08:37:42 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Thu, 19 Feb 2009 16:37:42 +0200 Subject: real hardware router VS linux router In-Reply-To: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Message-ID: <000e01c9929f$9f837e20$de8a7a60$@com> Not much really, besides your personal preference and the configurability of the device (will maintaining some semblance of sanity), there are some very nice custom linux based appliances out there e.g. vyatta routers, which boast 10 times throughput of Cisco (2800 series) routers, however it all comes down to what you want to do. -----Original Message----- From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] Sent: Thursday, February 19, 2009 4:30 PM To: nanog at nanog.org Subject: real hardware router VS linux router Hi All Actually, what is the different hardware router VS linux router? Have you had experience to compare real router eg: cisco VS linux router? eg: streaming speed... tcp / udp Thank you for your information From karnaugh at karnaugh.za.net Thu Feb 19 08:44:50 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 19 Feb 2009 16:44:50 +0200 Subject: real hardware router VS linux router In-Reply-To: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Message-ID: <499D7062.5000803@karnaugh.za.net> Deric Kwok wrote: > Hi All > > Actually, what is the different hardware router VS linux router? > > Have you had experience to compare real router eg: cisco VS linux router? Archives have discussed this at extreme length. The most interesting thing I saw come out of it was this http://data.guug.de/slides/lk2008/10G_preso_lk2008.pdf See pictures describing the primary differences. From lists at mtin.net Thu Feb 19 08:56:03 2009 From: lists at mtin.net (Justin Wilson - MTIN) Date: Thu, 19 Feb 2009 09:56:03 -0500 Subject: real hardware router VS linux router In-Reply-To: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Message-ID: Imagestream is a very solid and mature solution. In order to head off the Holy War I am a Cisco guy too. It just depends on your budget and situation. Justin > From: Deric Kwok > Date: Thu, 19 Feb 2009 09:30:16 -0500 > To: > Subject: real hardware router VS linux router > > Hi All > > Actually, what is the different hardware router VS linux router? > > Have you had experience to compare real router eg: cisco VS linux router? > > eg: streaming speed... tcp / udp > > Thank you for your information From sandy at tislabs.com Thu Feb 19 08:56:35 2009 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 19 Feb 2009 09:56:35 -0500 (EST) Subject: IPv6 Confusion In-Reply-To: <20090218180034.4e734e58@cs.columbia.edu> Message-ID: <20090219145635.D7F573F44D@pecan.tislabs.com> >I can't think of a single >> working group chair/co-chair that's ever presented at NANOG and asked >> for feedback. Were you at the last NANOG when I did everything but beg for feedback? --Sandy From jared at puck.nether.net Thu Feb 19 09:01:59 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 19 Feb 2009 10:01:59 -0500 Subject: IPv6 Confusion In-Reply-To: <20090219145635.D7F573F44D@pecan.tislabs.com> References: <20090218180034.4e734e58@cs.columbia.edu> <20090219145635.D7F573F44D@pecan.tislabs.com> Message-ID: <20090219150159.GB69199@puck.nether.net> On Thu, Feb 19, 2009 at 09:56:35AM -0500, Sandy Murphy wrote: > >I can't think of a single > >> working group chair/co-chair that's ever presented at NANOG and asked > >> for feedback. > > Were you at the last NANOG when I did everything but beg for feedback? Would it be insane to have an IETF back-to-back with a NANOG? - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mike-nanog at tiedyenetworks.com Thu Feb 19 09:05:46 2009 From: mike-nanog at tiedyenetworks.com (mike) Date: Thu, 19 Feb 2009 07:05:46 -0800 Subject: real hardware router VS linux router In-Reply-To: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Message-ID: <499D754A.6030008@tiedyenetworks.com> Well, Our operation uses linux everywhere and we have our own in house tiny embedded flavor with all the tools and things that make it suited for use in big and small boxes as many kinds of router and general packet flipping appliance. I have confidence built on long term, real world experience that says I can do this sucessfully, but the price I pay for it is the knowledge curve and having had to invent the 'right' mix of stuff, which includes compact flash based boot media, read-only filesystem, and minimal management (command line via ssh, you need to be an expert), and as well as having had to select the right hardware (constraints include power on always, no dumb bios to stop the boot process, and other issues). I would never ever reccomend that anyone just 'use linux' for network appliances. It *can* do the job, but all the baggage of 'pc hardware' typically conspires to make for less than rock solid. Stuff like hard disks, which crash malfunction corrupt, and issues like - does the box power on when power is applied or does someone have to press a button? (You will note, most commercial hardware like routers and switches either don't have a power button, or simply default to being 'on' unless you take pains to flip buttons somewhere. But, PC's typically have a power button you have to press to make it come on). And there's other issues too - PC Bios's also conspire to get in the way and stop the boot process. If they detect some sort of error, a key press, a missing disk, or many other excuses, they stop cold waiting for someone to 'press f1 to continue', or worse. Also most PC systems also have single power supply units, and that which are less sturdy construction and are more likely to burn out at some point than the more heavy duty commercial grade units you see in commercial router/switch equipment). The difference then between linux and 'a hardware router' then is that the manufacturer - cisco, juniper, whomever - has a large degree of control over the integration between their software and the hardware it runs on, and can dictate all of the things that makes the product work like the boot process and it's internal storage and wether there are sufficient fans and what kind of power supplie(s) are present and wether there's a hardware watchdog (that works!) and the type of chips serving as the ethernet controllers (which dictates all kinds of things that the mnf considers 'features'). It's a long list. To summarize, you can do many jobs with linux. How WELL you do them, however, is more of a function of how much exerience and knowledge that you have. You can also do many jobs with commercial boxes, but how well you do that job can be expressed more in terms of selecting the right platform and plugging the right configuration lines into it, and both of these can easilly be 'done well' in exchange for money (router vendor support team, etc). Mike- Deric Kwok wrote: > Hi All > > Actually, what is the different hardware router VS linux router? > > Have you had experience to compare real router eg: cisco VS linux router? > > eg: streaming speed... tcp / udp > > Thank you for your information > From rays at maine.edu Thu Feb 19 09:16:57 2009 From: rays at maine.edu (Soucy, Ray) Date: Thu, 19 Feb 2009 10:16:57 -0500 Subject: IPv6 Confusion In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> Message-ID: <36243D984F88BA4ABD1E0EFC1E61B98965287A@fudd.ad.maine.edu> Response inline. -----Original Message----- From: Carl Rosevear [mailto:Carl.Rosevear at demandmedia.com] Sent: Tuesday, February 17, 2009 11:59 AM To: nanog at nanog.org Subject: IPv6 Confusion > How does IPv6 addressing work? RFC 2372 is a good starting point. With IPv6 we provide for every LAN network to be a /64. A good starting point would be counting your VLANs and trying to anticipate how many networks you will need (not how many hosts on said networks). Don't count any non-routed networks, as these can make use of ULA address space (the IPv6 equivalent to RFC 1918 space), for more info on ULA see RFC 4193. If you assign a /64 to every LAN (as you should) then the rest is deciding how much address space you need for network identifiers (remember, since the host segment of each network is a /64 there is no need to define the number of hosts you will have on any given network). A /56 for example would provide you with 256 networks, which is more than enough for most mid-sized networks. If you need more, you could jump up to a /52, providing a 12 bit address space for network identifiers (or 4096) which is the same size as the 802.1Q VLAN ID field. This could be useful in tracking your IPv6 networks as you could essentially use those 12 bits to encode the hex value of the VLAN ID for any network you create (preventing address space conflicts). For very large organizations (multi-campus organizations for example) moving up to a /48 provides enough address space for 16 /52s, or 256 /56s (again, these are just examples, I like to keep the breaks 4 bits apart for readability, but you could use any mask in between). The point is you need to get away from the mindset of determining network sizes based on the number of hosts. On a side note we do make use of /126 networks in the zero address space for link networks (router to router) as recommended by RFC 3627. The main reason for this is because a /64 for link networks (of which we have several) is very wasteful. Using the zero address space for these also provides us with the ability to have much shorter addresses for links using the :: notation; e.g. 2001:DB8::1. With that said, I think most providers are giving out either /64s or /48s right now. IMHO a /48 is often wasteful, but it's not like the address space isn't there. If you're going to be using BGP for routing IPv6 (e.g. more than one provider) you'll want to have something larger than a /48 (/48 and /32 are the most common prefix sizes we see announced through BGP). Many ISPs will refuse to route anything smaller than a /32 though, so check with who you plan on getting service from first. If you don't have need for something that is a /48 or larger, you probably should just try to go through a single provider to assign you a prefix out of their space. Hurricane Electric (HE.net) offers free IPv6 tunnels with /64 or /48 prefix assignments. It might be a good option for you to play around with IPv6 before you go out and request a /32. > I know it's been hashed and rehashed but several orgs I am associated > with are about to ask for their allocations from ARIN and we are all > realizing we don't really know how the network / subnet structure > trickles down from the edge to the host. We really don't have a firm > grasp of all of this as there seems to be multiple options regarding > how many addresses should be assigned to a host, if the MAC address > should be included in the address or if that is just for auto- > configuration purposes or what the heck the deal is. There are a lot > of clear statements out there and a lot that are clear as mud. > Unfortunately, even when trying to analyze which RFC superseded > another. Can I just subnet it all like IPv4 but with room to grow or > is each host really going to need its own /84 or something? I can't > see why hosts would need any more addresses than today but maybe I'm > missing something because a lot of addressing models sure allow for a > huge number of unique addresses per host. You shouldn't make any network smaller than a /64, the exception is link networks as mentioned above, but even then there are purists who will say no to those and use /64s there as well. That's the entire point of having a 128-bit address space instead of a 64-bit address space. The intent was to do away with the need for NAT (which is costly and breaks the Internet). Stateless Autoconfiguration (RFC 4862) is your friend; don't fight it. It will be some time before we see things like DHCPv6 snooping work its way into L2 security, but work is already in progress for protection against Router Advertisement (RA)... it's called RA Guard, and you can view the current draft of it here: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 On a side note, I always use ::1 for the gateway address, but there is no requirement for that. If you need to assign static IPs to hosts you can start using ::2 or even leave the first handful of addresses empty for future use. Anything that doesn't have the stateless flag (FFFE inserted in the middle) shouldn't cause a conflict. Note that we're in a transition phase for IPv6 right now. That means we're talking about dual-stack network deployments (IPv6 and IPv4 running side by side). It's going to be a while before we can get away with running IPv6-only networks. > There are people here at my company that seem to get it but can't > seem to explain it clearly to me. To me, its basically just larger > addressing space with some new logical boundaries.... But there are > so many discussions of potential addressing methods that I am > confused. I know from my lab setups that I can "make it work" but > I'd like to "do it right". J > I've been doing this for over 10 years now... IPv4 is native to me. > If you can point me in the direction of some good, authoritative > information or even say "Dood, go get IPv6 for dummies", that's fine > I just need to know where to find some good information. Dump the IPv4 mindset, don't use anything smaller than a /64, and assign a /64 for each VLAN and you'll be fine. We have IPv6 deployed on a limited number of networks. The things slowing us down right now are mainly the lack of L2 security features that are around for IPv4 (DHCP snooping, ARP inspection, etc.) In the future we'll be looking at 802.1X for securing access, RA Guard for suppressing rogue IPv6 routers, and much later on, perhaps a shift to stateful addressing using DHCPv6 so that we can dynamically IPv6 DNS records, but that will be much later. Many operating systems don't support DHCPv6 natively yet, but all hosts that support IPv6 support stateless autoconfiguration. We do DHCPv6 on our routers to hand out IPv6 DNS servers for hosts that support DHCPv6, but that's mostly for testing IPv6 on our DNS servers. Ray From bicknell at ufp.org Thu Feb 19 09:19:19 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 19 Feb 2009 10:19:19 -0500 Subject: IPv6 Confusion In-Reply-To: <20090219150159.GB69199@puck.nether.net> References: <20090218180034.4e734e58@cs.columbia.edu> <20090219145635.D7F573F44D@pecan.tislabs.com> <20090219150159.GB69199@puck.nether.net> Message-ID: <20090219151919.GB53113@ussenterprise.ufp.org> In a message written on Thu, Feb 19, 2009 at 10:01:59AM -0500, Jared Mauch wrote: > > Would it be insane to have an IETF back-to-back with a NANOG? > Probably, but it would be a good idea. :) I have no idea how the IETF agenda is set, but that may be part of the trick. I suspect network operators care a lot about protocols at lower layers in the stack, and less and less at higher levels in the stack. SeND, DHCP, the RA stuff are all very important to us; some new header field in HTTP or IMAP much less so. Since IETF is usually 5 days, it would be nice if that lower level stuff could be adjacent to NANOG. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From sandy at tislabs.com Thu Feb 19 09:18:57 2009 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 19 Feb 2009 10:18:57 -0500 (EST) Subject: IPv6 Confusion In-Reply-To: <20090218180034.4e734e58@cs.columbia.edu> Message-ID: <20090219151857.E0D513F44D@pecan.tislabs.com> >Were you at the last NANOG when I did everything but beg for feedback? Maybe I should have been more helpful. Here's the link: http://www.nanog.org/meetings/nanog45/presentations/Wednesday/Murphy_light_sidr_N45.pdf --Sandy From smb at cs.columbia.edu Thu Feb 19 09:23:14 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 19 Feb 2009 10:23:14 -0500 Subject: IPv6 Confusion In-Reply-To: <20090219151919.GB53113@ussenterprise.ufp.org> References: <20090218180034.4e734e58@cs.columbia.edu> <20090219145635.D7F573F44D@pecan.tislabs.com> <20090219150159.GB69199@puck.nether.net> <20090219151919.GB53113@ussenterprise.ufp.org> Message-ID: <20090219102314.655f3b94@cs.columbia.edu> On Thu, 19 Feb 2009 10:19:19 -0500 Leo Bicknell wrote: > In a message written on Thu, Feb 19, 2009 at 10:01:59AM -0500, Jared > Mauch wrote: > > > > Would it be insane to have an IETF back-to-back with a NANOG? > > > > Probably, but it would be a good idea. :) > > I have no idea how the IETF agenda is set, but that may be part of > the trick. I suspect network operators care a lot about protocols > at lower layers in the stack, and less and less at higher levels > in the stack. > > SeND, DHCP, the RA stuff are all very important to us; some new > header field in HTTP or IMAP much less so. Since IETF is usually > 5 days, it would be nice if that lower level stuff could be adjacent > to NANOG. > The IETF agenda isn't set that way -- not even close... The big problem I see is that after a week of IETF, I'm *completely* fried. It's also just a very long time to be away from my family. --Steve Bellovin, http://www.cs.columbia.edu/~smb From dave at mvn.net Thu Feb 19 09:43:06 2009 From: dave at mvn.net (David E. Smith) Date: Thu, 19 Feb 2009 09:43:06 -0600 Subject: real hardware router VS linux router In-Reply-To: <499D6E99.1090706@uiuc.edu> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> Message-ID: <499D7E0A.80906@mvn.net> Ryan Harden wrote: > While you could probably build a linux router that is just as fast as a > real hardware router, you're always going to run into the moving pieces > part of the equation. > > In almost all scenarios, moving parts are more prone to failure than > non-moving parts. > It's quite possible to build Linux-based devices with few or no moving parts. Small embedded boards, and flash drives, are common and cheap; and for low-load situations it's possible to build a passively-cooled (i.e. no fans, so zero moving parts) system. Higher-performance setups with a few moving parts (mainly fans) are still possible, but at some point you have to balance the time and effort of R&D and performance-tuning your system. If you save a few thousand dollars on hardware, but spend a few days tweaking everything, you may not come out ahead after all. At least two vendors (Imagestream and Mikrotik) offer complete packages based on Linux; the latter also sells the software separately, for installation on your own hardware, and both offer support if you need it. David Smith MVN.net From msaqib at gmail.com Thu Feb 19 09:50:17 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Thu, 19 Feb 2009 20:50:17 +0500 Subject: Network SLA Message-ID: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> Greetings I am curious to know about any tools/techniques that a service provider uses to assess an SLA before signing it. That is to say, how does an administrator know if he/she can meet what he is promising. Is it based on experience? Are there commonly used tools for this? Thanks and best regards -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From BBlackford at nwresd.k12.or.us Thu Feb 19 09:54:34 2009 From: BBlackford at nwresd.k12.or.us (Bill Blackford) Date: Thu, 19 Feb 2009 07:54:34 -0800 Subject: real hardware router VS linux router In-Reply-To: <499D6E99.1090706@uiuc.edu> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> Message-ID: <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> In scaling upward. How would a linux router even if a kernel guru were to tweak and compile an optimized build, compare to a 7600/RSP720CXL or a Juniper PIC in ASIC? At some point packets/sec becomes a limitation I would think. -b -----Original Message----- From: Ryan Harden [mailto:hardenrm at uiuc.edu] Sent: Thursday, February 19, 2009 6:37 AM To: Deric Kwok Cc: nanog at nanog.org Subject: Re: real hardware router VS linux router -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While you could probably build a linux router that is just as fast as a real hardware router, you're always going to run into the moving pieces part of the equation. In almost all scenarios, moving parts are more prone to failure than non-moving parts. Regardless of what you find out in your research, consider the above in your cost-benefit analysis. /Ryan Deric Kwok wrote: > Hi All > > Actually, what is the different hardware router VS linux router? > > Have you had experience to compare real router eg: cisco VS linux router? > > eg: streaming speed... tcp / udp > > Thank you for your information - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: hardenrm at illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign University of Illinois - ICCN -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmdbpcACgkQtuPckBBbXboREgCguTikt2UwEIRHNfoNzASreLD/ YLcAoKdr/Gbw8CQuY9dTitvGQdD3+H0s =bsHP -----END PGP SIGNATURE----- From tme at multicasttech.com Thu Feb 19 10:01:30 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 19 Feb 2009 11:01:30 -0500 Subject: IPv6 Confusion In-Reply-To: <20090219102314.655f3b94@cs.columbia.edu> References: <20090218180034.4e734e58@cs.columbia.edu> <20090219145635.D7F573F44D@pecan.tislabs.com> <20090219150159.GB69199@puck.nether.net> <20090219151919.GB53113@ussenterprise.ufp.org> <20090219102314.655f3b94@cs.columbia.edu> Message-ID: <8B5A97C2-2A9D-4BEC-BB32-354251B13719@multicasttech.com> On Feb 19, 2009, at 10:23 AM, Steven M. Bellovin wrote: > On Thu, 19 Feb 2009 10:19:19 -0500 > Leo Bicknell wrote: > >> In a message written on Thu, Feb 19, 2009 at 10:01:59AM -0500, Jared >> Mauch wrote: >>> >>> Would it be insane to have an IETF back-to-back with a NANOG? >>> >> >> Probably, but it would be a good idea. :) >> >> I have no idea how the IETF agenda is set, but that may be part of >> the trick. I suspect network operators care a lot about protocols >> at lower layers in the stack, and less and less at higher levels >> in the stack. >> >> SeND, DHCP, the RA stuff are all very important to us; some new >> header field in HTTP or IMAP much less so. Since IETF is usually >> 5 days, it would be nice if that lower level stuff could be adjacent >> to NANOG. >> > The IETF agenda isn't set that way -- not even close... > > The big problem I see is that after a week of IETF, I'm *completely* > fried. It's also just a very long time to be away from my family. > > I fully agree. There is no time at any IETF meeting (at least for me, FWIW) to go to other meetings. Note that IETF agenda times are set out some time into the future to avoid conflicts with IEEE 802.1 and other bodies : http://www.ietf.org/meetings/0mtg-sites.txt If you want to pick a date and make a proposal, send it to Ray Pelletier and / or the IAOC iad at ietf.org iaoc at ietf.org Regards Marshall > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From jbates at brightok.net Thu Feb 19 10:08:07 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 19 Feb 2009 10:08:07 -0600 Subject: real hardware router VS linux router In-Reply-To: <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <499D83E7.9010200@brightok.net> Bill Blackford wrote: > In scaling upward. How would a linux router even if a kernel guru were to tweak and compile an optimized build, compare to a 7600/RSP720CXL or a Juniper PIC in ASIC? At some point packets/sec becomes a limitation I would think. It scales quite well, I'm sure, if you take about 12-16 servers, interconnect them at 256+ gigabit, build your own communication protocols between them. Hmmm. This is starting to sound like the Juniper layout prior to them having hardware. :) -Jack From patrick at ianai.net Thu Feb 19 10:23:33 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 19 Feb 2009 11:23:33 -0500 Subject: real hardware router VS linux router In-Reply-To: <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: On Feb 19, 2009, at 10:54 AM, Bill Blackford wrote: > In scaling upward. How would a linux router even if a kernel guru > were to tweak and compile an optimized build, compare to a 7600/ > RSP720CXL or a Juniper PIC in ASIC? At some point packets/sec > becomes a limitation I would think. I've asked this before and been told you can get PCI cards with multiple GigE ports, or even build specialized PCI cards that look like PICs. So I congratulated them on re-inventing Juniper. -- TTFN, patrick From ray at oneunified.net Thu Feb 19 10:30:25 2009 From: ray at oneunified.net (Ray Burkholder) Date: Thu, 19 Feb 2009 12:30:25 -0400 Subject: real hardware router VS linux router In-Reply-To: <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <04d601c992af$5f5cf730$1e16e590$@net> > > In scaling upward. How would a linux router even if a kernel guru were > to tweak and compile an optimized build, compare to a 7600/RSP720CXL or > a Juniper PIC in ASIC? At some point packets/sec becomes a limitation I > would think. > Is anyone building linux/bsd-box add-on cards with off the shelf packet processors? Maybe something with the likes of http://www.netlogicmicro.com/ or whatever? -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean. From morrowc.lists at gmail.com Thu Feb 19 10:44:09 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Feb 2009 11:44:09 -0500 Subject: IPv6 Confusion In-Reply-To: <07cd01c99218$865975d0$930c6170$@net> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <499C87F4.2000401@senie.com> <07cd01c99218$865975d0$930c6170$@net> Message-ID: <75cb24520902190844x34614075md48fc0fb420545e8@mail.gmail.com> On Wed, Feb 18, 2009 at 5:30 PM, Tony Hain wrote: > Daniel Senie wrote: >> >... >> > No, the decision was to not blindly import all the excess crap from >> IPv4. If >> > anyone has a reason to have a DHCPv6 option, all they need to do is >> specify >> > it. The fact that the *nog community stopped participating in the >> IETF has >> > resulted in the situation where functionality is missing, because >> nobody >> > stood up and did the work to make it happen. >> >> Because clearly everything done in IPv4 space was crap, or should be >> assumed to be crap. Therefore, everything that's been worked out and >> made to function well in the last 25+ years in IPv4 space should be >> tossed and re-engineered. OSI anyone? > > That is not what the decision said. The point was that the DHCP WG was not > going to decide for you what was necessary or appropriate to carry forward. > Rather than add baggage that nobody actually uses, there is nothing until > someone says 'I need that'. Never mind that DHCP wasn't defined when the > IPng work started, and wasn't in widespread use yet when DHCPv6 was being > started ... > and ipv4 didnt stop evolving when ipv6 started being designed/engineered/'architected'. If new use cases, or different business cases were evolved in th ev4 world, it seems that those should have also trickled back into the v6 work. That does not seem to have been the case, multihoming is but one example of this. >> >> The point, which seems to elude many, is that rightly or wrongly there >> is an assumption that going from IPv4 to IPv6 should not involve a step >> back in time, not on security, not on central configuration >> capability, >> not on the ability to multihome, and so forth. The rude awakening is >> that the IPv6 evangelists insisting everyone should "get with the >> program" failed to understand that the community at large would expect >> equivalent or better functionality. > > Yes people expect 1:1 functionality, but how many of them are stepping up to how many vendors are implementing willy-nilly v4 feature requests for their enterprise/isp customers? does it not seem reasonable to look at each one and say: "Gosh, if you want a TE knob for v4,surely you'll want that in v6 'soon' yes?" (replace TE knob with ... us about every other knob requested actually). The arguement that 'You have to ask for v6 knobs the exist in v4 else they won't happen' flies in the face of the arguement that: "People don't want v4 or v6, they just want IP connectivity." This doesn't exactly follow for the IETF process, though it really ought to for a goodly number of things. If you are using something in v4, and it got added via the consensus process in the IETF, it's very likely that you will need like functionality in v6. DHCP and Multihoming are just 2 simple examples of this. I still can't see how: "but v6 has autoconf so you don't need dhcp!" is even attempted as an argument after 1996. Surely vendors of networking gear and consumer OS's realized before 1996 that things other than 'address and default route' are important to end stations?? I know these entities use other features in their enterprise networks... > the table with $$$ to make that happen... In the US, it is only the DoD. In > the ISP space, most of it comes from Japan. If you are not finding what you I thougth EU also was spending on v6? -chris From Rich_Andreas at Cable.Comcast.com Thu Feb 19 10:59:11 2009 From: Rich_Andreas at Cable.Comcast.com (Andreas, Rich) Date: Thu, 19 Feb 2009 11:59:11 -0500 Subject: Network SLA In-Reply-To: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> Message-ID: <997BC128AE961E4A8B880CD7442D948009BE290C@NJCHLEXCMB01.cable.comcast.com> Availability cannot be calculated in advance. It typically is based on historical component failure information. Sound design ensures redundancy and eliminates single point of failure. As for the rest, CIR, Latency, Jitter, Loss ..... this can be tested prior to customer handover with any number of tools and protocols including IEEE 802.11ag/ah, ITU-T 1731, IETF RFC2544. Hand-helds are typically not cost effective. Rich Andreas Comcast Network Engineering -----Original Message----- From: Saqib Ilyas [mailto:msaqib at gmail.com] Sent: Thursday, February 19, 2009 10:50 AM To: nanog at nanog.org Subject: Network SLA Greetings I am curious to know about any tools/techniques that a service provider uses to assess an SLA before signing it. That is to say, how does an administrator know if he/she can meet what he is promising. Is it based on experience? Are there commonly used tools for this? Thanks and best regards -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From joelja at bogus.com Thu Feb 19 10:58:24 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 19 Feb 2009 08:58:24 -0800 Subject: real hardware router VS linux router In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <499D8FB0.6000000@bogus.com> Patrick W. Gilmore wrote: > On Feb 19, 2009, at 10:54 AM, Bill Blackford wrote: > >> In scaling upward. How would a linux router even if a kernel guru were >> to tweak and compile an optimized build, compare to a 7600/RSP720CXL >> or a Juniper PIC in ASIC? At some point packets/sec becomes a >> limitation I would think. > > I've asked this before and been told you can get PCI cards with multiple > GigE ports, or even build specialized PCI cards that look like PICs. > > So I congratulated them on re-inventing Juniper. multiport network interfaces substantially predate the existence of asic based l3 forwarding. I can just barely remember what a router looked like in 1991, but our compaq and sun pedestal servers certainly had them. we have variously and in use today as standardized formfactors in embedded network optimized pc platforms. cpci (6u eurocard) - which is neither compact nor pci but I digress pmc xmc atca amc standard pci-e mini-pci-e when when consider that a gen2.0 8x pci-e point-to-point link can carry ~32Gbits/s symmetric the building blocks are certainly there for multiport interfaces and 4xge or 2x10Gbe per slot interfaces are relatively de riguer in pc based filewall/ips/network appliance platforms... From if at xip.at Thu Feb 19 11:15:42 2009 From: if at xip.at (Ingo Flaschberger) Date: Thu, 19 Feb 2009 18:15:42 +0100 (CET) Subject: real hardware router VS linux router In-Reply-To: <499D8FB0.6000000@bogus.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> Message-ID: this plattform can handle about 100.000pps and 400mbit 1500byte packets with freebsd http://lannerinc.com/Network_Application_Platforms/x86_Network_Appliance/1U_Network_Appliances/FW-7550 hardware: 4x pci 32bit, 33mhz intel gbit 1gb cf-card 1gb ram with this hardware even more pps should be possible: http://www.axiomtek.de/network_appliances/network_appliances/smb_network_security_platform/na820.html hardware: 7x pcie (1lane each) connected network add freebsd-net mailinglist people achieved nearly 1.000.000pps with servers (hp-servers) I suggest to use freebsd os if quagga is the routing daemon as quagga runs more stable than on linux. I have currently 300days uptime at my border routers (2x FW-7550), last week I had a peak with 230mbit's; no problem to handle. Kind regards, ingo flaschberger From mohacsi at niif.hu Thu Feb 19 11:18:13 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 19 Feb 2009 18:18:13 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: <75cb24520902190844x34614075md48fc0fb420545e8@mail.gmail.com> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <499C87F4.2000401@senie.com> <07cd01c99218$865975d0$930c6170$@net> <75cb24520902190844x34614075md48fc0fb420545e8@mail.gmail.com> Message-ID: On Thu, 19 Feb 2009, Christopher Morrow wrote: >> >> That is not what the decision said. The point was that the DHCP WG was not >> going to decide for you what was necessary or appropriate to carry forward. >> Rather than add baggage that nobody actually uses, there is nothing until >> someone says 'I need that'. Never mind that DHCP wasn't defined when the >> IPng work started, and wasn't in widespread use yet when DHCPv6 was being >> started ... >> > > and ipv4 didnt stop evolving when ipv6 started being > designed/engineered/'architected'. If new use cases, or different > business cases were evolved in th ev4 world, it seems that those > should have also trickled back into the v6 work. That does not seem to > have been the case, multihoming is but one example of this. Nobody will stop you to go to RIR and argue for a PI address space for IPv6. You will be able use PI IPv6 address similarly as you used PI IPv4. > This doesn't exactly follow for the IETF process, though it really > ought to for a goodly number of things. If you are using something in > v4, and it got added via the consensus process in the IETF, it's very > likely that you will need like functionality in v6. DHCP and > Multihoming are just 2 simple examples of this. I still can't see how: > "but v6 has autoconf so you don't need dhcp!" is even attempted as an > argument after 1996. Surely vendors of networking gear and consumer > OS's realized before 1996 that things other than 'address and default > route' are important to end stations?? I know these entities use other > features in their enterprise networks... In IPv6 you have additional options next to static and DHCP the autoconfiguration. Since autoconfiguration was developed earlier this assumed to be avilable most of the IPv6 implementation. You can argue, that DHCPv6 client support is vital part of IPv6 node requirements... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > >> the table with $$$ to make that happen... In the US, it is only the DoD. In >> the ISP space, most of it comes from Japan. If you are not finding what you > > I thougth EU also was spending on v6? > > -chris > > From VLeonard at TarrantCounty.com Thu Feb 19 11:19:43 2009 From: VLeonard at TarrantCounty.com (Vernon Leonard) Date: Thu, 19 Feb 2009 11:19:43 -0600 Subject: single fiber 10Gb/s X2 or Xenpak transceiver In-Reply-To: <9be3e6fd0902190218x49ea0ee6t9ce935db9cca6466@mail.gmail.com> References: <9be3e6fd0902190218x49ea0ee6t9ce935db9cca6466@mail.gmail.com> Message-ID: <01C251110E9D20459139A69431CDE21005CEE21B@ade2kbe05.tarrantcounty.com> We just got in 4 of the X2's. Vernon Leonard Tarrant County IT -----Original Message----- From: Andrey Slastenov [mailto:a.slastenov at gmail.com] Sent: Thursday, February 19, 2009 4:18 AM To: nanog Subject: single fiber 10Gb/s X2 or Xenpak transceiver Hi Guys. Do you ever see single fiber 10Gb/s X2 or Xenpak transceiver? (I know about SFP, but never see X2 or Xenpak before) From isabeldias1 at yahoo.com Thu Feb 19 11:27:33 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Thu, 19 Feb 2009 09:27:33 -0800 (PST) Subject: Network SLA In-Reply-To: <997BC128AE961E4A8B880CD7442D948009BE290C@NJCHLEXCMB01.cable.comcast.com> Message-ID: <262551.38087.qm@web52610.mail.re2.yahoo.com> Maybe the best way of addressing this is knowing exactly what we need to measure- if IP traffic, services or processes. If the timescale of a process (ie: MTTR's)and/or procedure or just data and/or voice traffic from point A to B. Or just scoping the measurments as being the performance of the core network, or only related to usage based service. And that takes us to the TMN model and to the bottom-up approach starting w/ the FCAPs. you have fereware, shareware and licenced tools or most likely specific vendor-related tools and only linked to one vendor or one type of equipment. I am sure you've heard of RRD/MRTG, just like a few others that normally sit on the botton tier and have an upstream chain correlating the events. Most times the options are about suitablity and what the software version is prepared to report on so they are seen as more "suitable" to customers. --- On Thu, 2/19/09, Andreas, Rich wrote: > From: Andreas, Rich > Subject: RE: Network SLA > To: "Saqib Ilyas" , nanog at nanog.org > Date: Thursday, February 19, 2009, 5:59 PM > Availability cannot be calculated in advance. It typically > is based on > historical component failure information. Sound design > ensures > redundancy and eliminates single point of failure. > > As for the rest, CIR, Latency, Jitter, Loss ..... this can > be tested > prior to customer handover with any number of tools and > protocols > including IEEE 802.11ag/ah, ITU-T 1731, IETF RFC2544. > Hand-helds are > typically not cost effective. > > Rich Andreas > Comcast Network Engineering > -----Original Message----- > From: Saqib Ilyas [mailto:msaqib at gmail.com] > Sent: Thursday, February 19, 2009 10:50 AM > To: nanog at nanog.org > Subject: Network SLA > > Greetings > I am curious to know about any tools/techniques that a > service provider > uses > to assess an SLA before signing it. That is to say, how > does an > administrator know if he/she can meet what he is promising. > Is it based > on > experience? Are there commonly used tools for this? > Thanks and best regards > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences From drais at icantclick.org Thu Feb 19 11:30:55 2009 From: drais at icantclick.org (david raistrick) Date: Thu, 19 Feb 2009 12:30:55 -0500 (EST) Subject: Network SLA In-Reply-To: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> Message-ID: On Thu, 19 Feb 2009, Saqib Ilyas wrote: > I am curious to know about any tools/techniques that a service provider uses > to assess an SLA before signing it. That is to say, how does an > administrator know if he/she can meet what he is promising. IME, the administrators don't have anything to do with what is signed. The "company" chooses what SLAs to sign with customers (typically whatever the customer requests, possibly with various levels of pricing for different agreements), but the operational staff are not involved. If you're lucky, you have this information before you build and can -try- to build to suite. But most times, the SLAs are signed after you've built, and everyone just crosses their fingers. IME. ..david --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From alh-ietf at tndh.net Thu Feb 19 11:48:42 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 19 Feb 2009 09:48:42 -0800 Subject: IPv6 Confusion In-Reply-To: References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> Message-ID: <08cb01c992ba$4e1c0000$ea540000$@net> Randy Bush wrote: > > The fact that the *nog community stopped participating in the IETF > has > > resulted in the situation where functionality is missing, because > nobody > > stood up and did the work to make it happen. > > the ops gave up on the ietf because it did no good to participate. so > the choice was spend the time accomplishing nothing or do something > else > with one's time. > > this is a slight exaggeration. it took me less than five years to get > rid of NLAs, TLAs, ... wooo wooo! Those were put in at the insistence of the ops / routing community as a way to constrain the routing table, by using the technology definition as a way to enforce a no-PI policy. The fact that it moved policy control from the RIRs to the IETF was later recognized as a problem, and moving it back was what took the time. The 'give-up' attitude is now coming home as a set of definitions that are not meeting the operational needs. This is not a criticism of anyone, but the general global expectation of instant gratification is causing people to give up on long cycle issues that need active feedback to keep the system in check. Many in the *nog community criticize their management for having a long-range vision that only reaches to the end of the next quarter, and this is a case where the engineering side of the house is not looking far enough forward. If you don't give the vendors a couple of years notice that you require IPv6, don't expect it to be what you want. Then if you expect multiple vendors to implement something close to the same and the way you want it, you need to engage at the IETF to make sure the definition goes the right way. Working group chairs are supposed to be facilitators for the work of the group, not dictators. If you are having a problem with a WG chair, inform the AD. If that doesn't help, inform the nomcom that the AD is not responsive. Giving up will only let the system run open-loop, and you should not be surprised when the outcome is not what you expect. Tony From dholmes at mwdh2o.com Thu Feb 19 11:49:15 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 19 Feb 2009 09:49:15 -0800 Subject: Single fiber 10Gb/s X2 or Xenpak transceiver In-Reply-To: <9be3e6fd0902190106s5ef4f061nd80921aee28b9480@mail.gmail.com> References: <9be3e6fd0902190106s5ef4f061nd80921aee28b9480@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E086A29B0@usmsxt104.mwd.h2o> Haven't seen one. With the huge heat sink and serialization circuitry on the X2, what advantage would a single strand connector bring? MRV may have one if anyone does, though. -----Original Message----- From: Andrey Slastenov [mailto:a.slastenov at gmail.com] Sent: Thursday, February 19, 2009 1:06 AM To: nanog at nanog.org Subject: Single fiber 10Gb/s X2 or Xenpak transceiver Hi Guys. Do you ever see single fiber 10Gb/s X2 or Xenpak transceiver? (I know about SFP, but never see X2 or Xenpak before) From dholmes at mwdh2o.com Thu Feb 19 11:51:44 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 19 Feb 2009 09:51:44 -0800 Subject: Network SLA In-Reply-To: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E086A29B5@usmsxt104.mwd.h2o> We use the BRIX active measurement instrumentation product to measure round-trip, jitter, and packet loss SLA conformity. -----Original Message----- From: Saqib Ilyas [mailto:msaqib at gmail.com] Sent: Thursday, February 19, 2009 7:50 AM To: nanog at nanog.org Subject: Network SLA Greetings I am curious to know about any tools/techniques that a service provider uses to assess an SLA before signing it. That is to say, how does an administrator know if he/she can meet what he is promising. Is it based on experience? Are there commonly used tools for this? Thanks and best regards -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From alh-ietf at tndh.net Thu Feb 19 11:59:12 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 19 Feb 2009 09:59:12 -0800 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <072401c9920d$cb823cb0$6286b610$@net> Message-ID: <08cc01c992bb$c5b171d0$51145570$@net> David Conrad wrote: > Tony, > > On Feb 18, 2009, at 11:13 AM, Tony Hain wrote: > > The bottom line is, if you want something to be defined in a way > > that works for you, you have to participate in the definition. > > Well, yes. But there is an impedance mismatch here. No argument. > > The IETF still seems to operate under the assumption that the folks > who run the networks are the same folks who implement the code the > network runs on top of. I figure this (mostly) stopped being the case > (at least for the "production Internet") sometime in the mid-90s. > Today, network operators and end users are the folks who are > specifying requirements. Folks who go to IETFs are the ones who are > trying to figure out the protocols to meet those requirements, or at > least what they believe those requirements to be. Unfortunately, > that's not what we have. We have network operators in their own > little world, trying to keep the network running and protocol > developers in their own little world, trying to come up with cool > features that will make their protocols relevant, based on their own > beliefs as to what is important or not. These two camps seem to > intersect rarely. Outside of a handful of people that make a point of it, there is almost no interaction. > > As such, it isn't particularly surprising when IETF protocol > developers tell network operators who go to the IETF they aren't > relevant. In the specific definition of protocol bits on the wire, > network operators actually aren't that relevant. Network operators > care about the functionality and multi-vendor interoperability, > whether it is bit 8 in the second octet or bit 4 in the third octet > that results in that functionality isn't a big concern (as long as > everyone agrees). The network operators tell the vendors what sort of > functionality they need, and the vendors go to the IETF to push their > particular approach to address those requirements (or block another > vendor's approach). This may be where Randy Bush derives his "IVTF" > label. > > The problem is, since around the mid-90s, it seems we've taken it too > far. The fact that the IETF has demonstrably ignored network operator > input in stuff like DHCP or routing scalability means the IETF has > developed protocols that don't meet network operator requirements. > And because network operators can't be bothered to learn and argue the > bit patterns, their ability to provide input into protocol definition > is reduced to yelling from the sidelines or communicating via proxies > with their own agendas. Well, for awhile there was a push to develop 'requirements' RFCs, but without participation from the ops community, these did little and were widely chastised as a waste of time. I personally disagree with that, as anytime you get more than a couple of people working on a problem you need to write down the expected outcome to keep everyone on track. In any case, there is a place to put high-level requirements into the system, it just needs to be exercised. > > Yes, there have been attempts to bridge the two camps, but I suspect > the only way to really address this is a fundamental shift in the way > the IETF does business, taking into account the fact that network > operators and end users, by and large, are not the implementors of > protocols and don't actually care how they are implemented, but rather > the folks who define what the protocols need to do. I'll admit some > skepticism that such a change is actually feasible. It is easy to throw rocks and say that the other guy needs to change. Reality is that both sides need to move toward each other. There is nothing that says the ops community has to stay involved throughout the entire bit-positioning set of arguments, but if they don't engage at requirements definition time there is no hope that the outcome will be close to what they want. Tony From alh-ietf at tndh.net Thu Feb 19 12:23:44 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 19 Feb 2009 10:23:44 -0800 Subject: IPv6 Confusion In-Reply-To: <75cb24520902190844x34614075md48fc0fb420545e8@mail.gmail.com> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <499C87F4.2000401@senie.com> <07cd01c99218$865975d0$930c6170$@net> <75cb24520902190844x34614075md48fc0fb420545e8@mail.gmail.com> Message-ID: <08eb01c992bf$32eea800$98cbf800$@net> christopher.morrow at gmail.com wrote: > >... > > Yes people expect 1:1 functionality, but how many of them are > stepping up to > > how many vendors are implementing willy-nilly v4 feature requests for > their enterprise/isp customers? does it not seem reasonable to look at > each one and say: "Gosh, if you want a TE knob for v4,surely you'll > want that in v6 'soon' yes?" (replace TE knob with ... us about every > other knob requested actually). The arguement that 'You have to ask > for v6 knobs the exist in v4 else they won't happen' flies in the face > of the arguement that: "People don't want v4 or v6, they just want IP > connectivity." The reality is that people are telling the vendor 'I need X NOW, don't bother with slowing down to make IPv6 work while you are at it'. Since the list of X is never ending, nobody ever gets time to go back and add IPv6. If you expect IPv6 in your products, you have to put money on the table. Expecting that a vendor will do something that you are telling them not to by your procurement habits, is really silly. > > This doesn't exactly follow for the IETF process, though it really > ought to for a goodly number of things. If you are using something in > v4, and it got added via the consensus process in the IETF, it's very > likely that you will need like functionality in v6. No, the ops community does not use everything that the IETF turns out. How many people still use SLIP, RIP, EGP, SMTP over X.25, IP over ARCNET, FDDI-mib, ...??? The IETF needs operational input about what is really useful, and that has to come from people that are running networks. > DHCP and > Multihoming are just 2 simple examples of this. I still can't see how: > "but v6 has autoconf so you don't need dhcp!" is even attempted as an > argument after 1996. Surely vendors of networking gear and consumer > OS's realized before 1996 that things other than 'address and default > route' are important to end stations?? I know these entities use other > features in their enterprise networks... There are vast differences in how enterprise networks are run today than they were 10 years ago, and in both cases they are different than how consumer networks are run. Again, this group is composed of professional network managers, and they want explicit knobs to manage things. Other environments don't care about those knobs and shouldn't be required to understand and tweak them. Both are valid and need to operate independently of the other. > > > the table with $$$ to make that happen... In the US, it is only the > DoD. In > > the ISP space, most of it comes from Japan. If you are not finding > what you > > I thougth EU also was spending on v6? The EU talks a lot, but outside of the 6net/6diss projects has not really put much money behind it, that I am aware of. Even those efforts were more about documenting what was operationally possible at the time than they were about defining requirements. Tony From surfer at mauigateway.com Thu Feb 19 12:34:00 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 19 Feb 2009 10:34:00 -0800 Subject: more AS prepend antics? Message-ID: <20090219103400.8C154ED9@resin11.mta.everyone.net> --- nrauhauser at gmail.com wrote: From: neal rauhauser What in the world is someone doing with that many prepends? I'm trying to envision what would drive such a decision - small, regional player on one ------------------------------------------- Playing with the internet just to see what happens? ;-) scott From steve at ibctech.ca Thu Feb 19 13:02:24 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 19 Feb 2009 14:02:24 -0500 Subject: real hardware router VS linux router In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> Message-ID: <499DACC0.8040709@ibctech.ca> Ingo Flaschberger wrote: > > this plattform can handle about > 100.000pps and 400mbit 1500byte packets with freebsd > http://lannerinc.com/Network_Application_Platforms/x86_Network_Appliance/1U_Network_Appliances/FW-7550 > > hardware: > 4x pci 32bit, 33mhz intel gbit > 1gb cf-card > 1gb ram > > with this hardware even more pps should be possible: > http://www.axiomtek.de/network_appliances/network_appliances/smb_network_security_platform/na820.html > > hardware: > 7x pcie (1lane each) connected network A very quick test through a box much like the one in your latter link, running FBSD 7.1, Quagga, and many IPFW rules, to a machine that is not very busy: receiver% netstat -h -w 1 input (Total) output packets errs bytes packets errs bytes colls 1 0 60 1 0 170 0 1 0 60 1 0 170 0 1 0 60 1 0 170 0 1 0 60 1 0 170 0 47K 0 28M 1 0 170 0 132K 0 77M 1 0 170 0 133K 0 78M 1 0 170 0 133K 0 78M 1 0 170 0 131K 0 77M 1 0 170 0 132K 0 77M 1 0 170 0 132K 0 78M 1 0 170 0 133K 0 78M 1 0 170 0 Steve From hescominsoon at emmanuelcomputerconsulting.com Thu Feb 19 14:09:31 2009 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Thu, 19 Feb 2009 15:09:31 -0500 Subject: real hardware router VS linux router In-Reply-To: <499D6E99.1090706@uiuc.edu> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> Message-ID: <499DBC7B.3080108@emmanuelcomputerconsulting.com> On 2/19/2009 9:37 AM, Ryan Harden wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > While you could probably build a linux router that is just as fast as a > real hardware router, you're always going to run into the moving pieces > part of the equation. > > In almost all scenarios, moving parts are more prone to failure than > non-moving parts. > > Regardless of what you find out in your research, consider the above in > your cost-benefit analysis. > > /Ryan > > Deric Kwok wrote: > >> Hi All >> >> Actually, what is the different hardware router VS linux router? >> >> Have you had experience to compare real router eg: cisco VS linux router? >> >> eg: streaming speed... tcp / udp >> >> Thank you for your information >> > > - -- > Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 > CITES - Network Engineering Cell: 630-363-0365 > 2130 Digital Computer Lab Fax: 217-244-7089 > 1304 W. Springfield email: hardenrm at illinois.edu > Urbana, IL 61801 > > University of Illinois at Urbana/Champaign > University of Illinois - ICCN > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkmdbpcACgkQtuPckBBbXboREgCguTikt2UwEIRHNfoNzASreLD/ > YLcAoKdr/Gbw8CQuY9dTitvGQdD3+H0s > =bsHP > -----END PGP SIGNATURE----- > > > ssd's remove the spindle from the equation..otherwise they both have fans that do fail. From zaid at zaidali.com Thu Feb 19 14:09:37 2009 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 19 Feb 2009 12:09:37 -0800 (PST) Subject: do I need to maintain with RADB? In-Reply-To: <8559380.1411235074104312.JavaMail.zaid@turing-2.local> Message-ID: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> Hi, need some advise here. Do I still need to maintain my objects (and pay) RADB? I use ARIN as source and all my route objects can be verified with a whois. Thanks, Zaid From rodunn at cisco.com Thu Feb 19 14:15:02 2009 From: rodunn at cisco.com (Rodney Dunn) Date: Thu, 19 Feb 2009 15:15:02 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <20090217222701.GL21284@rtp-cse-489.cisco.com> References: <20090217185434.GA9548@ajax.opentransit.net> <499B1384.8030201@rockynet.com> <005201c9913a$26a1d300$0a00000a@nil.si> <20090217201157.GP17200@rtp-cse-489.cisco.com> <20090217223149.GB11589@ajax.opentransit.net> <20090217222701.GL21284@rtp-cse-489.cisco.com> Message-ID: <20090219201502.GU10344@rtp-cse-489.cisco.com> We are working on a document for Cisco.com but in the interim here is the bug that will fix the issue of a Cisco IOS device sending an incorrectly formatted BGP update when as a result of prepending it goes over 255 AS hops. Note: The Title and Release-note on bug toolkit may be a bit different as I just updated it to be more accurate. Of all the scenarios I've looked at (thanks to those that responded offline) there wasn't a condition found where this could happen without AS path prepending being used. Please respond offline or let's move the discussion over to cisco-nsp at this point. CSCsx73770 Invalid BGP formatted update causes peer reset with AS prepending Symptom: A Cisco IOS device that receives a BGP update message and as a result of AS prepending needs to send an update downstream that would have over 255 AS hops will send an invalid formatted update. This update when received by a downstream BGP speaker triggers a NOTIFICATION back to the sender which results in the BGP session being reset. Conditions: This problem is seen when a Cisco IOS device receives a BGP update and due to a combination of either inbound, outbound, or both AS prepending it needs to send an update downstream that has more than 255 AS hops. Workaround: The workaround is to implement bgp maxas-limit X on the device that after prepending would need to send an update with over 255 AS hops. Since IOS limits the inbound prepending value to 10 the most that could be added iss 11 AS hops (10 on ingress, 10 on egress, and 1 for normal eBGP AS hop addition). Therefore, a conservative value to configure would be 200 to prevent this condition. Full support of Section 5.1.2 of RFC4271 is being tracked under CSCsx75937 Add BGP support of AS paths longer than 255 per Section 5.1.2 of RFC4271 Thanks to those that worked offline with us to verify the field results reported. Rodney On Tue, Feb 17, 2009 at 05:27:01PM -0500, Rodney Dunn wrote: > If you want to take this offline send it unicast or we could > move it to cisco-nsp. > > What scenarios are you seeing that appear broken other than > when a notification is sent when a > 255 hop update is received? > That's the one I'm working on right now. > > Rodney > > On Tue, Feb 17, 2009 at 05:31:49PM -0500, German Martinez wrote: > > On Tue Feb 17, 2009, Rodney Dunn wrote: > > > > Hello Rodney, > > It will be great if you can share with us your findings. It seems > > like we are hitting different bugs in different platforms. > > > > Thanks > > German > > > > > Ivan, > > > > > > It is confusing but from what I have tested you have it correct. > > > > > > The confusing part comes from multiple issues. > > > > > > a) The documentation about the default maxas limit being 75 appears to be > > > incorrect. I'll get that fixed. > > > > > > b) Prior to CSCee30718 there was a hard limit of 255. After that fix > > > AS sets of more than 255 should work. > > > > > > c) CSCeh13489 implemented the maxas command to mark it as invalid and > > > not send. > > > > > > > > > There does appear to be an issue when you cross the 255 boundary > > > and the next hop router sends a notification back. > > > > > > I've got it recreated in the lab and we are working to clearly understand > > > why that is. I'll post an update once we have more. > > > > > > The way to prevent it is the upstream device that crosses the 255 boundary > > > on sending needs to use the maxas limit command to keep it less than 255. > > > > > > It doesn't work on the device that receives the update with the AS path > > > larger than 255. > > > > > > Rodney > > > > > > On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > > > > We were dropping ALL prefixes and the eBGP session was still > > > > > resetting. > > > > > > > > Upstream or downstream? > > > > > > > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > > > > on the IOS we were using. That is: it was previously verified > > > > > to be working just fine to drop paths longer than 75, but > > > > > once we started receiving paths > > > > > > 255 then BGP started resetting. > > > > > > > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The > > > > paths were generated by Quagga BGP daemon. > > > > > > > > 12.2SRC causes the downstream session to break when the installed AS-path > > > > length is close to 255 and you use downstream AS-path prepending. > > > > > > > > In your case, I'm assuming you were hit with an older bug (probably at the > > > > 128 AS-path length boundary). It would be very hard to generate just the > > > > right AS-path length to unintentionally break your upstream EBGP session (as > > > > I said before, it's a nice targeted attack if you know your downstream > > > > topology). > > > > > > > > If your IOS is vulnerable to the older bugs that break inbound processing of > > > > AS paths longer than 128, there's nothing you can do on your end. The > > > > internal BGP checks reject the inbound update before the inbound filters (or > > > > bgp maxas-limit) can touch it and reset the upstream BGP session. > > > > > > > > Hope this helps > > > > Ivan > > > > > > > > Disclaimer: as I don't have internal access to Cisco, all of the above is a > > > > result of lab tests. > > > > > From netfortius at gmail.com Thu Feb 19 14:16:42 2009 From: netfortius at gmail.com (Stefan) Date: Thu, 19 Feb 2009 14:16:42 -0600 Subject: Network SLA In-Reply-To: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> Message-ID: <499DBE2A.6020907@gmail.com> Saqib Ilyas wrote: > Greetings > I am curious to know about any tools/techniques that a service provider uses > to assess an SLA before signing it. That is to say, how does an > administrator know if he/she can meet what he is promising. Is it based on > experience? Are there commonly used tools for this? > Thanks and best regards > Not necessarily as a direct answer (I am pretty sure there'll be others on this list giving details in the area of specific tools and standards), but I think this may be a question (especially considering your end result concern: *signing the SLA!) equally applicable to your legal department. In the environment we live, nowadays, the SLA could (should?!? ... unfortunately) be "refined" and (at the other end - i.e. receiving) "interpreted" by the lawyers, with possibly equal effects (mostly financial and as overall impact on the business) as the tools we (the technical people) would be using to measure latency, uptime, bandwidth, jitter, etc... Stefan From jlewis at lewis.org Thu Feb 19 14:17:17 2009 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 19 Feb 2009 15:17:17 -0500 (EST) Subject: do I need to maintain with RADB? In-Reply-To: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> References: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> Message-ID: On Thu, 19 Feb 2009, Zaid Ali wrote: > Hi, need some advise here. Do I still need to maintain my objects (and > pay) RADB? I use ARIN as source and all my route objects can be verified > with a whois. If your objects are all maintained via another routing registry (ARIN's, altdb, etc.) and you don't care to maintain objects with radb.ra.net, then you do not need to pay RADB maintenance fees. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From billn at billn.net Thu Feb 19 14:30:52 2009 From: billn at billn.net (Bill Nash) Date: Thu, 19 Feb 2009 13:30:52 -0700 Subject: real hardware router VS linux router In-Reply-To: <499DACC0.8040709@ibctech.ca> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> Message-ID: You know you're off track when.. What operational relevance does this conversation, or the similiar ones that came before it, have? Are there a bunch in production contributing to the degradation of the best route between me and this video of cute kittens I'm trying to watch? Did something of this breed cause some eastern europe bgp flappy flappy this week? I've got BGP and OSPF speaking Linux machines under my care, but I don't think everyone wants to hear about them unless they're out of control like the cast of Lord of the Flies set loose in a supermarket. Having carped, I'm obligated to offer a solution: The technical discussion is certainly interesting to a small subset of NANOG participants, I'm sure (I do find it interesting, I promise), but I'm thinking this conversation is better elsewhere, like a beer & gear, or might I recommend forming some kind of nanog-shoptalk sub list? Is there one like it? Something for discussing the network substrata and not the weather a few layers up? I'm aware of stuff like c-nsp/j-nsp, but the Linux router crowd has it's own niche and there's certainly a place for discussing them, I just don't think it's.. here. - billn From Valdis.Kletnieks at vt.edu Thu Feb 19 14:47:27 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Feb 2009 15:47:27 -0500 Subject: real hardware router VS linux router In-Reply-To: Your message of "Thu, 19 Feb 2009 09:30:16 EST." <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Message-ID: <32530.1235076447@turing-police.cc.vt.edu> On Thu, 19 Feb 2009 09:30:16 EST, Deric Kwok said: > Hi All > > Actually, what is the different hardware router VS linux router? I'm continually amazed by the number of people who manage to conflate two entirely different issues here. There's *TWO* axes here: | PC-class hardware | routing-blade-architecture hardware -----------+-----------------------+----------------------------------- proprietary| | -----------+-----------------------+----------------------------------- open-source| | Kinda like that. A Juniper box (which is a BSD running on something that's *not* PC-class hardware) is a prime example that it's not "hardware versus linux" - it's two separate questions. 1) Is PC-class gear "good enough"? Do you have the hardware interfaces needed, and the I/O backplanes? Or is something with more oomph needed? 2) Does the software running on the box support the feature set you need? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From randy at psg.com Thu Feb 19 15:09:49 2009 From: randy at psg.com (Randy Bush) Date: Fri, 20 Feb 2009 06:09:49 +0900 Subject: IPv6 Confusion In-Reply-To: <08cb01c992ba$4e1c0000$ea540000$@net> References: <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <056801c9914d$7c2a0e10$747e2a30$@net> <499C63D8.2070100@kl.net> <499C656A.2040304@foobar.org> <154AAAE4-5F6F-4FFE-B702-40E2FA6A75CA@nbtsc.org> <20090218203406.GB4391@ussenterprise.ufp.org> <075b01c99211$71aa3810$54fea830$@net> <08cb01c992ba$4e1c0000$ea540000$@net> Message-ID: >> this is a slight exaggeration. it took me less than five years to get >> rid of NLAs, TLAs, ... wooo wooo! > Those were put in at the insistence of the ops / routing >> community complete and utter bs! randy From darren at bolding.org Thu Feb 19 15:15:40 2009 From: darren at bolding.org (Darren Bolding) Date: Thu, 19 Feb 2009 13:15:40 -0800 Subject: do I need to maintain with RADB? In-Reply-To: References: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> Message-ID: <5a318d410902191315q4d168078qa075dbb79411480f@mail.gmail.com> Is there a good source to explain the whole RADB "system", and tools/processes people use to maintain routing policies/filters based on it? I'd like to both review and make sure my current understanding is accurate, and have a doc to send people to. Thanks for any pointers! --D On Thu, Feb 19, 2009 at 12:17 PM, Jon Lewis wrote: > On Thu, 19 Feb 2009, Zaid Ali wrote: > > Hi, need some advise here. Do I still need to maintain my objects (and >> pay) RADB? I use ARIN as source and all my route objects can be verified >> with a whois. >> > > If your objects are all maintained via another routing registry (ARIN's, > altdb, etc.) and you don't care to maintain objects with radb.ra.net, then > you do not need to pay RADB maintenance fees. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > -- -- Darren Bolding -- -- darren at bolding.org -- From swmike at swm.pp.se Thu Feb 19 15:20:48 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 19 Feb 2009 22:20:48 +0100 (CET) Subject: lots of prepends Message-ID: Today 85.119.176.0/21 was announced by AS20912 with 177 prepends. I noticed 20912 modulo 256 is 176. AS47868 modulo 256 is 252 which matches this mondays prepend-incident. So, what router OS will put 20912 into a byte and thus end up with 176 in something like "set as-path prepend last-as " ? It needs to be fixed. Has anyone noticed any ill effects with IOS and using "bgp max-as"? Will it just drop any prefixes with long as-paths and no other ill operational effects? -- Mikael Abrahamsson email: swmike at swm.pp.se From pstewart at nexicomgroup.net Thu Feb 19 15:24:27 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 19 Feb 2009 16:24:27 -0500 Subject: lots of prepends In-Reply-To: References: Message-ID: <89D27DE3375BB6428DDCC2927489826A0203DF1A@nexus.nexicomgroup.net> Just seen that here too: Feb 19 16:20:35: %BGP-6-ASPATH: Long AS path 8001 8928 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 received from 207.99.64.25: More than configured MAXAS-LIMIT Our AS path limit is 100 which is way too high in my opinion but regardless I was trying to figure out any logic in this.... I can remember prepending one of our upstreams 4X at one point thinking that was a bit nuts .... thankfully we don't prepend anyone these days.... Paul -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: Thursday, February 19, 2009 4:21 PM To: nanog at nanog.org Subject: lots of prepends Today 85.119.176.0/21 was announced by AS20912 with 177 prepends. I noticed 20912 modulo 256 is 176. AS47868 modulo 256 is 252 which matches this mondays prepend-incident. So, what router OS will put 20912 into a byte and thus end up with 176 in something like "set as-path prepend last-as " ? It needs to be fixed. Has anyone noticed any ill effects with IOS and using "bgp max-as"? Will it just drop any prefixes with long as-paths and no other ill operational effects? -- Mikael Abrahamsson email: swmike at swm.pp.se ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From kb3ien+nanog at databit7.com Thu Feb 19 15:43:24 2009 From: kb3ien+nanog at databit7.com (kb3ien+nanog at databit7.com) Date: Thu, 19 Feb 2009 21:43:24 +0000 (UTC) Subject: No subject Message-ID: protect users from victimisation by the likes of this : http://www.bleepingcomputer.com/forums/topic204619.html For years (decades?) I've been DNS hijacking to criple worm ridden machines associating with my wifi nodes etc. That only deals with a few threats. I'd like to feel confident in using blackhole routes to combat maleware proliferation too. Any tools available to age out male-routes after a given period of time? Robin David Hammond KB3IEN n.y.c. ares From sethm at rollernet.us Thu Feb 19 15:50:11 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 19 Feb 2009 13:50:11 -0800 Subject: lots of prepends In-Reply-To: References: Message-ID: <499DD413.8000808@rollernet.us> Mikael Abrahamsson wrote: > > Today 85.119.176.0/21 was announced by AS20912 with 177 prepends. I > noticed 20912 modulo 256 is 176. AS47868 modulo 256 is 252 which matches > this mondays prepend-incident. > > So, what router OS will put 20912 into a byte and thus end up with 176 > in something like "set as-path prepend last-as " ? It > needs to be fixed. > > Has anyone noticed any ill effects with IOS and using "bgp max-as"? Will > it just drop any prefixes with long as-paths and no other ill > operational effects? > No ill effects here, but I never saw the others before this one, and I'm only seeing it via 3561. 010308: Feb 19 13:08:13.455 PDT: %BGP-6-ASPATH: Long AS path 3561 3257 8928 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 received from 216.88.158.93: More than configured MAXAS-LIMIT ~Seth From randy at psg.com Thu Feb 19 15:54:24 2009 From: randy at psg.com (Randy Bush) Date: Fri, 20 Feb 2009 06:54:24 +0900 Subject: IPv6 Confusion In-Reply-To: <20090219145635.D7F573F44D@pecan.tislabs.com> References: <20090218180034.4e734e58@cs.columbia.edu> <20090219145635.D7F573F44D@pecan.tislabs.com> Message-ID: >> I can't think of a single working group chair/co-chair that's >> ever presented at NANOG and asked for feedback. > Were you at the last NANOG when I did everything but beg for feedback? no i was not but leo's post was simple flatulence randy From pstewart at nexicomgroup.net Thu Feb 19 15:54:47 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 19 Feb 2009 16:54:47 -0500 Subject: lots of prepends In-Reply-To: <499DD413.8000808@rollernet.us> References: <499DD413.8000808@rollernet.us> Message-ID: <89D27DE3375BB6428DDCC2927489826A0203DF52@nexus.nexicomgroup.net> The only ill effect is if set it too low.... we tested it a bit at 20-30 AS path length range figuring we shouldn't see *much* and it was staggering over time. The unfortunate thing more related to your question is that we found some AS's that were prepending 40-50 times to ALL their upstreams so with max-as set too low we had no routing to them at all! We've had it set to 100 for quite a while now and no side effects.... Paul -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Thursday, February 19, 2009 4:50 PM To: nanog at nanog.org Subject: Re: lots of prepends Mikael Abrahamsson wrote: > > Today 85.119.176.0/21 was announced by AS20912 with 177 prepends. I > noticed 20912 modulo 256 is 176. AS47868 modulo 256 is 252 which matches > this mondays prepend-incident. > > So, what router OS will put 20912 into a byte and thus end up with 176 > in something like "set as-path prepend last-as " ? It > needs to be fixed. > > Has anyone noticed any ill effects with IOS and using "bgp max-as"? Will > it just drop any prefixes with long as-paths and no other ill > operational effects? > No ill effects here, but I never saw the others before this one, and I'm only seeing it via 3561. 010308: Feb 19 13:08:13.455 PDT: %BGP-6-ASPATH: Long AS path 3561 3257 8928 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 received from 216.88.158.93: More than configured MAXAS-LIMIT ~Seth ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From nanog at confluence.com Thu Feb 19 16:02:20 2009 From: nanog at confluence.com ((nanog) Brian Battle) Date: Thu, 19 Feb 2009 17:02:20 -0500 Subject: Network diagram software In-Reply-To: <20090211144206.GA2731@kallisti.us> References: <3e306c60902110506l4d539149w25b1a49298b70d40@mail.gmail.com> <20090211144206.GA2731@kallisti.us> Message-ID: <3489C3AADB49634BB93992EE12DCAD7705CA8112@NEWMAN.confluence.com> Graphviz will do this. (www.graphviz.org) The basic (dot) syntax for what you describe below is: digraph G { R1 -> VLAN100; R2 -> R1; SW1 -> VLAN100; SW2 -> R2; H1 -> SW1; H2 -> SW1; H3 -> SW2; H4 -> SW2; } It'll output a GIF flowchart-style diagram with the nodes connected as described above. It's also good for visualizing BGP AS paths . -----Original Message----- From: Ross Vandegrift [mailto:ross at kallisti.us] Sent: Wednesday, February 11, 2009 9:42 AM To: Mathias Wolkert Cc: nanog at nanog.org Subject: Re: Network diagram software On Wed, Feb 11, 2009 at 02:06:09PM +0100, Mathias Wolkert wrote: > I'd like to know what software people are using to document networks. > Visio is obvious but feels like a straight jacket to me. > I liked netviz but it seems owned by CA and unsupported nowadays. > > What do you use? I'd like to put a second request. I often want to very quickly mock-up a diagram that I'm going to use for myself or for internal purposes. Is there any application that takes some kind of *simple* description and produces a (possibly not so beautiful) picture? For example, I might say something like: Router(rtr1) connects to vlan 100 Router(rtr2) connects to Router(rtr1) via T1 switch(sw1) connects to vlan100 switch(sw2) connects to Router(rtr2) A few hosts connect to Switch(sw1) A few hosts connect to Switch(sw2) -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie From bruce at greatbasin.net Thu Feb 19 16:07:31 2009 From: bruce at greatbasin.net (Bruce Robertson) Date: Thu, 19 Feb 2009 14:07:31 -0800 Subject: do I need to maintain with RADB? In-Reply-To: References: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> Message-ID: <499DD823.1020702@greatbasin.net> Is the ARIN registry free, then? Jon Lewis wrote: > On Thu, 19 Feb 2009, Zaid Ali wrote: > >> Hi, need some advise here. Do I still need to maintain my objects >> (and pay) RADB? I use ARIN as source and all my route objects can be >> verified with a whois. > > If your objects are all maintained via another routing registry > (ARIN's, altdb, etc.) and you don't care to maintain objects with > radb.ra.net, then you do not need to pay RADB maintenance fees. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: bruce.vcf Type: text/x-vcard Size: 352 bytes Desc: not available URL: From zaid at zaidali.com Thu Feb 19 16:19:02 2009 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 19 Feb 2009 14:19:02 -0800 (PST) Subject: do I need to maintain with RADB? In-Reply-To: <15914959.1671235081933607.JavaMail.zaid@turing-2.local> Message-ID: <16209835.1691235081939090.JavaMail.zaid@turing-2.local> It's not entirely free since you have to pay an AS maintenance fee and if you are assigned a netblock directly then you pay maintenance on that also. I would rather maintain everything in one place rather than paying an extra $495 to RADB if my BGP peers can source it from ARIN. Zaid ----- Original Message ----- From: "Bruce Robertson" To: "NANOG list" Sent: Thursday, February 19, 2009 2:07:31 PM GMT -08:00 US/Canada Pacific Subject: Re: do I need to maintain with RADB? Is the ARIN registry free, then? Jon Lewis wrote: > On Thu, 19 Feb 2009, Zaid Ali wrote: > >> Hi, need some advise here. Do I still need to maintain my objects >> (and pay) RADB? I use ARIN as source and all my route objects can be >> verified with a whois. > > If your objects are all maintained via another routing registry > (ARIN's, altdb, etc.) and you don't care to maintain objects with > radb.ra.net, then you do not need to pay RADB maintenance fees. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > > > From bruce at greatbasin.net Thu Feb 19 16:19:42 2009 From: bruce at greatbasin.net (Bruce Robertson) Date: Thu, 19 Feb 2009 14:19:42 -0800 Subject: do I need to maintain with RADB? In-Reply-To: <16209835.1691235081939090.JavaMail.zaid@turing-2.local> References: <16209835.1691235081939090.JavaMail.zaid@turing-2.local> Message-ID: <499DDAFE.9030107@greatbasin.net> But I pay for all that already, so it seems that using ARIN is a no-brainer. Zaid Ali wrote: > It's not entirely free since you have to pay an AS maintenance fee and if you are assigned a netblock directly then you pay maintenance on that also. I would rather maintain everything in one place rather than paying an extra $495 to RADB if my BGP peers can source it from ARIN. > > Zaid > ----- Original Message ----- > From: "Bruce Robertson" > To: "NANOG list" > Sent: Thursday, February 19, 2009 2:07:31 PM GMT -08:00 US/Canada Pacific > Subject: Re: do I need to maintain with RADB? > > Is the ARIN registry free, then? > > Jon Lewis wrote: > >> On Thu, 19 Feb 2009, Zaid Ali wrote: >> >> >>> Hi, need some advise here. Do I still need to maintain my objects >>> (and pay) RADB? I use ARIN as source and all my route objects can be >>> verified with a whois. >>> >> If your objects are all maintained via another routing registry >> (ARIN's, altdb, etc.) and you don't care to maintain objects with >> radb.ra.net, then you do not need to pay RADB maintenance fees. >> >> ---------------------------------------------------------------------- >> Jon Lewis | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> >> >> >> >> >> > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: bruce.vcf Type: text/x-vcard Size: 366 bytes Desc: not available URL: From nospaceleft at gmail.com Thu Feb 19 16:23:10 2009 From: nospaceleft at gmail.com (Jean) Date: Thu, 19 Feb 2009 23:23:10 +0100 Subject: Single fiber 10Gb/s X2 or Xenpak transceiver In-Reply-To: <9be3e6fd0902190106s5ef4f061nd80921aee28b9480@mail.gmail.com> References: <9be3e6fd0902190106s5ef4f061nd80921aee28b9480@mail.gmail.com> Message-ID: <207b505d0902191423p9b8fbf3j7c37f5ca83bd8c98@mail.gmail.com> 2009/2/19, Andrey Slastenov : > Hi Guys. > > Do you ever see single fiber 10Gb/s X2 or Xenpak transceiver? (I know about > SFP, but never see X2 or Xenpak before) > -- Envoy? avec mon mobile Jean From tomas at caslavsky.cz Thu Feb 19 16:29:08 2009 From: tomas at caslavsky.cz (Tomas Caslavsky) Date: Thu, 19 Feb 2009 23:29:08 +0100 Subject: lots of prepends In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0203DF52@nexus.nexicomgroup.net> References: <499DD413.8000808@rollernet.us> <89D27DE3375BB6428DDCC2927489826A0203DF52@nexus.nexicomgroup.net> Message-ID: <499DDD34.6000101@caslavsky.cz> Hi all, I am writing on behalf of AS8928. We have changed our BGP policy against AS 20912 to allow maximum of 20 AS prepends. Our NOC will communicate this issue to customer and when I will have some news why this happened I will update NANOG list. Best Regards Tomas Caslavsky +---------------------------------------------------------------+ + Principal IP engineer + + Interoute CZECH + + Nad Elektrarnou 1428/47 + + 106 00 Praha 10 + + Prague + + Czech RepubliC + + Direct Phone: +420 225 352 675 + + Mobile Phone: +420 731 492 872 + + Email: Tomas.Caslavsky at interoute.com + +---------------------------------------------------------------+ "the impossible we can do - miracles take a little longer!" "/earth is 98% full... please delete anyone you can." Paul Stewart wrote: > The only ill effect is if set it too low.... we tested it a bit at 20-30 AS path length range figuring we shouldn't see *much* and it was staggering over time. The unfortunate thing more related to your question is that we found some AS's that were prepending 40-50 times to ALL their upstreams so with max-as set too low we had no routing to them at all! > > We've had it set to 100 for quite a while now and no side effects.... > > Paul > > > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Thursday, February 19, 2009 4:50 PM > To: nanog at nanog.org > Subject: Re: lots of prepends > > Mikael Abrahamsson wrote: > >> Today 85.119.176.0/21 was announced by AS20912 with 177 prepends. I >> noticed 20912 modulo 256 is 176. AS47868 modulo 256 is 252 which matches >> this mondays prepend-incident. >> >> So, what router OS will put 20912 into a byte and thus end up with 176 >> in something like "set as-path prepend last-as " ? It >> needs to be fixed. >> >> Has anyone noticed any ill effects with IOS and using "bgp max-as"? Will >> it just drop any prefixes with long as-paths and no other ill >> operational effects? >> >> > > No ill effects here, but I never saw the others before this one, and I'm > only seeing it via 3561. > > 010308: Feb 19 13:08:13.455 PDT: %BGP-6-ASPATH: Long AS path 3561 3257 > 8928 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 > 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 > 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 > 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 > 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 > 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 20912 > 20912 20912 20912 20912 20912 20912 received from 216.88.158.93: More > than configured MAXAS-LIMIT > > ~Seth > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > From zaid at zaidali.com Thu Feb 19 16:31:27 2009 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 19 Feb 2009 14:31:27 -0800 (PST) Subject: do I need to maintain with RADB? In-Reply-To: <499DDAFE.9030107@greatbasin.net> Message-ID: <12904690.1801235082684468.JavaMail.zaid@turing-2.local> Yes but I wanted to get a feel from the community and I get a notification message from RADB to pay up I wanted to get a feel from providers. I am happy to take my question off the list :) Zaid ----- Original Message ----- From: "Bruce Robertson" To: "Zaid Ali" Cc: "NANOG list" Sent: Thursday, February 19, 2009 2:19:42 PM GMT -08:00 US/Canada Pacific Subject: Re: do I need to maintain with RADB? But I pay for all that already, so it seems that using ARIN is a no-brainer. Zaid Ali wrote: It's not entirely free since you have to pay an AS maintenance fee and if you are assigned a netblock directly then you pay maintenance on that also. I would rather maintain everything in one place rather than paying an extra $495 to RADB if my BGP peers can source it from ARIN. Zaid ----- Original Message ----- From: "Bruce Robertson" To: "NANOG list" Sent: Thursday, February 19, 2009 2:07:31 PM GMT -08:00 US/Canada Pacific Subject: Re: do I need to maintain with RADB? Is the ARIN registry free, then? Jon Lewis wrote: On Thu, 19 Feb 2009, Zaid Ali wrote: Hi, need some advise here. Do I still need to maintain my objects (and pay) RADB? I use ARIN as source and all my route objects can be verified with a whois. If your objects are all maintained via another routing registry (ARIN's, altdb, etc.) and you don't care to maintain objects with radb.ra.net, then you do not need to pay RADB maintenance fees. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From randy at psg.com Thu Feb 19 16:57:57 2009 From: randy at psg.com (Randy Bush) Date: Fri, 20 Feb 2009 07:57:57 +0900 Subject: lots of prepends In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0203DF52@nexus.nexicomgroup.net> References: <499DD413.8000808@rollernet.us> <89D27DE3375BB6428DDCC2927489826A0203DF52@nexus.nexicomgroup.net> Message-ID: > The only ill effect is if set it too low.... we tested it a bit > at 20-30 AS path length range figuring we shouldn't see *much* > and it was staggering over time. The unfortunate thing more > related to your question is that we found some AS's that were > prepending 40-50 times to ALL their upstreams so with max-as set > too low we had no routing to them at all! aha! an idiot filter. this could be a feature, not a bug. randy From chort at smtps.net Thu Feb 19 17:10:38 2009 From: chort at smtps.net (Brian Keefer) Date: Thu, 19 Feb 2009 15:10:38 -0800 Subject: Appropriate list for Linux routers (was: real hardware router VS linux router) In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> Message-ID: <60BF7745-C622-4357-8BD0-5032FD4D48B8@smtps.net> On Feb 19, 2009, at 12:30 PM, Bill Nash wrote: > > Having carped, I'm obligated to offer a solution: > The technical discussion is certainly interesting to a small subset > of NANOG participants, I'm sure (I do find it interesting, I > promise), but I'm thinking this conversation is better elsewhere, > like a beer & gear, or might I recommend forming some kind of nanog- > shoptalk sub list? Is there one like it? Something for discussing > the network substrata and not the weather a few layers up? I'm aware > of stuff like c-nsp/j-nsp, but the Linux router crowd has it's own > niche and there's certainly a place for discussing them, I just > don't think it's.. here. > > - billn I would be interested in a such a thing. I've tried approaching the Linux crowd for such information, but they seem more interested in writing patches to blink LEDs when Netfilter does something than talking about performance and scaling considerations. If anyone would like to drop me a line off-list to point me in the right direction, I'd be very grateful. So far the most useful information I've found on the topic has been via this list. PS I'm talking specifically about Linux. The FreeBSD and OpenBSD crowd seem to have lists that provide this sort of thing already. -- bk From heather.schiller at verizonbusiness.com Thu Feb 19 17:21:13 2009 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Thu, 19 Feb 2009 18:21:13 -0500 Subject: do I need to maintain with RADB? In-Reply-To: References: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> Message-ID: <499DE969.902@verizonbusiness.com> No. Use of a routing registry is not required.. ARIN's, RADB's or otherwise. You might want to check out this presentation: http://nanog.org/meetings/nanog44/abstracts.php?pt=ODg4Jm5hbm9nNDQ=&nm=nanog44 This is an entirely different statement from "Your globally unique IP's should to be allocated to you in an RIR's database before someone routes them for you" For example 207.76.0.0/14 is allocated to us, you can see it in ARIN's whois, but it is not registered in ARIN's IRRD, or any other. As further proof - note that people publicly route resources that aren't registered in a "routing registry database" or even registered to them by an RIR at all: http://www.cidr-report.org/as2.0/#Bogons I'm not saying this is a good thing.. I would like to see the system drastically improved and secured.. I'm just pointing out how things actually work today. Check w/ your provider, but in most cases you will find that they don't use a route registry. --Heather ==================================================== Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management help4u at verizonbusiness.com ===================================================== Jon Lewis wrote: > On Thu, 19 Feb 2009, Zaid Ali wrote: > >> Hi, need some advise here. Do I still need to maintain my objects (and >> pay) RADB? I use ARIN as source and all my route objects can be >> verified with a whois. > > If your objects are all maintained via another routing registry (ARIN's, > altdb, etc.) and you don't care to maintain objects with radb.ra.net, > then you do not need to pay RADB maintenance fees. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > From adrian at creative.net.au Thu Feb 19 17:22:03 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 20 Feb 2009 08:22:03 +0900 Subject: Appropriate list for Linux routers (was: real hardware router VS linux router) In-Reply-To: <60BF7745-C622-4357-8BD0-5032FD4D48B8@smtps.net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <60BF7745-C622-4357-8BD0-5032FD4D48B8@smtps.net> Message-ID: <20090219232203.GD17366@skywalker.creative.net.au> On Thu, Feb 19, 2009, Brian Keefer wrote: > If anyone would like to drop me a line off-list to point me in the > right direction, I'd be very grateful. So far the most useful > information I've found on the topic has been via this list. > > PS I'm talking specifically about Linux. The FreeBSD and OpenBSD > crowd seem to have lists that provide this sort of thing already. The people doing this commercially under Linux/FreeBSD, and have mods to do higher PPS in certain conditions, generally don't talk (much.) A few FreeBSD developers are pushing forward with higher PPS improvements. If this is inline with what you want, then I suggest talking to them and seeing how they can help. Migrating to a superior platform (where "superior" here is "does what I want better" isn't a -bad- idea. :) Adrian From randy at psg.com Thu Feb 19 17:30:40 2009 From: randy at psg.com (Randy Bush) Date: Fri, 20 Feb 2009 08:30:40 +0900 Subject: do I need to maintain with RADB? In-Reply-To: <499DE969.902@verizonbusiness.com> References: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> <499DE969.902@verizonbusiness.com> Message-ID: > No. Use of a routing registry is not required. ^ always some wise upstreams require it. and it is a good idea to be in the irr. and there are free/open irr servers. randy From steve at ibctech.ca Thu Feb 19 08:43:53 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 19 Feb 2009 09:43:53 -0500 Subject: real hardware router VS linux router In-Reply-To: <499D6E99.1090706@uiuc.edu> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> Message-ID: <499D7029.8090200@ibctech.ca> Ryan Harden wrote: > While you could probably build a linux router that is just as fast as a > real hardware router, you're always going to run into the moving pieces > part of the equation. Not if you boot directly from USB key into memory with no disk drive. Steve From zaid at zaidali.com Thu Feb 19 17:48:37 2009 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 19 Feb 2009 15:48:37 -0800 (PST) Subject: do I need to maintain with RADB? In-Reply-To: <6397612.2071235087194029.JavaMail.zaid@turing-2.local> Message-ID: <10498976.2091235087314825.JavaMail.zaid@turing-2.local> Most of all my providers use a route registry and if they don't I would question it. I am all for a route registry but can we adopt one or one of X registries which I think is what is happening. For my ease of management I would like to use one and also pay (and budget) for one since its the same information (or should be). Zaid ----- Original Message ----- From: "Heather Schiller" To: "Zaid Ali" Cc: "Jon Lewis" , "NANOG list" Sent: Thursday, February 19, 2009 3:21:13 PM GMT -08:00 US/Canada Pacific Subject: Re: do I need to maintain with RADB? No. Use of a routing registry is not required.. ARIN's, RADB's or otherwise. You might want to check out this presentation: http://nanog.org/meetings/nanog44/abstracts.php?pt=ODg4Jm5hbm9nNDQ=&nm=nanog44 This is an entirely different statement from "Your globally unique IP's should to be allocated to you in an RIR's database before someone routes them for you" For example 207.76.0.0/14 is allocated to us, you can see it in ARIN's whois, but it is not registered in ARIN's IRRD, or any other. As further proof - note that people publicly route resources that aren't registered in a "routing registry database" or even registered to them by an RIR at all: http://www.cidr-report.org/as2.0/#Bogons I'm not saying this is a good thing.. I would like to see the system drastically improved and secured.. I'm just pointing out how things actually work today. Check w/ your provider, but in most cases you will find that they don't use a route registry. --Heather ==================================================== Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management help4u at verizonbusiness.com ===================================================== Jon Lewis wrote: > On Thu, 19 Feb 2009, Zaid Ali wrote: > >> Hi, need some advise here. Do I still need to maintain my objects (and >> pay) RADB? I use ARIN as source and all my route objects can be >> verified with a whois. > > If your objects are all maintained via another routing registry (ARIN's, > altdb, etc.) and you don't care to maintain objects with radb.ra.net, > then you do not need to pay RADB maintenance fees. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > From mike-nanog at tiedyenetworks.com Thu Feb 19 17:56:14 2009 From: mike-nanog at tiedyenetworks.com (mike) Date: Thu, 19 Feb 2009 15:56:14 -0800 Subject: real hardware router VS linux router In-Reply-To: <499D7029.8090200@ibctech.ca> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <499D7029.8090200@ibctech.ca> Message-ID: <499DF19E.5030409@tiedyenetworks.com> Steve Bertrand wrote: > Ryan Harden wrote: > >> While you could probably build a linux router that is just as fast as a >> real hardware router, you're always going to run into the moving pieces >> part of the equation. >> > > Not if you boot directly from USB key into memory with no disk drive. > > Steve > > I am sorry, but this is wrong. A USB Key is another 'PC Architecture' that DOES NOT WORK for network devices. There is NO positive mechanical force to keep that thing inserted, and the way a USB Key would hang off most devices with a USB port, would put it at very high risk for being accidentally bumped / disconnected. Secondly, there are still many many PC Architecture boxen that still do not boot correctly from USB. ' From jgreco at ns.sol.net Thu Feb 19 17:59:24 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 19 Feb 2009 17:59:24 -0600 (CST) Subject: real hardware router VS linux router In-Reply-To: <499D7029.8090200@ibctech.ca> from "Steve Bertrand" at Feb 19, 2009 09:43:53 AM Message-ID: <200902192359.n1JNxO61031319@aurora.sol.net> > Ryan Harden wrote: > > While you could probably build a linux router that is just as fast as a > > real hardware router, you're always going to run into the moving pieces > > part of the equation. > > Not if you boot directly from USB key into memory with no disk drive. You probably don't want a USB key. Too easy to knock off, etc. Though for a small enough USB key, like the Kingston microSD-to-USB adapters (like FCR-MRR+SDC) ... that'd probably be okay. What we did for a few applications... FreeBSD 7.1R on a 4GB compact flash, the CF plugged into a CF-to-IDE converter. In our case we case modded a few Intel ISP 1100 1U servers to allow the CF to be inserted from the front. Great for VPN service (either server or client), load balancers, traffic shapers, or smallish routers. ad0: 3847MB at ata0-master PIO4 Designed to run with root as read-only-usually, with memory filesystems for /var and /tmp (logging to a remote syslog server and serial console seem to address most of the obvious complaints). This only partially addresses the moving parts concerns, since the system is still dependent on fans. However, with a passive heatsink, at least the loss of a single fan isn't critical. And, geez, most of my switch gear has fans, so at what point do we draw the line? We had a 3Com SuperStack switch (~10 years old) that we didn't identify as the source of a nasty growly sound for probably half a decade. :-) There have been numerous discussions about PC routers on NANOG and other lists in the past. Short form is, if you know what you're doing and the tradeoffs and benefits are acceptable, it can really rock. Otherwise, proceed with caution and do lots of reading. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From brandon.galbraith at gmail.com Thu Feb 19 18:01:52 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 19 Feb 2009 18:01:52 -0600 Subject: real hardware router VS linux router In-Reply-To: <499DF19E.5030409@tiedyenetworks.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <499D7029.8090200@ibctech.ca> <499DF19E.5030409@tiedyenetworks.com> Message-ID: <366100670902191601j58ed69a5u2a50ff2d55f189da@mail.gmail.com> On 2/19/09, mike wrote: > > > > Steve Bertrand wrote: > >> Ryan Harden wrote: >> >> >>> While you could probably build a linux router that is just as fast as a >>> real hardware router, you're always going to run into the moving pieces >>> part of the equation. >>> >>> >> >> Not if you boot directly from USB key into memory with no disk drive. >> >> Steve >> >> >> > I am sorry, but this is wrong. A USB Key is another 'PC Architecture' that > DOES NOT WORK for network devices. There is NO positive mechanical force to > keep that thing inserted, and the way a USB Key would hang off most devices > with a USB port, would put it at very high risk for being accidentally > bumped / disconnected. Secondly, there are still many many PC Architecture > boxen that still do not boot correctly from USB. > I've used a hot glue gun to glue a USB key to the device/server/etc in question. Works very well against being bumped or accidentally dislodged. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From leo.vegoda at icann.org Thu Feb 19 18:01:59 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 19 Feb 2009 16:01:59 -0800 Subject: do I need to maintain with RADB? In-Reply-To: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> Message-ID: On 19/02/2009 12:09, "Zaid Ali" wrote: > Hi, need some advise here. Do I still need to maintain my objects (and pay) > RADB? I use ARIN as source and all my route objects can be verified with a > whois. If you are happy using a RR which appears to only rely on a MAIL-FROM auth scheme then the ARIN RR is fine. If you'd like to have a stronger auth scheme available you might want to look at RADB. Leo From frnkblk at iname.com Thu Feb 19 21:15:41 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 19 Feb 2009 21:15:41 -0600 Subject: IPv6 Confusion In-Reply-To: <499D61B7.1080000@brightok.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> <499D61B7.1080000@brightok.net> Message-ID: I probably tied CPE to NAT together in my mind....if I peel NAT out from what these CPE are doing, perhaps a PPPoE/A environment is the only place a L3 CPE will be needed with IPv6 anymore. FTTH, BWA, RFC 1483/RBE, and cable modems can bridge at L2 and each customer host can each have their own IPv6 address. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thursday, February 19, 2009 7:42 AM To: Frank Bulk Cc: 'Brandon Galbraith'; nanog at nanog.org Subject: Re: IPv6 Confusion Frank Bulk wrote: > Considering that the only real IPv6-ready CPE at your favorite N.A. electronics store is Apple's AirPort, it seems to me that it will be several years before the majority (50% plus 1) of our respective customer bases has IPv6-ready or dual-stack equipment. On the other hand, a majority of the routers purchased are for wireless connectivity, followed quickly by the necessity for multiple computers sharing a common subnet. Security and firewalls are not something most end users attribute to routers, but instead to their host based solutions. As such, I have no problem with pointing out that they can have 4.3 billion squared devices sitting off a cheap switch; all sharing the same subnet. Of course, wireless peeps will either have to use wireless bridges or have supported routers. Really, the AirPort is pretty stable and functional as a wireless AP. Most say it's worth the extra $$$. -Jack From rsnyder at toontown.erial.nj.us Thu Feb 19 21:35:32 2009 From: rsnyder at toontown.erial.nj.us (Bob Snyder) Date: Thu, 19 Feb 2009 22:35:32 -0500 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> Message-ID: <499E2504.2070002@toontown.erial.nj.us> Frank Bulk wrote: > Considering that the only real IPv6-ready CPE at your favorite N.A. electronics store is Apple's AirPort, it seems to me that it will be several years before the majority (50% plus 1) of our respective customer bases has IPv6-ready or dual-stack equipment. > Actually, out of the box my newish Linksys WRT610N started sending RAs and provides IPv6 connectivity via 6to4. Came as a bit of a surprise when it stole traffic away from my existing IPv6 tunnel. Couple of problems, though: 1) No switch to turn it off 2) No firewalling/filtering is done. This makes it somewhat less than ideal, and worse than the original Apple Airport default configuration which at least had clear and obvious knobs to make it do the right thing even if they had a poor default setting. Bob From swmike at swm.pp.se Thu Feb 19 23:44:08 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 20 Feb 2009 06:44:08 +0100 (CET) Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> <499D61B7.1080000@brightok.net> Message-ID: On Thu, 19 Feb 2009, Frank Bulk wrote: > I probably tied CPE to NAT together in my mind....if I peel NAT out from > what these CPE are doing, perhaps a PPPoE/A environment is the only > place a L3 CPE will be needed with IPv6 anymore. FTTH, BWA, RFC > 1483/RBE, and cable modems can bridge at L2 and each customer host can > each have their own IPv6 address. Do you really want to keep state for hundreds of end user devices in your equipment? In my mind, IPv6 more than ever requires the customer to have their own L3 device (which you delegate a /56 to with DHCPv6-PD). Imagine the size of your TCAM needed with antispoofing ACLs and adjacancies when the customer has 100 active IPv6 addresses (remember that IPv6 enabled devices often have multiple IPv6 addresses, my windows machine regularily grabs 3 for instance). -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Thu Feb 19 23:49:50 2009 From: randy at psg.com (Randy Bush) Date: Fri, 20 Feb 2009 14:49:50 +0900 Subject: IPv6 Confusion In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> <499D61B7.1080000@brightok.net> Message-ID: > Do you really want to keep state for hundreds of end user devices in > your equipment? > > In my mind, IPv6 more than ever requires the customer to have their > own L3 device (which you delegate a /56 to with DHCPv6-PD). > > Imagine the size of your TCAM needed with antispoofing ACLs and > adjacancies when the customer has 100 active IPv6 addresses (remember > that IPv6 enabled devices often have multiple IPv6 addresses, my > windows machine regularily grabs 3 for instance). we do not have to imagine. c & j have both demonstrated the nat scaling problem when protyping for comcast. that is why the idea of a 'carrier grade' nat in the core has become man near-edge nats and ds-lite. it is sorely broken architecture. randy From Stephen.Bailey at uk.fujitsu.com Fri Feb 20 02:51:51 2009 From: Stephen.Bailey at uk.fujitsu.com (Bailey Stephen) Date: Fri, 20 Feb 2009 08:51:51 -0000 Subject: real hardware router VS linux router In-Reply-To: <366100670902191601j58ed69a5u2a50ff2d55f189da@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com><499D6E99.1090706@uiuc.edu> <499D7029.8090200@ibctech.ca><499DF19E.5030409@tiedyenetworks.com> <366100670902191601j58ed69a5u2a50ff2d55f189da@mail.gmail.com> Message-ID: Not sure if this has already been mentioned, but what about solid state hard drives? Think they are in the high GB capacity now and solves the problem of no moving parts? Although I'm all for hardware based devices, we recently been to Cisco to see the new Cisco ASR1000 switch uses an underlying Linux kernel :o Stephen Bailey - Senior Lead Systems Engineer Network Operations - ISP & DSL FUJITSU Fujitsu Services Limited, Registered in England no 96056, Registered Office 22 Baker Street, London, W1U 3BW This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free. -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: 20 February 2009 00:02 To: mike Cc: nanog at nanog.org Subject: Re: real hardware router VS linux router On 2/19/09, mike wrote: > > > > Steve Bertrand wrote: > >> Ryan Harden wrote: >> >> >>> While you could probably build a linux router that is just as fast as a >>> real hardware router, you're always going to run into the moving pieces >>> part of the equation. >>> >>> >> >> Not if you boot directly from USB key into memory with no disk drive. >> >> Steve >> >> >> > I am sorry, but this is wrong. A USB Key is another 'PC Architecture' that > DOES NOT WORK for network devices. There is NO positive mechanical force to > keep that thing inserted, and the way a USB Key would hang off most devices > with a USB port, would put it at very high risk for being accidentally > bumped / disconnected. Secondly, there are still many many PC Architecture > boxen that still do not boot correctly from USB. > I've used a hot glue gun to glue a USB key to the device/server/etc in question. Works very well against being bumped or accidentally dislodged. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From nanog at daork.net Fri Feb 20 03:16:05 2009 From: nanog at daork.net (Nathan Ward) Date: Fri, 20 Feb 2009 22:16:05 +1300 Subject: real hardware router VS linux router In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com><499D6E99.1090706@uiuc.edu> <499D7029.8090200@ibctech.ca><499DF19E.5030409@tiedyenetworks.com> <366100670902191601j58ed69a5u2a50ff2d55f189da@mail.gmail.com> Message-ID: <1FF7FEDD-5824-4375-B5E7-C73C97EE94CF@daork.net> On 20/02/2009, at 9:51 PM, Bailey Stephen wrote: > Not sure if this has already been mentioned, but what about solid > state > hard drives? Think they are in the high GB capacity now and solves > the > problem of no moving parts? Regular CF works fine. CF's interface is ATA, so you can drop it in to a PATA hole with a very simple adapter. There are plenty of "network appliance" boxes that are designed for this sort of thing with lots of network holes mounted on the front and so on. Lots of them have CF card slots on the front as well, just like many router vendors do. -- Nathan Ward From bill at edisys.co.uk Fri Feb 20 03:51:04 2009 From: bill at edisys.co.uk (William Hamilton) Date: Fri, 20 Feb 2009 09:51:04 -0000 (GMT) Subject: real hardware router VS linux router In-Reply-To: <499DF19E.5030409@tiedyenetworks.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <499D7029.8090200@ibctech.ca> <499DF19E.5030409@tiedyenetworks.com> Message-ID: <31207.83.104.210.137.1235123464.squirrel@shiva.edisys.co.uk> > > > Steve Bertrand wrote: >> Ryan Harden wrote: >> >>> While you could probably build a linux router that is just as fast as a >>> real hardware router, you're always going to run into the moving pieces >>> part of the equation. >>> >> >> Not if you boot directly from USB key into memory with no disk drive. >> >> Steve >> >> > I am sorry, but this is wrong. A USB Key is another 'PC Architecture' > that DOES NOT WORK for network devices. There is NO positive mechanical > force to keep that thing inserted, and the way a USB Key would hang off > most devices with a USB port, would put it at very high risk for being > accidentally bumped / disconnected. It's already been suggested that a glue gun would be useful here, especially if you have a thumbnail sized USB drive. > Secondly, there are still many many PC Architecture boxen that > still do not boot correctly from USB. This is true, but when you are buying hardware specifically for it's ability to boot off USB then it's assumed that the purchaser would do their research, so something of a moot point. B From cidr-report at potaroo.net Fri Feb 20 05:00:06 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Feb 2009 22:00:06 +1100 (EST) Subject: BGP Update Report Message-ID: <200902201100.n1KB06EM037473@wattle.apnic.net> BGP Update Report Interval: 19-Jan-09 -to- 19-Feb-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 252388 5.4% 168.9 -- SIFY-AS-IN Sify Limited 2 - AS7643 167194 3.6% 278.2 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 3 - AS30890 52239 1.1% 117.4 -- EVOLVA Evolva Telecom 4 - AS6629 48437 1.0% 745.2 -- NOAA-AS - NOAA 5 - AS35805 35061 0.8% 93.0 -- UTG-AS United Telecom AS 6 - AS17974 33362 0.7% 66.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 7 - AS6458 30697 0.7% 66.0 -- Telgua 8 - AS27757 30429 0.7% 245.4 -- ANDINATEL S.A. 9 - AS30306 28205 0.6% 7051.2 -- AfOL-Sz-AS 10 - AS12500 26532 0.6% 6633.0 -- RCS-AS RCS Autonomus System 11 - AS5050 24213 0.5% 410.4 -- PSC-EXT - Pittsburgh Supercomputing Center 12 - AS30969 23596 0.5% 2949.5 -- TAN-NET TransAfrica Networks 13 - AS16559 22991 0.5% 2554.6 -- REALCONNECT-01 - RealConnect, Inc 14 - AS5056 21623 0.5% 186.4 -- INS-NET-2 - Iowa Network Services 15 - AS8452 21514 0.5% 14.6 -- TEDATA TEDATA 16 - AS14420 21438 0.5% 87.9 -- ANDINATEL S.A. 17 - AS20115 21021 0.5% 10.2 -- CHARTER-NET-HKY-NC - Charter Communications 18 - AS17488 20962 0.5% 13.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 19 - AS8151 20618 0.4% 13.8 -- Uninet S.A. de C.V. 20 - AS6389 20014 0.4% 4.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30287 9318 0.2% 9318.0 -- ALON-USA - ALON USA, LP 2 - AS30306 28205 0.6% 7051.2 -- AfOL-Sz-AS 3 - AS12500 26532 0.6% 6633.0 -- RCS-AS RCS Autonomus System 4 - AS41382 3018 0.1% 3018.0 -- TELEPORT-AS Teleport LLC Network AS 5 - AS30969 23596 0.5% 2949.5 -- TAN-NET TransAfrica Networks 6 - AS19017 2689 0.1% 2689.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 7 - AS16559 22991 0.5% 2554.6 -- REALCONNECT-01 - RealConnect, Inc 8 - AS28194 7260 0.2% 2420.0 -- 9 - AS10806 6265 0.1% 2088.3 -- AFP-NET - AGENCE FRANCE PRESSE 10 - AS5033 14564 0.3% 1618.2 -- ISW - Internet Specialties West Inc. 11 - AS23917 1613 0.0% 1613.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 12 - AS25970 7560 0.2% 1260.0 -- IAC - IAC Services LLC 13 - AS32398 11274 0.2% 1252.7 -- REALNET-ASN-1 14 - AS35335 1167 0.0% 1167.0 -- ESSTU-AS East-Siberian State Technological University AS 15 - AS29224 2154 0.1% 1077.0 -- HELLMANN Hellmann Worldwide Logistics GmbH & Co KG 16 - AS44265 11231 0.2% 1021.0 -- SMOLTELECOM-NET Smoltelecom Ltd AS peering 17 - AS29427 2025 0.0% 1012.5 -- AZM-AS Mercury Telecom 18 - AS41685 1004 0.0% 1004.0 -- DTEK DTEK 19 - AS30095 1964 0.0% 982.0 -- AS-30095 - Group M Worldwide, Inc. 20 - AS46328 8611 0.2% 956.8 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 23982 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 221.134.32.0/24 23761 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 190.152.103.0/24 17617 0.3% AS27757 -- ANDINATEL S.A. 4 - 192.35.129.0/24 16220 0.3% AS6629 -- NOAA-AS - NOAA 5 - 192.102.88.0/24 16080 0.3% AS6629 -- NOAA-AS - NOAA 6 - 198.77.177.0/24 15939 0.3% AS6629 -- NOAA-AS - NOAA 7 - 221.135.107.0/24 15250 0.3% AS9583 -- SIFY-AS-IN Sify Limited 8 - 210.214.177.0/24 15104 0.3% AS9583 -- SIFY-AS-IN Sify Limited 9 - 210.214.146.0/24 14974 0.3% AS9583 -- SIFY-AS-IN Sify Limited 10 - 210.214.222.0/24 14862 0.3% AS9583 -- SIFY-AS-IN Sify Limited 11 - 210.214.232.0/24 14844 0.3% AS9583 -- SIFY-AS-IN Sify Limited 12 - 210.214.132.0/24 14821 0.3% AS9583 -- SIFY-AS-IN Sify Limited 13 - 210.214.117.0/24 14773 0.3% AS9583 -- SIFY-AS-IN Sify Limited 14 - 64.162.116.0/24 14428 0.3% AS5033 -- ISW - Internet Specialties West Inc. 15 - 212.85.223.0/24 14010 0.3% AS30306 -- AfOL-Sz-AS 16 - 212.85.220.0/24 13975 0.3% AS30306 -- AfOL-Sz-AS 17 - 210.214.184.0/24 13450 0.3% AS9583 -- SIFY-AS-IN Sify Limited 18 - 210.18.10.0/24 13306 0.3% AS9583 -- SIFY-AS-IN Sify Limited 19 - 210.210.127.0/24 13025 0.3% AS9583 -- SIFY-AS-IN Sify Limited 20 - 66.63.32.0/19 12603 0.2% AS16559 -- REALCONNECT-01 - RealConnect, Inc Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 20 05:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Feb 2009 22:00:01 +1100 (EST) Subject: The Cidr Report Message-ID: <200902201100.n1KB01Ew037438@wattle.apnic.net> This report has been generated at Fri Feb 20 21:14:44 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 13-02-09 286337 178222 14-02-09 286606 178525 15-02-09 286864 178547 16-02-09 286675 178825 17-02-09 286961 178737 18-02-09 287148 178948 19-02-09 287534 179208 20-02-09 287886 179260 AS Summary 30724 Number of ASes in routing system 13062 Number of ASes announcing only one prefix 4368 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89816320 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 20Feb09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 287785 179251 108534 37.7% All ASes AS6389 4368 353 4015 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4224 1816 2408 57.0% TWTC - tw telecom holdings, inc. AS209 2833 1258 1575 55.6% ASN-QWEST - Qwest Communications Corporation AS4766 1815 524 1291 71.1% KIXS-AS-KR Korea Telecom AS17488 1521 368 1153 75.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1212 233 979 80.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1019 60 959 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8452 1225 307 918 74.9% TEDATA TEDATA AS8151 1477 609 868 58.8% Uninet S.A. de C.V. AS1785 1748 928 820 46.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 953 244 709 74.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1144 476 668 58.4% CABLEONE - CABLE ONE, INC. AS18566 1061 411 650 61.3% COVAD - Covad Communications Co. AS18101 752 165 587 78.1% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1141 558 583 51.1% LEVEL3 Level 3 Communications AS6478 1250 681 569 45.5% ATT-INTERNET3 - AT&T WorldNet Services AS7545 746 191 555 74.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS17908 604 112 492 81.5% TCISL Tata Communications AS22047 605 118 487 80.5% VTR BANDA ANCHA S.A. AS2706 550 80 470 85.5% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS855 619 161 458 74.0% CANET-ASN-4 - Bell Aliant AS4808 615 157 458 74.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 673 238 435 64.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1444 1011 433 30.0% ATT-INTERNET4 - AT&T WorldNet Services AS4134 927 499 428 46.2% CHINANET-BACKBONE No.31,Jin-rong Street AS4668 703 285 418 59.5% LGNET-AS-KR LG CNS AS9443 507 91 416 82.1% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 966 554 412 42.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17676 527 117 410 77.8% GIGAINFRA BB TECHNOLOGY Corp. AS10620 751 342 409 54.5% TV Cable S.A. Total 37980 12947 25033 65.9% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 155.254.0.0/16 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.36.28.0/22 AS40633 LAIX - LOS ANGELES INTERNET EXCHANGE 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.8.160.0/19 AS18109 EPOWER-TW E-Test Digital Technology Corp. 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.159.128.0/18 AS18109 EPOWER-TW E-Test Digital Technology Corp. 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/20 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.236.64.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 209.236.96.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet 220.247.128.0/19 AS18109 EPOWER-TW E-Test Digital Technology Corp. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From g.peritore at panservice.it Fri Feb 20 05:15:38 2009 From: g.peritore at panservice.it (Giuliano Peritore) Date: Fri, 20 Feb 2009 12:15:38 +0100 Subject: Lots of prepends - AS20912 case Message-ID: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> The long (176) AS20912 prepend incident was due to a misconfiguration of a BGP router we were testing. The problem is that differently to Cisco the syntax of the prepend field on thius system is not a string (eg. "20912 20912 20912") but an integer, that the user interface _should_ limit to the interval 0-16. Unfortunately something has gone wrong with the syntax checker so you can enter a number (the number entered, thinking to Cisco syntax, was 20912) and the sotware interpreted it as the request of 20912 prepends... (0x51B0), dropped the highest 8 bits and processed it as the request of 0xB0=176 prepends. The producer has been warned about the problem, which I can't completely define as a "bug"... but the lack of a user configuration helper (syntax checker). I think that the case of AS47868 is the same, because I seed the modulo was involved too. Many thanks to one of our upstream providers for their support. --------------------------------------------------- Giuliano Peritore - g.peritore at panservice.it Direzione Generale - Panservice Servizi professionali per Internet ed il Networking Panservice e' associata AIIP -- RIPE Local Registry Phone: +39 0773 410020 Fax +39 0773 470219 Numero verde: 800 901492 - http://www.panservice.it --------------------------------------------------- From tomas at caslavsky.cz Fri Feb 20 05:29:25 2009 From: tomas at caslavsky.cz (Tomas Caslavsky) Date: Fri, 20 Feb 2009 12:29:25 +0100 Subject: Lots of prepends - AS20912 case In-Reply-To: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> Message-ID: <499E9415.1000105@caslavsky.cz> Hi all, I can only cofnirm that AS47868 is using also Mikrotik as their border BGP router Tomas Giuliano Peritore wrote: > > The long (176) AS20912 prepend incident was due to a > misconfiguration of a BGP router we were testing. > > The problem is that differently to Cisco the syntax of the > prepend field on thius system is not a string (eg. "20912 20912 > 20912") but an integer, that the user interface _should_ limit to the > interval 0-16. > > Unfortunately something has gone wrong with the syntax checker > so you can enter a number (the number entered, thinking to Cisco > syntax, was 20912) and the sotware interpreted it as the request of > 20912 prepends... (0x51B0), dropped the highest 8 bits and processed > it as the request of 0xB0=176 prepends. > > The producer has been warned about the problem, which I can't > completely define as a "bug"... but the lack of a user configuration > helper (syntax checker). > > I think that the case of AS47868 is the same, because I seed > the modulo was involved too. > > Many thanks to one of our upstream providers for their support. > > > --------------------------------------------------- > Giuliano Peritore - g.peritore at panservice.it > Direzione Generale - Panservice > Servizi professionali per Internet ed il Networking > Panservice e' associata AIIP -- RIPE Local Registry > Phone: +39 0773 410020 Fax +39 0773 470219 > Numero verde: 800 901492 - http://www.panservice.it > --------------------------------------------------- > > From nanog-post at rsuc.gweep.net Fri Feb 20 05:58:06 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 20 Feb 2009 06:58:06 -0500 Subject: do I need to maintain with RADB? In-Reply-To: <5a318d410902191315q4d168078qa075dbb79411480f@mail.gmail.com> References: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> <5a318d410902191315q4d168078qa075dbb79411480f@mail.gmail.com> Message-ID: <20090220115806.GA19741@gweep.net> On Thu, Feb 19, 2009 at 01:15:40PM -0800, Darren Bolding wrote: > Is there a good source to explain the whole RADB "system", and > tools/processes people use to maintain routing policies/filters based on it? > I'd like to both review and make sure my current understanding is accurate, > and have a doc to send people to. It is the IRR system. You want to read up on http://www.irr.net/ and the various RPSL docs (RFC2622, RFC2650, and related). Choice of a registry to use will dictate your toolset; someone already noted auth method limitations, but some will support more elements of the language or extend with local needs. If you are large ehough that the time investment makes sense, you can just run your own routing registry and be free of those limitations. Local-use tools of interest would include ease-of-driving your updates with your selected registry [irrpt (http://sourceforge.net/projects/irrpt/)] and the recent updates to IRRToolset (http://irrtoolset.isc.org/ - see http://www.uknof.org.uk/uknof12/Kerr-IRRtoolset.pdf). Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From ed-nanog at s5h.net Fri Feb 20 06:58:11 2009 From: ed-nanog at s5h.net (ed) Date: Fri, 20 Feb 2009 12:58:11 +0000 Subject: Any twitter admins here? Message-ID: <20090220125811.GA2588@s5h.net> Hi All, Does anyone here work for Twitter, or have contact details of anyone who might. We're a large organisation who look after the network for another large organisation who are using Twitter in their broadcast promotions. Unfortunately our network has been blocked from accessing Twitter and their support cases require twitter for updates, so any contact details would be gratefully received. Thanks in advance -- The PRI to 3rd floor is A.F.U. because of the evil spock with a goatee. Han Solo is being "re-worked" by George Lucas. :: http://www.s5h.net/ :: http://www.s5h.net/gpg.html From jlewis at lewis.org Fri Feb 20 07:00:46 2009 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 20 Feb 2009 08:00:46 -0500 (EST) Subject: Lots of prepends - AS20912 case In-Reply-To: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> Message-ID: On Fri, 20 Feb 2009, Giuliano Peritore wrote: > The problem is that differently to Cisco the syntax of the prepend > field on thius system is not a string (eg. "20912 20912 20912") but an > integer, that the user interface _should_ limit to the interval 0-16. ... > The producer has been warned about the problem, which I can't > completely define as a "bug"... but the lack of a user configuration helper > (syntax checker). More important than whether or not to consider this a bug, it seems a very shortsighted way to support prepending. If your prepend "field" is an integer controlling how many times to prepend, how do you control which ASN(s) or even AS Paths are prepended? It sounds like you probably can't. As has been discussed recently, there are cases where you might want to prepend a creative AS Path for traffic engineering purposes to force certain routes/paths to be ignored by certain ASNs. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jeremy at evilrouters.net Fri Feb 20 07:07:24 2009 From: jeremy at evilrouters.net (Jeremy Gaddis) Date: Fri, 20 Feb 2009 08:07:24 -0500 Subject: Any twitter admins here? In-Reply-To: <20090220125811.GA2588@s5h.net> References: <20090220125811.GA2588@s5h.net> Message-ID: <8623d07f0902200507h26c11e7at7ae99418f1846773@mail.gmail.com> On Fri, Feb 20, 2009 at 7:58 AM, ed wrote: > Unfortunately our network has been blocked from accessing Twitter and > their support cases require twitter for updates, so any contact details > would be gratefully received. http://twitter.zendesk.com/requests/portal/new ? -- Jeremy L. Gaddis http://evilrouters.net/ From ed-nanog at s5h.net Fri Feb 20 07:11:35 2009 From: ed-nanog at s5h.net (ed) Date: Fri, 20 Feb 2009 13:11:35 +0000 Subject: Any twitter admins here? In-Reply-To: <8623d07f0902200507h26c11e7at7ae99418f1846773@mail.gmail.com> References: <20090220125811.GA2588@s5h.net> <8623d07f0902200507h26c11e7at7ae99418f1846773@mail.gmail.com> Message-ID: <20090220131135.GB2588@s5h.net> On Fri, Feb 20, 2009 at 08:07:24AM -0500, Jeremy Gaddis wrote: > On Fri, Feb 20, 2009 at 7:58 AM, ed wrote: > > Unfortunately our network has been blocked from accessing Twitter and > > their support cases require twitter for updates, so any contact details > > would be gratefully received. > > http://twitter.zendesk.com/requests/portal/new ? Thanks, That unfortunately redirects to twitter.com, where we're blocked. -- The T3 to www.tatooine.net is taking hits because of some bitchy farm boy on tatooine. The Sys Admin is wished well in their future endeavors. :: http://www.s5h.net/ :: http://www.s5h.net/gpg.html From dhetzel at gmail.com Fri Feb 20 07:51:26 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 20 Feb 2009 08:51:26 -0500 Subject: Lots of prepends - AS20912 case In-Reply-To: References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> Message-ID: <7db2dcf90902200551y7d359f45v60d2fd0230813981@mail.gmail.com> Replacing what is conventially thought to be a string with an integer multiplier seems a massive violation of the principle of least astonishment. On Fri, Feb 20, 2009 at 8:00 AM, Jon Lewis wrote: > On Fri, 20 Feb 2009, Giuliano Peritore wrote: > > The problem is that differently to Cisco the syntax of the prepend >> field on thius system is not a string (eg. "20912 20912 20912") but an >> integer, that the user interface _should_ limit to the interval 0-16. >> > ... > >> The producer has been warned about the problem, which I can't >> completely define as a "bug"... but the lack of a user configuration helper >> (syntax checker). >> > > More important than whether or not to consider this a bug, it seems a very > shortsighted way to support prepending. If your prepend "field" is an > integer controlling how many times to prepend, how do you control which > ASN(s) or even AS Paths are prepended? It sounds like you probably can't. > As has been discussed recently, there are cases where you might want to > prepend a creative AS Path for traffic engineering purposes to force certain > routes/paths to be ignored by certain ASNs. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgpfor PGP public key_________ > > From brandon at rd.bbc.co.uk Fri Feb 20 07:52:09 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 20 Feb 2009 13:52:09 GMT Subject: Any twitter admins here? Message-ID: <200902201352.NAA21410@sunf10.rd.bbc.co.uk> > > > Unfortunately our network has been blocked from accessing Twitter and > > > their support cases require twitter for updates, so any contact details > > > would be gratefully received. We're seeing something similar, started Wednesday afternoon ish It gets used a lot here including on air so we're getting a lot of IT support calls We've raised a support call with Twitter but they're saying "we've got a bit of a backlog, we might get back to you in about 5-7 working days" which may suggest they've done this to others brandon From swmike at swm.pp.se Fri Feb 20 08:05:48 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 20 Feb 2009 15:05:48 +0100 (CET) Subject: Lots of prepends - AS20912 case In-Reply-To: <7db2dcf90902200551y7d359f45v60d2fd0230813981@mail.gmail.com> References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> <7db2dcf90902200551y7d359f45v60d2fd0230813981@mail.gmail.com> Message-ID: On Fri, 20 Feb 2009, Dorn Hetzel wrote: > Replacing what is conventially thought to be a string with an integer > multiplier seems a massive violation of the principle of least astonishment. On a Cisco running 12.0S: route-map test1 set as-path prepend last-as ? <1-10> number of last-AS prepends Cisco seems to be doing more sensible limits, but I do agree that the feature makes sense. There are two ways of handling when someone puts in a very high number to number of prepends: 1. Say "out of limit" and disallow it in the config checker. 2. Actually prepend the number of times specified. The option done here: 3. Prepend number of times entered modulo 256, is just broken. -- Mikael Abrahamsson email: swmike at swm.pp.se From mathias at openvpn.se Fri Feb 20 07:58:36 2009 From: mathias at openvpn.se (Mathias Sundman) Date: Fri, 20 Feb 2009 14:58:36 +0100 (CET) Subject: Lots of prepends - AS20912 case In-Reply-To: References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> <7db2dcf90902200551y7d359f45v60d2fd0230813981@mail.gmail.com> Message-ID: On Fri, 20 Feb 2009, Mikael Abrahamsson wrote: > On Fri, 20 Feb 2009, Dorn Hetzel wrote: > >> Replacing what is conventially thought to be a string with an integer >> multiplier seems a massive violation of the principle of least >> astonishment. > > 3. Prepend number of times entered modulo 256, is just broken. In v3.20 of RouterOS (Mikrotik) it seems to fixed (havn't checked earlier releases), so they must have been running an old version of RouterOS if that was the platform they was using in this case, that I think someone was indicating. [admin at router1] /routing filter> set 1 set-bgp-prepend=20912 value of set-bgp-prepend out of range (0..16) [admin at router1] /routing filter> set 1 set-bgp-prepend=17 value of set-bgp-prepend out of range (0..16) I think having an option to prepend the AS-PATH with an integer multiplier is pretty convenient, just as they have checks like bgp-as-path-length=0 to check the lengh of AS-PATHs without writing regexps. But there should of course also be normal text prepends and regexp checks. With a check that no more than 16 are added, like the current version enforces misstakes like this shouldn't be possible. -- _____________________________________________________________ Mathias Sundman (^) ASCII Ribbon Campaign OpenVPN GUI for Windows X NO HTML/RTF in e-mail http://openvpn.se/ / \ NO Word docs in e-mail From jmaimon at ttec.com Fri Feb 20 08:35:35 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 20 Feb 2009 09:35:35 -0500 Subject: Comprehensive community Guideline and Policies for an AS Message-ID: <499EBFB7.5040001@ttec.com> I am looking to put together a comprehensive BGP communities guideline and policies for an AS starting from a blank slate. When I say comprehensive, I mean covers *everything* that is known to be best practice such as: Route Type Prepends Learned from Peers Learned from Peers Peers Learned from Transits Learned from Customers Learned from Customers Customers Advertise to Peers Advertise to Peers Peers Advertise to Transits Advertise to Customers Advertise to Customers Customers Local Preferences No exports No advertise Leaking to Peers/Transits/Customers Null-Route Region/POP And anything else I may have overlooked. Naturally, the resulting policy needs to be easily implementable on current IOS. My own experience and the publicly available information doesnt even come close to a consensus on the objectives that should be handled, let alone the number patterns preferred to be used. What I am looking for is a best practice guide on community policy setup. Barring that, I plan to continue examining every publicly published guideline to try to produce one, but likely as not it will suffer from the all to common human failing of shortsightedness. Thanks, Joe From jmaimon at ttec.com Fri Feb 20 08:41:37 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 20 Feb 2009 09:41:37 -0500 Subject: external L2 ethernet connections Message-ID: <499EC121.9090204@ttec.com> Does anyone have a best practice list of things to disable/filter/turn off on ethernet ports l2 connected to other AS's cdp stp switchport negotiate vtp if trunking, limit vlans, no vlan1 So on so forth. Switches do so many darn things all by themselves, as any packet capture shows. Thanks, Joe From dhetzel at gmail.com Fri Feb 20 08:46:24 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 20 Feb 2009 09:46:24 -0500 Subject: Lots of prepends - AS20912 case In-Reply-To: References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> <7db2dcf90902200551y7d359f45v60d2fd0230813981@mail.gmail.com> Message-ID: <7db2dcf90902200646v43b1f7a5ufa87413d8b4ad7ca@mail.gmail.com> It's just a personal opinion, but I would think that if someone is going to make the rest of the net suffer the ugliness of a nnnnn nnnnn nnnnn nnnnn nnnnn nnnnn nnnnn nnnnn nnnnn nnnnn nnnnn nnnnn prepend, then it's not unreasonable they should have to look at the ugliness in their config file as well :) The use of a multiplier just makes it too painless to inflict all that ugliness on everyone else without having to look at it first... On Fri, Feb 20, 2009 at 8:58 AM, Mathias Sundman wrote: > On Fri, 20 Feb 2009, Mikael Abrahamsson wrote: > > On Fri, 20 Feb 2009, Dorn Hetzel wrote: >> >> Replacing what is conventially thought to be a string with an integer >>> multiplier seems a massive violation of the principle of least >>> astonishment. >>> >> >> 3. Prepend number of times entered modulo 256, is just broken. >> > > In v3.20 of RouterOS (Mikrotik) it seems to fixed (havn't checked earlier > releases), so they must have been running an old version of RouterOS if that > was the platform they was using in this case, that I think someone was > indicating. > > [admin at router1] /routing filter> set 1 set-bgp-prepend=20912 > value of set-bgp-prepend out of range (0..16) > > [admin at router1] /routing filter> set 1 set-bgp-prepend=17 > value of set-bgp-prepend out of range (0..16) > > I think having an option to prepend the AS-PATH with an integer multiplier > is pretty convenient, just as they have checks like bgp-as-path-length=0 to > check the lengh of AS-PATHs without writing regexps. But there should of > course also be normal text prepends and regexp checks. With a check that no > more than 16 are added, like the current version enforces misstakes like > this shouldn't be possible. > > -- > _____________________________________________________________ > Mathias Sundman (^) ASCII Ribbon Campaign > OpenVPN GUI for Windows X NO HTML/RTF in e-mail > http://openvpn.se/ / \ NO Word docs in e-mail > > From pstewart at nexicomgroup.net Fri Feb 20 08:48:21 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 20 Feb 2009 09:48:21 -0500 Subject: external L2 ethernet connections In-Reply-To: <499EC121.9090204@ttec.com> References: <499EC121.9090204@ttec.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A02099F2D@nexus.nexicomgroup.net> http://www.ams-ix.net/technical/config_guide/ has some great info specific to IX connections.. Paul -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Friday, February 20, 2009 9:42 AM To: nanog at nanog.org Subject: external L2 ethernet connections Does anyone have a best practice list of things to disable/filter/turn off on ethernet ports l2 connected to other AS's cdp stp switchport negotiate vtp if trunking, limit vlans, no vlan1 So on so forth. Switches do so many darn things all by themselves, as any packet capture shows. Thanks, Joe ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From isabeldias1 at yahoo.com Fri Feb 20 08:55:38 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Fri, 20 Feb 2009 06:55:38 -0800 (PST) Subject: external L2 ethernet connections In-Reply-To: <499EC121.9090204@ttec.com> Message-ID: <909013.47715.qm@web52602.mail.re2.yahoo.com> Joe, I take credit card payments ....and we can agree on a daily rate ...as after all you are into "IT Consultancy". Just use the available search engine optimizers to build your knowledge based by performing the "black had v white hat" searches :-) I am here still ....what is your budget? --- On Fri, 2/20/09, Joe Maimon wrote: > From: Joe Maimon > Subject: external L2 ethernet connections > To: nanog at nanog.org > Date: Friday, February 20, 2009, 3:41 PM > Does anyone have a best practice list of things to > disable/filter/turn off on ethernet ports l2 connected to > other AS's > > cdp > stp > switchport negotiate > vtp > if trunking, limit vlans, no vlan1 > > So on so forth. > > Switches do so many darn things all by themselves, as any > packet capture shows. > > Thanks, > > Joe From adam at choopa.com Fri Feb 20 08:59:00 2009 From: adam at choopa.com (Adam Davenport) Date: Fri, 20 Feb 2009 09:59:00 -0500 Subject: external L2 ethernet connections In-Reply-To: <499EC121.9090204@ttec.com> References: <499EC121.9090204@ttec.com> Message-ID: <499EC534.1020704@choopa.com> If you're using a Cisco device on your side, you'll likely want to disable MOP as well: http://www.ciscotaccc.com/kaidara-advisor/lanswitching/showcase?case=K20523308 Adam Davenport / adam at choopa.com www.choopa.com / 1.866.2.CHOOPA Joe Maimon wrote: > Does anyone have a best practice list of things to disable/filter/turn > off on ethernet ports l2 connected to other AS's > > cdp > stp > switchport negotiate > vtp > if trunking, limit vlans, no vlan1 > > So on so forth. > > Switches do so many darn things all by themselves, as any packet > capture shows. > > Thanks, > > Joe > > From jmaimon at ttec.com Fri Feb 20 09:07:16 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 20 Feb 2009 10:07:16 -0500 Subject: external L2 ethernet connections In-Reply-To: <909013.47715.qm@web52602.mail.re2.yahoo.com> References: <909013.47715.qm@web52602.mail.re2.yahoo.com> Message-ID: <499EC724.1080401@ttec.com> I like your community spirit. Are you a member of the NANOG community because: a) You want to educate yourself b) You want to educate others c) You want to participate in flame wars d) You want to read flame wars e) You want to denigrate those seeking to educate themselves or others You cant have your cake and eat it too. Thanks but no thanks, I am going to avoid the pissing contest. Joe isabel dias wrote: > Joe, > > I take credit card payments ....and we can agree on a daily rate ...as after all you are into "IT Consultancy". > Just use the available search engine optimizers to build your knowledge based by performing the "black had v white hat" searches :-) > > > I am here still ....what is your budget? > > > > --- On Fri, 2/20/09, Joe Maimon wrote: > >> From: Joe Maimon >> Subject: external L2 ethernet connections >> To: nanog at nanog.org >> Date: Friday, February 20, 2009, 3:41 PM >> Does anyone have a best practice list of things to >> disable/filter/turn off on ethernet ports l2 connected to >> other AS's >> >> cdp >> stp >> switchport negotiate >> vtp >> if trunking, limit vlans, no vlan1 >> >> So on so forth. >> >> Switches do so many darn things all by themselves, as any >> packet capture shows. >> >> Thanks, >> >> Joe > > > > > From isabeldias1 at yahoo.com Fri Feb 20 09:17:39 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Fri, 20 Feb 2009 07:17:39 -0800 (PST) Subject: external L2 ethernet connections In-Reply-To: <499EC724.1080401@ttec.com> Message-ID: <696745.943.qm@web52609.mail.re2.yahoo.com> I ma not too sure if that is a comment that needs another expert answer .....but i can think of a few possible answers YES. "although I'm a little afraid, however I'd like to try it" ....."IT Consultancy"? --- On Fri, 2/20/09, Joe Maimon wrote: > From: Joe Maimon > Subject: Re: external L2 ethernet connections > To: isabeldias1 at yahoo.com > Cc: nanog at nanog.org > Date: Friday, February 20, 2009, 4:07 PM > I like your community spirit. > > Are you a member of the NANOG community because: > > a) You want to educate yourself > b) You want to educate others > c) You want to participate in flame wars > d) You want to read flame wars > e) You want to denigrate those seeking to educate > themselves or others > > You cant have your cake and eat it too. > > Thanks but no thanks, I am going to avoid the pissing > contest. > > Joe > > > > isabel dias wrote: > > Joe, > > I take credit card payments ....and we can agree on a > daily rate ...as after all you are into "IT > Consultancy". Just use the available search engine > optimizers to build your knowledge based by performing the > "black had v white hat" searches :-) > > > > > > I am here still ....what is your budget? > > > > > > --- On Fri, 2/20/09, Joe Maimon > wrote: > > > >> From: Joe Maimon > >> Subject: external L2 ethernet connections > >> To: nanog at nanog.org > >> Date: Friday, February 20, 2009, 3:41 PM > >> Does anyone have a best practice list of things to > >> disable/filter/turn off on ethernet ports l2 > connected to > >> other AS's > >> > >> cdp > >> stp > >> switchport negotiate > >> vtp > >> if trunking, limit vlans, no vlan1 > >> > >> So on so forth. > >> > >> Switches do so many darn things all by themselves, > as any > >> packet capture shows. > >> > >> Thanks, > >> > >> Joe > > > > > > > > From ivan.pepelnjak at zaplana.net Fri Feb 20 09:35:31 2009 From: ivan.pepelnjak at zaplana.net (Ivan Pepelnjak) Date: Fri, 20 Feb 2009 16:35:31 +0100 Subject: Lots of prepends - AS20912 case In-Reply-To: References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it><7db2dcf90902200551y7d359f45v60d2fd0230813981@mail.gmail.com> Message-ID: <010801c99370$de585180$0a00000a@nil.si> >From the end-user perspective, it makes sense to make the "prepend" parameter an integer. The only thing an end-user really needs is routing policy (primary/backup selection) and sometimes AS path prepending is the only solution. Allowing them to insert third-party AS numbers into the AS path increases their confusion (assuming they were never exposed to Cisco IOS). Obviously, the number of prepends has to be limited to something sensible (10 seems a good number, and it looks like Mikrotik has implemented that restriction). The "set as-path prepend last-as" is a completely different story; it's used to do proxy prepending for your customers. Ivan Pepelnjak http://blog.ioshints.info > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] > Sent: Friday, February 20, 2009 3:06 PM > To: nanog at nanog.org > Subject: Re: Lots of prepends - AS20912 case > > On Fri, 20 Feb 2009, Dorn Hetzel wrote: > > > Replacing what is conventially thought to be a string with > an integer > > multiplier seems a massive violation of the principle of > least astonishment. > > On a Cisco running 12.0S: > > route-map test1 > set as-path prepend last-as ? > <1-10> number of last-AS prepends > > Cisco seems to be doing more sensible limits, but I do agree > that the feature makes sense. > > There are two ways of handling when someone puts in a very > high number to number of prepends: > > 1. Say "out of limit" and disallow it in the config checker. > 2. Actually prepend the number of times specified. > > The option done here: > > 3. Prepend number of times entered modulo 256, is just broken. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From dhetzel at gmail.com Fri Feb 20 09:56:56 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 20 Feb 2009 10:56:56 -0500 Subject: Lots of prepends - AS20912 case In-Reply-To: <010801c99370$de585180$0a00000a@nil.si> References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> <7db2dcf90902200551y7d359f45v60d2fd0230813981@mail.gmail.com> <010801c99370$de585180$0a00000a@nil.si> Message-ID: <7db2dcf90902200756i35232ed9jdc4662455d78185b@mail.gmail.com> If we really want bgp for idiots, perhaps a checkbox for "make this (slightly,more,greatly) less preferred for incoming traffic" would do the job :) Then again, perhaps people who want the results of their local configuration distributed to the ends of the earth should at least read a book or two... -Dorn On Fri, Feb 20, 2009 at 10:35 AM, Ivan Pepelnjak wrote: > >From the end-user perspective, it makes sense to make the "prepend" > parameter an integer. The only thing an end-user really needs is routing > policy (primary/backup selection) and sometimes AS path prepending is the > only solution. Allowing them to insert third-party AS numbers into the AS > path increases their confusion (assuming they were never exposed to Cisco > IOS). Obviously, the number of prepends has to be limited to something > sensible (10 seems a good number, and it looks like Mikrotik has > implemented > that restriction). > > The "set as-path prepend last-as" is a completely different story; it's > used > to do proxy prepending for your customers. > > Ivan Pepelnjak > http://blog.ioshints.info > > > -----Original Message----- > > From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] > > Sent: Friday, February 20, 2009 3:06 PM > > To: nanog at nanog.org > > Subject: Re: Lots of prepends - AS20912 case > > > > On Fri, 20 Feb 2009, Dorn Hetzel wrote: > > > > > Replacing what is conventially thought to be a string with > > an integer > > > multiplier seems a massive violation of the principle of > > least astonishment. > > > > On a Cisco running 12.0S: > > > > route-map test1 > > set as-path prepend last-as ? > > <1-10> number of last-AS prepends > > > > Cisco seems to be doing more sensible limits, but I do agree > > that the feature makes sense. > > > > There are two ways of handling when someone puts in a very > > high number to number of prepends: > > > > 1. Say "out of limit" and disallow it in the config checker. > > 2. Actually prepend the number of times specified. > > > > The option done here: > > > > 3. Prepend number of times entered modulo 256, is just broken. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > > > From rodunn at cisco.com Fri Feb 20 10:39:54 2009 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 20 Feb 2009 11:39:54 -0500 Subject: anyone else seeing very long AS paths? In-Reply-To: <20090219201502.GU10344@rtp-cse-489.cisco.com> References: <20090217185434.GA9548@ajax.opentransit.net> <499B1384.8030201@rockynet.com> <005201c9913a$26a1d300$0a00000a@nil.si> <20090217201157.GP17200@rtp-cse-489.cisco.com> <20090217223149.GB11589@ajax.opentransit.net> <20090217222701.GL21284@rtp-cse-489.cisco.com> <20090219201502.GU10344@rtp-cse-489.cisco.com> Message-ID: <20090220163954.GO18753@rtp-cse-489.cisco.com> Typo in one part so sending to make it accurate. > The workaround is to implement bgp maxas-limit X on the > device that after prepending would need to send an update with over 255 AS > hops. Since IOS limits the inbound prepending value to 10 the most that > could be added iss 11 AS hops (10 on ingress, 10 on egress, and 1 for normal > eBGP AS hop addition). Therefore, a conservative value to configure would be > 200 to prevent this condition. It should be 21 hops (10 in a route-map on ingress, 10 in a route-map on egress, and 1 normal eBGP AS hop addition). Thanks to John Stuppi for pointing it out. Rodney On Thu, Feb 19, 2009 at 03:15:02PM -0500, Rodney Dunn wrote: > We are working on a document for Cisco.com but in the interim > here is the bug that will fix the issue of a Cisco IOS device > sending an incorrectly formatted BGP update when as a result > of prepending it goes over 255 AS hops. > > Note: The Title and Release-note on bug toolkit may be a > bit different as I just updated it to be more accurate. > > Of all the scenarios I've looked at (thanks to those that responded > offline) there wasn't a condition found where this could happen > without AS path prepending being used. > > Please respond offline or let's move the discussion over to > cisco-nsp at this point. > > CSCsx73770 > Invalid BGP formatted update causes peer reset with AS prepending > > Symptom: > > A Cisco IOS device that receives a BGP update message and as a result of AS > prepending needs to send an update downstream that would have over 255 AS hops > will send an invalid formatted update. This update when received by a > downstream BGP speaker triggers a NOTIFICATION back to the sender which results > in the BGP session being reset. > > Conditions: > > This problem is seen when a Cisco IOS device receives a BGP update and > due to a combination of either inbound, outbound, or both AS prepending it > needs to send an update downstream that has more than 255 AS hops. > > Workaround: > > The workaround is to implement bgp maxas-limit X on the > device that after prepending would need to send an update with over 255 AS > hops. Since IOS limits the inbound prepending value to 10 the most that > could be added iss 11 AS hops (10 on ingress, 10 on egress, and 1 for normal > eBGP AS hop addition). Therefore, a conservative value to configure would be > 200 to prevent this condition. > > > > Full support of Section 5.1.2 of RFC4271 is being tracked under > CSCsx75937 > Add BGP support of AS paths longer than 255 per Section 5.1.2 of RFC4271 > > Thanks to those that worked offline with us to verify the field results > reported. > > Rodney > > > > > On Tue, Feb 17, 2009 at 05:27:01PM -0500, Rodney Dunn wrote: > > If you want to take this offline send it unicast or we could > > move it to cisco-nsp. > > > > What scenarios are you seeing that appear broken other than > > when a notification is sent when a > 255 hop update is received? > > That's the one I'm working on right now. > > > > Rodney > > > > On Tue, Feb 17, 2009 at 05:31:49PM -0500, German Martinez wrote: > > > On Tue Feb 17, 2009, Rodney Dunn wrote: > > > > > > Hello Rodney, > > > It will be great if you can share with us your findings. It seems > > > like we are hitting different bugs in different platforms. > > > > > > Thanks > > > German > > > > > > > Ivan, > > > > > > > > It is confusing but from what I have tested you have it correct. > > > > > > > > The confusing part comes from multiple issues. > > > > > > > > a) The documentation about the default maxas limit being 75 appears to be > > > > incorrect. I'll get that fixed. > > > > > > > > b) Prior to CSCee30718 there was a hard limit of 255. After that fix > > > > AS sets of more than 255 should work. > > > > > > > > c) CSCeh13489 implemented the maxas command to mark it as invalid and > > > > not send. > > > > > > > > > > > > There does appear to be an issue when you cross the 255 boundary > > > > and the next hop router sends a notification back. > > > > > > > > I've got it recreated in the lab and we are working to clearly understand > > > > why that is. I'll post an update once we have more. > > > > > > > > The way to prevent it is the upstream device that crosses the 255 boundary > > > > on sending needs to use the maxas limit command to keep it less than 255. > > > > > > > > It doesn't work on the device that receives the update with the AS path > > > > larger than 255. > > > > > > > > Rodney > > > > > > > > On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > > > > > We were dropping ALL prefixes and the eBGP session was still > > > > > > resetting. > > > > > > > > > > Upstream or downstream? > > > > > > > > > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > > > > > on the IOS we were using. That is: it was previously verified > > > > > > to be working just fine to drop paths longer than 75, but > > > > > > once we started receiving paths > > > > > > > 255 then BGP started resetting. > > > > > > > > > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The > > > > > paths were generated by Quagga BGP daemon. > > > > > > > > > > 12.2SRC causes the downstream session to break when the installed AS-path > > > > > length is close to 255 and you use downstream AS-path prepending. > > > > > > > > > > In your case, I'm assuming you were hit with an older bug (probably at the > > > > > 128 AS-path length boundary). It would be very hard to generate just the > > > > > right AS-path length to unintentionally break your upstream EBGP session (as > > > > > I said before, it's a nice targeted attack if you know your downstream > > > > > topology). > > > > > > > > > > If your IOS is vulnerable to the older bugs that break inbound processing of > > > > > AS paths longer than 128, there's nothing you can do on your end. The > > > > > internal BGP checks reject the inbound update before the inbound filters (or > > > > > bgp maxas-limit) can touch it and reset the upstream BGP session. > > > > > > > > > > Hope this helps > > > > > Ivan > > > > > > > > > > Disclaimer: as I don't have internal access to Cisco, all of the above is a > > > > > result of lab tests. > > > > > > > From cgucker at onesc.net Fri Feb 20 11:00:24 2009 From: cgucker at onesc.net (Charles Gucker) Date: Fri, 20 Feb 2009 12:00:24 -0500 Subject: Comprehensive community Guideline and Policies for an AS In-Reply-To: <499EBFB7.5040001@ttec.com> References: <499EBFB7.5040001@ttec.com> Message-ID: > What I am looking for is a best practice guide on community policy setup. > > Barring that, I plan to continue examining every publicly published > guideline to try to produce one, but likely as not it will suffer from the > all to common human failing of shortsightedness. Feel free to look at our online collection of BGP Community guides. Some are more extensive than others and some intentionally leave off internal identifers. http://www.onesc.net/communities As a yearly request, if anybody knows of guides out there that we do not have listed, please let me know. thanks, charles From cscora at apnic.net Fri Feb 20 12:18:28 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Feb 2009 04:18:28 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200902201818.n1KIISQR021732@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Feb, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 280761 Prefixes after maximum aggregation: 133516 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 137721 Total ASes present in the Internet Routing Table: 30639 Prefixes per ASN: 9.16 Origin-only ASes present in the Internet Routing Table: 26668 Origin ASes announcing only one prefix: 12988 Transit ASes present in the Internet Routing Table: 3971 Transit-only ASes present in the Internet Routing Table: 90 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 529 Unregistered ASNs in the Routing Table: 177 Number of 32-bit ASNs allocated by the RIRs: 104 Prefixes from 32-bit ASNs in the Routing Table: 15 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 215 Number of addresses announced to Internet: 2007408064 Equivalent to 119 /8s, 166 /16s and 157 /24s Percentage of available address space announced: 54.2 Percentage of allocated address space announced: 63.3 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 75.8 Total number of prefixes smaller than registry allocations: 137856 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 64873 Total APNIC prefixes after maximum aggregation: 23232 APNIC Deaggregation factor: 2.79 Prefixes being announced from the APNIC address blocks: 61716 Unique aggregates announced from the APNIC address blocks: 28187 APNIC Region origin ASes present in the Internet Routing Table: 3534 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix: 956 APNIC Region transit ASes present in the Internet Routing Table: 545 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 402566816 Equivalent to 23 /8s, 254 /16s and 174 /24s Percentage of available APNIC address space announced: 80.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123836 Total ARIN prefixes after maximum aggregation: 65380 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 93252 Unique aggregates announced from the ARIN address blocks: 35691 ARIN Region origin ASes present in the Internet Routing Table: 12801 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4933 ARIN Region transit ASes present in the Internet Routing Table: 1228 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 416103232 Equivalent to 24 /8s, 205 /16s and 59 /24s Percentage of available ARIN address space announced: 80.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 63670 Total RIPE prefixes after maximum aggregation: 37387 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 58308 Unique aggregates announced from the RIPE address blocks: 38867 RIPE Region origin ASes present in the Internet Routing Table: 12697 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 6673 RIPE Region transit ASes present in the Internet Routing Table: 1925 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 389410528 Equivalent to 23 /8s, 53 /16s and 238 /24s Percentage of available RIPE address space announced: 82.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23309 Total LACNIC prefixes after maximum aggregation: 5718 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 21488 Unique aggregates announced from the LACNIC address blocks: 11883 LACNIC Region origin ASes present in the Internet Routing Table: 1069 LACNIC Prefixes per ASN: 20.10 LACNIC Region origin ASes announcing only one prefix: 341 LACNIC Region transit ASes present in the Internet Routing Table: 178 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 61081728 Equivalent to 3 /8s, 164 /16s and 8 /24s Percentage of available LACNIC address space announced: 60.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4576 Total AfriNIC prefixes after maximum aggregation: 1392 AfriNIC Deaggregation factor: 3.29 Prefixes being announced from the AfriNIC address blocks: 4305 Unique aggregates announced from the AfriNIC address blocks: 1401 AfriNIC Region origin ASes present in the Internet Routing Table: 284 AfriNIC Prefixes per ASN: 15.16 AfriNIC Region origin ASes announcing only one prefix: 85 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10027520 Equivalent to 0 /8s, 153 /16s and 2 /24s Percentage of available AfriNIC address space announced: 29.9 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1684 6928 395 Korea Telecom (KIX) 17488 1527 114 99 Hathway IP Over Cable Interne 4755 1211 429 178 TATA Communications formerly 9583 1092 86 518 Sify Limited 4134 927 16255 368 CHINANET-BACKBONE 18101 752 198 25 Reliance Infocom Ltd Internet 7545 726 158 98 TPG Internet Pty Ltd 9498 682 297 52 BHARTI BT INTERNET LTD. 24560 673 228 174 Bharti Airtel Ltd. 9829 638 491 19 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4368 3688 341 bellsouth.net, inc. 209 2833 4163 616 Qwest 4323 1775 1081 377 Time Warner Telecom 1785 1748 733 139 PaeTec Communications, Inc. 20115 1583 1421 718 Charter Communications 7018 1446 5879 1009 AT&T WorldNet Services 2386 1265 715 904 AT&T Data Communications Serv 6478 1250 299 506 AT&T Worldnet Services 11492 1202 192 12 Cable One 3356 1138 10976 440 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1225 188 7 TEDATA 30890 445 88 202 SC Kappa Invexim SRL 3292 443 1762 388 TDC Tele Danmark 12479 397 578 6 Uni2 Autonomous System 3320 341 7065 291 Deutsche Telekom AG 3301 338 1669 304 TeliaNet Sweden 8866 336 109 22 Bulgarian Telecommunication C 3215 331 2946 103 France Telecom Transpac 29049 328 26 3 AzerSat LLC. 8551 312 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1478 2831 230 UniNet S.A. de C.V. 10620 760 166 93 TVCABLE BOGOTA 11830 694 299 9 Instituto Costarricense de El 22047 605 302 14 VTR PUNTO NET S.A. 7303 511 255 80 Telecom Argentina Stet-France 6471 438 95 42 ENTEL CHILE S.A. 16814 427 27 11 NSS, S.A. 11172 405 118 75 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 370 506 23 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 665 74 38 LINKdotNET AS number 20858 290 34 3 This AS will be used to conne 3741 271 857 229 The Internet Solution 2018 242 215 142 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 128 15 8 Ci Telecom Autonomous system 5536 119 7 20 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 117 523 65 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4368 3688 341 bellsouth.net, inc. 209 2833 4163 616 Qwest 4323 1775 1081 377 Time Warner Telecom 1785 1748 733 139 PaeTec Communications, Inc. 4766 1684 6928 395 Korea Telecom (KIX) 20115 1583 1421 718 Charter Communications 17488 1527 114 99 Hathway IP Over Cable Interne 8151 1478 2831 230 UniNet S.A. de C.V. 7018 1446 5879 1009 AT&T WorldNet Services 2386 1265 715 904 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2833 2217 Qwest 1785 1748 1609 PaeTec Communications, Inc. 17488 1527 1428 Hathway IP Over Cable Interne 4323 1775 1398 Time Warner Telecom 4766 1684 1289 Korea Telecom (KIX) 8151 1478 1248 UniNet S.A. de C.V. 8452 1225 1218 TEDATA 11492 1202 1190 Cable One 18566 1061 1051 Covad Communications 4755 1211 1033 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:55 /12:162 /13:316 /14:577 /15:1125 /16:10341 /17:4586 /18:7895 /19:16958 /20:19936 /21:19594 /22:24758 /23:25089 /24:147061 /25:695 /26:856 /27:595 /28:97 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2846 4368 bellsouth.net, inc. 209 1571 2833 Qwest 4766 1392 1684 Korea Telecom (KIX) 17488 1305 1527 Hathway IP Over Cable Interne 8452 1204 1225 TEDATA 11492 1162 1202 Cable One 1785 1154 1748 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 954 1265 AT&T Data Communications Serv 9583 944 1092 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:180 12:2206 13:2 15:21 16:3 17:4 20:35 24:1114 32:51 38:545 40:96 41:1960 43:1 44:2 47:11 52:3 55:2 56:3 57:25 58:531 59:614 60:458 61:1099 62:1146 63:1994 64:3542 65:2424 66:3538 67:1474 68:656 69:2480 70:508 71:159 72:1608 73:2 74:1428 75:201 76:306 77:779 78:540 79:326 80:969 81:832 82:547 83:406 84:600 85:994 86:397 87:624 88:350 89:1403 90:42 91:1985 92:277 93:1086 94:1102 95:446 96:90 97:180 98:189 99:16 109:1 112:77 113:76 114:208 115:221 116:1132 117:493 118:284 119:640 120:134 121:704 122:961 123:523 124:858 125:1278 128:221 129:222 130:134 131:411 132:73 133:9 134:339 135:37 136:223 137:139 138:145 139:79 140:417 141:105 142:381 143:324 144:321 145:40 146:373 147:151 148:534 149:230 150:141 151:198 152:152 153:132 154:10 155:260 156:171 157:291 158:149 159:240 160:280 161:138 162:274 163:144 164:516 165:503 166:274 167:352 168:682 169:162 170:469 171:39 172:10 173:216 174:68 178:1 186:5 187:48 189:298 190:2589 192:5811 193:4210 194:3333 195:2698 196:1067 198:3702 199:3286 200:5526 201:1487 202:7797 203:8062 204:3934 205:2172 206:2346 207:2792 208:3835 209:3475 210:2637 211:1125 212:1489 213:1707 214:65 215:30 216:4551 217:1213 218:372 219:408 220:1219 221:462 222:315 End of report From andree+nanog at toonk.nl Fri Feb 20 12:42:04 2009 From: andree+nanog at toonk.nl (Andree Toonk) Date: Fri, 20 Feb 2009 19:42:04 +0100 Subject: Lots of prepends - AS20912 case In-Reply-To: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> References: <20090220111538.8DF7C40AD0D@mars.noc.panservice.it> Message-ID: <20090220184204.GA5996@toonk.nl> Hi, .-- My secret spy satellite informs me that at Fri, 20 Feb 2009, Giuliano Peritore wrote: > I think that the case of AS47868 is the same, because I seed the > modulo was involved too. For those interested, I made an overview of longest AS paths observed per day, starting with February 1st. I added a feature that checks if number of prepends matches the low-order 8 bits of the offending AS number. Indicating that it's likely caused by the same Mikrotik bug/feature. The list can be found here: http://bgpmon.net/maxASpath.php Interesting is that the first time this was observed was actually on February 9th (251 prepends by AS45307). Apparently the impact was not as widespread as this week. Cheers, Andree From leen at consolejunkie.net Fri Feb 20 13:29:02 2009 From: leen at consolejunkie.net (Leen Besselink) Date: Fri, 20 Feb 2009 20:29:02 +0100 Subject: real hardware router VS linux router In-Reply-To: <499DBC7B.3080108@emmanuelcomputerconsulting.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <499DBC7B.3080108@emmanuelcomputerconsulting.com> Message-ID: <499F047E.7080704@consolejunkie.net> William Warren wrote: > On 2/19/2009 9:37 AM, Ryan Harden wrote: > While you could probably build a linux router that is just as fast as a > real hardware router, you're always going to run into the moving pieces > part of the equation. > > In almost all scenarios, moving parts are more prone to failure than > non-moving parts. > > Regardless of what you find out in your research, consider the above in > your cost-benefit analysis. > > /Ryan > > Deric Kwok wrote: > >>>> Hi All >>>> >>>> Actually, what is the different hardware router VS linux router? >>>> >>>> Have you had experience to compare real router eg: cisco VS linux >>>> router? >>>> >>>> eg: streaming speed... tcp / udp >>>> >>>> Thank you for your information >>>> > >> >> > ssd's remove the spindle from the equation..otherwise they both have > fans that do fail. And I had a ticket from a few months ago with one of our transit-providers because they had a Juniper router reboot, it turned out this was because a harddisk failure of one of the routing engines. So 'real'-routers have those moving parts as well. ;-) From leen at consolejunkie.net Fri Feb 20 13:30:45 2009 From: leen at consolejunkie.net (Leen Besselink) Date: Fri, 20 Feb 2009 20:30:45 +0100 Subject: real hardware router VS linux router In-Reply-To: <04d601c992af$5f5cf730$1e16e590$@net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <04d601c992af$5f5cf730$1e16e590$@net> Message-ID: <499F04E5.7050706@consolejunkie.net> Ray Burkholder wrote: >> In scaling upward. How would a linux router even if a kernel guru were >> to tweak and compile an optimized build, compare to a 7600/RSP720CXL or >> a Juniper PIC in ASIC? At some point packets/sec becomes a limitation I >> would think. >> > > Is anyone building linux/bsd-box add-on cards with off the shelf packet > processors? Maybe something with the likes of > http://www.netlogicmicro.com/ or whatever? > > The first thing that comes to mind is this open source addon-card with FPGA-processor for routing packets in hardware: http://www.liberouter.org/liberouter.php From surfer at mauigateway.com Fri Feb 20 13:40:06 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 20 Feb 2009 11:40:06 -0800 Subject: sorta-OT graph snmp values Message-ID: <20090220114006.8C18B3C0@resin17.mta.everyone.net> First, please don't respond with "use mrtg, rrdtool, cricket, etc, etc." Silly 'layer 8' reasons are keeping me from being able to utilize these tools at this time. I have a need to graph SNMP values created by using a simple shell script on a Solaris box. I have output like this: 02-20-2009_08:00 39 19 20 18 23 19 18 18 ........ ........ 26 20 20 17 02-20-2009_09:00 23 20 22 18 I want to find a program that will allow me to graph the dates on the x-axis and the values on the y-axis, but I need it to be programmable such that I can run it from cron and send the graph to a directory as a jpeg, gif or png file. I tried using gnuplot, but I can't seem to make it work on outputting only to a file. Even using "set output graph.png". Can someone push me in the right direction? I'm not sure, but this should probably be discussed off-list... Thanks, scott From daler at ibbs.com Fri Feb 20 14:09:56 2009 From: daler at ibbs.com (Dale Rumph) Date: Fri, 20 Feb 2009 15:09:56 -0500 Subject: Trying to contact MSN/hotmail/microsoft admin Message-ID: <688C02E4787000408CC32EF37BA15D5D072266D477@ibknexch01.ibbsonline.local> All, Sorry to post this on-list but I am trying to reach anyone that works for or has a contact at the MSN/Hotmail NOC. We have been trying all week to reach someone. Currently a customer (Cable MSO) of ours has a few /24's being dropped at the entry point to that network. If someone could please contact me off-list I would be very grateful. Thanks - Dale Rumph Integrated Broadband Services LLC. daler at ibbs.com From cmadams at hiwaay.net Fri Feb 20 14:16:44 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 20 Feb 2009 14:16:44 -0600 Subject: real hardware router VS linux router In-Reply-To: <499F047E.7080704@consolejunkie.net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <499DBC7B.3080108@emmanuelcomputerconsulting.com> <499F047E.7080704@consolejunkie.net> Message-ID: <20090220201644.GE1284673@hiwaay.net> Once upon a time, Leen Besselink said: > And I had a ticket from a few months ago with one of our transit-providers > because they had a Juniper router reboot, it turned out this was because > a harddisk failure of one of the routing engines. > > So 'real'-routers have those moving parts as well. ;-) Yeah, I was going to say the same thing. Show me a "real" router without a fan; even the old Cisco 2501 had a fan in it. Most "real" routers can be heard outside the room! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ka at pacific.net Fri Feb 20 14:17:51 2009 From: ka at pacific.net (Ken A) Date: Fri, 20 Feb 2009 14:17:51 -0600 Subject: sorta-OT graph snmp values In-Reply-To: <20090220114006.8C18B3C0@resin17.mta.everyone.net> References: <20090220114006.8C18B3C0@resin17.mta.everyone.net> Message-ID: <499F0FEF.2080906@pacific.net> GD::Graph::lines does this easily, and there are plenty of examples to work from. (might be too much a pain if you don't have GD available) Ken Scott Weeks wrote: > > First, please don't respond with "use mrtg, rrdtool, cricket, etc, etc." Silly 'layer 8' reasons are keeping me from being able to utilize these tools at this time. > > I have a need to graph SNMP values created by using a simple shell script on a Solaris box. I have output like this: > > 02-20-2009_08:00 39 19 20 18 > 23 19 18 18 > ........ ........ > 26 20 20 17 > 02-20-2009_09:00 23 20 22 18 > > > I want to find a program that will allow me to graph the dates on the x-axis and the values on the y-axis, but I need it to be programmable such that I can run it from cron and send the graph to a directory as a jpeg, gif or png file. I tried using gnuplot, but I can't seem to make it work on outputting only to a file. Even using "set output graph.png". Can someone push me in the right direction? > > I'm not sure, but this should probably be discussed off-list... > > Thanks, > scott > > > > > From jon at rosenson.com Fri Feb 20 14:24:01 2009 From: jon at rosenson.com (Jonathan H. Rosenson) Date: Fri, 20 Feb 2009 15:24:01 -0500 Subject: Comcast Abuse Contact Message-ID: <6c964c5d0902201224va249d6dqb3594f42cc226349@mail.gmail.com> I need to speak with someone from Comcast abuse group off list. Please contact me as soon as possible. Sincerely, Jon == Jonathan H. Rosenson Expedient Communications jon at rosenson.com 412-316-7812 (office) 412-596-9322 (mobile) From jbates at brightok.net Fri Feb 20 14:40:54 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 20 Feb 2009 14:40:54 -0600 Subject: real hardware router VS linux router In-Reply-To: <499F047E.7080704@consolejunkie.net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <499DBC7B.3080108@emmanuelcomputerconsulting.com> <499F047E.7080704@consolejunkie.net> Message-ID: <499F1556.1000604@brightok.net> Leen Besselink wrote: > And I had a ticket from a few months ago with one of our transit-providers > because they had a Juniper router reboot, it turned out this was because > a harddisk failure of one of the routing engines. > Given the redundancy capabilities of Juniper M/T series, that actually scares me. NSF and ISSU are the biggies that I love about them. A harddisk failure should cause a quick kick to the backup RE. > So 'real'-routers have those moving parts as well. ;-) If your 'real' router doesn't sound like a jet engine purring, consider an upgrade. ;) Jack From adrian at creative.net.au Fri Feb 20 14:55:25 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 21 Feb 2009 05:55:25 +0900 Subject: IPv6 Confusion In-Reply-To: <499E2504.2070002@toontown.erial.nj.us> References: <6CDE22DE80A63A4DACF4FE2C916519A53F022F784D@BLV11EXVS01.corp.dm.local> <4838CFAB-F38B-4696-A7C2-1A6C002A7189@delong.com> <6CDE22DE80A63A4DACF4FE2C916519A53F022F788E@BLV11EXVS01.corp.dm.local> <050701c99135$df0f0ed0$9d2d2c70$@net> <366100670902171827o37ba393btffda3cdd3cc0d7e5@mail.gmail.com> <499E2504.2070002@toontown.erial.nj.us> Message-ID: <20090220205525.GF17366@skywalker.creative.net.au> On Thu, Feb 19, 2009, Bob Snyder wrote: > Frank Bulk wrote: > >Considering that the only real IPv6-ready CPE at your favorite N.A. > >electronics store is Apple's AirPort, it seems to me that it will be > >several years before the majority (50% plus 1) of our respective customer > >bases has IPv6-ready or dual-stack equipment. > > Actually, out of the box my newish Linksys WRT610N started sending RAs > and provides IPv6 connectivity via 6to4. Came as a bit of a surprise > when it stole traffic away from my existing IPv6 tunnel. Couple of > problems, though: > > 1) No switch to turn it off > 2) No firewalling/filtering is done. > > This makes it somewhat less than ideal, and worse than the original > Apple Airport default configuration which at least had clear and obvious > knobs to make it do the right thing even if they had a poor default setting. Would you be willing to update the ARIN ipv6 info wiki page for this? http://www.getipv6.info/index.php/Broadband_CPE Whoever looks after this - would you please consider setting up some kind of feature/bug matrix that tries to capture a bit of how "good" these things are? Just saying "Yup, supports IPv6" with no idea of how well, which bits work/don't, stuff like lacking firewalling (as above) would be good to know. Thanks! Adrian (Using a Cisco 827, speaks IPv6 real good..) From ip at ioshints.info Fri Feb 20 14:55:35 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Fri, 20 Feb 2009 21:55:35 +0100 Subject: Followup: anyone else seeing very long AS paths? In-Reply-To: <20090219201502.GU10344@rtp-cse-489.cisco.com> References: <20090217185434.GA9548@ajax.opentransit.net> <499B1384.8030201@rockynet.com> <005201c9913a$26a1d300$0a00000a@nil.si> <20090217201157.GP17200@rtp-cse-489.cisco.com> <20090217223149.GB11589@ajax.opentransit.net> <20090217222701.GL21284@rtp-cse-489.cisco.com> <20090219201502.GU10344@rtp-cse-489.cisco.com> Message-ID: <013d01c9939d$94b22060$0a00000a@nil.si> I know this is getting boring, but I don't want to see information lying around hinting that the ISPs around the world were to blame for the Monday incident due to their sloppy software upgrade policies. That's not the case; a lot of very recent IOS releases were affected. There was lots of conflicting information flowing around. Rodney did an excellent job with the bug description, but I was still wondering what exactly was going on, so I've tested all potential combinations of inbound/outbound IBGP/EBGP prepending/no-prepending cases to identify exactly what can happen; you should be able to figure out which one affected your network: http://blog.ioshints.info/2009/02/oversized-as-paths-cisco-ios-bug.html And it should be reiterated that anyone that has already configured bgp maxas-limit has avoided this problem. Ivan > -----Original Message----- > From: Rodney Dunn [mailto:rodunn at cisco.com] > Sent: Thursday, February 19, 2009 9:15 PM > To: Rodney Dunn > Cc: German Martinez; Ivan Pepelnjak; nanog at nanog.org > Subject: Re: anyone else seeing very long AS paths? > > We are working on a document for Cisco.com but in the interim > here is the bug that will fix the issue of a Cisco IOS device > sending an incorrectly formatted BGP update when as a result > of prepending it goes over 255 AS hops. > > Note: The Title and Release-note on bug toolkit may be a bit > different as I just updated it to be more accurate. > > Of all the scenarios I've looked at (thanks to those that responded > offline) there wasn't a condition found where this could > happen without AS path prepending being used. > > Please respond offline or let's move the discussion over to > cisco-nsp at this point. > > CSCsx73770 > Invalid BGP formatted update causes peer reset with AS prepending > > Symptom: > > A Cisco IOS device that receives a BGP update message and as > a result of AS prepending needs to send an update downstream > that would have over 255 AS hops will send an invalid > formatted update. This update when received by a downstream > BGP speaker triggers a NOTIFICATION back to the sender which > results in the BGP session being reset. > > Conditions: > > This problem is seen when a Cisco IOS device receives a BGP > update and due to a combination of either inbound, outbound, > or both AS prepending it needs to send an update downstream > that has more than 255 AS hops. > > Workaround: > > The workaround is to implement bgp maxas-limit X > on the device that after prepending would need to > send an update with over 255 AS hops. Since IOS limits the > inbound prepending value to 10 the most that could be added > iss 11 AS hops (10 on ingress, 10 on egress, and 1 for normal > eBGP AS hop addition). Therefore, a conservative value to > configure would be 200 to prevent this condition. > > > > Full support of Section 5.1.2 of RFC4271 is being tracked under > CSCsx75937 > Add BGP support of AS paths longer than 255 per Section 5.1.2 > of RFC4271 > > Thanks to those that worked offline with us to verify the > field results reported. > > Rodney > > > > > On Tue, Feb 17, 2009 at 05:27:01PM -0500, Rodney Dunn wrote: > > If you want to take this offline send it unicast or we > could move it > > to cisco-nsp. > > > > What scenarios are you seeing that appear broken other than when a > > notification is sent when a > 255 hop update is received? > > That's the one I'm working on right now. > > > > Rodney > > > > On Tue, Feb 17, 2009 at 05:31:49PM -0500, German Martinez wrote: > > > On Tue Feb 17, 2009, Rodney Dunn wrote: > > > > > > Hello Rodney, > > > It will be great if you can share with us your findings. > It seems > > > like we are hitting different bugs in different platforms. > > > > > > Thanks > > > German > > > > > > > Ivan, > > > > > > > > It is confusing but from what I have tested you have it correct. > > > > > > > > The confusing part comes from multiple issues. > > > > > > > > a) The documentation about the default maxas limit > being 75 appears to be > > > > incorrect. I'll get that fixed. > > > > > > > > b) Prior to CSCee30718 there was a hard limit of 255. > After that fix > > > > AS sets of more than 255 should work. > > > > > > > > c) CSCeh13489 implemented the maxas command to mark it > as invalid and > > > > not send. > > > > > > > > > > > > There does appear to be an issue when you cross the 255 > boundary > > > > and the next hop router sends a notification back. > > > > > > > > I've got it recreated in the lab and we are working to clearly > > > > understand why that is. I'll post an update once we have more. > > > > > > > > The way to prevent it is the upstream device that > crosses the 255 > > > > boundary on sending needs to use the maxas limit > command to keep it less than 255. > > > > > > > > It doesn't work on the device that receives the update > with the AS > > > > path larger than 255. > > > > > > > > Rodney > > > > > > > > On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > > > > > We were dropping ALL prefixes and the eBGP session > was still > > > > > > resetting. > > > > > > > > > > Upstream or downstream? > > > > > > > > > > > 1) "bgp maxas-limit 75" had no effect mitigating > this problem > > > > > > on the IOS we were using. That is: it was > previously verified > > > > > > to be working just fine to drop paths longer than > 75, but once > > > > > > we started receiving paths > > > > > > > 255 then BGP started resetting. > > > > > > > > > > I was able to receive BGP paths longer than 255 on > IOS release > > > > > 12.2SRC. The paths were generated by Quagga BGP daemon. > > > > > > > > > > 12.2SRC causes the downstream session to break when the > > > > > installed AS-path length is close to 255 and you use > downstream AS-path prepending. > > > > > > > > > > In your case, I'm assuming you were hit with an older bug > > > > > (probably at the > > > > > 128 AS-path length boundary). It would be very hard > to generate > > > > > just the right AS-path length to unintentionally break your > > > > > upstream EBGP session (as I said before, it's a nice targeted > > > > > attack if you know your downstream topology). > > > > > > > > > > If your IOS is vulnerable to the older bugs that > break inbound > > > > > processing of AS paths longer than 128, there's > nothing you can > > > > > do on your end. The internal BGP checks reject the inbound > > > > > update before the inbound filters (or bgp > maxas-limit) can touch it and reset the upstream BGP session. > > > > > > > > > > Hope this helps > > > > > Ivan > > > > > > > > > > Disclaimer: as I don't have internal access to Cisco, > all of the > > > > > above is a result of lab tests. > > > > > > > > From jmaimon at ttec.com Fri Feb 20 15:12:11 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 20 Feb 2009 16:12:11 -0500 Subject: Comprehensive community Guideline and Policies for an AS In-Reply-To: References: <499EBFB7.5040001@ttec.com> Message-ID: <499F1CAB.6040003@ttec.com> Charles Gucker wrote: >> What I am looking for is a best practice guide on community policy setup. >> >> Barring that, I plan to continue examining every publicly published >> guideline to try to produce one, but likely as not it will suffer from the >> all to common human failing of shortsightedness. > > Feel free to look at our online collection of BGP Community guides. > Some are more extensive than others and some intentionally leave off > internal identifers. > > http://www.onesc.net/communities > > As a yearly request, if anybody knows of guides out there that we do > not have listed, please let me know. > > thanks, > charles > > Its a great list and resource, and the real problem I am looking to address is trying to create a best of breed out of them all. I want to express my appreciation to you and to anyone else involved in maintaining this resource. Thanks, Joe From bepstein at ias.edu Fri Feb 20 15:26:56 2009 From: bepstein at ias.edu (Brian Epstein) Date: Fri, 20 Feb 2009 16:26:56 -0500 Subject: sorta-OT graph snmp values In-Reply-To: <20090220114006.8C18B3C0@resin17.mta.everyone.net> References: <20090220114006.8C18B3C0@resin17.mta.everyone.net> Message-ID: <499F2020.5090505@ias.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/20/2009 02:40 PM, Scott Weeks wrote: | a jpeg, gif or png file. I tried using gnuplot, but I can't seem to | make it work on outputting only to a file. Even using "set output | graph.png". Can someone push me in the right direction? Did you: set terminal png set output graph.png ... Thanks, ep - -- Brian Epstein +1 609-734-8179 Network and Security Officer Institute for Advanced Study Key fingerprint = 128A 38F4 4CFA 5EDB 99CE 4734 6117 4C25 0371 C12A -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFJnyAfYRdMJQNxwSoRAgblAJwN2B3v5zZWDYn6Jp5uB2JDcuj8JACfZZIF obBAWuNcmcEtTtvdVWWilU0= =lEJD -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3296 bytes Desc: S/MIME Cryptographic Signature URL: From surfer at mauigateway.com Fri Feb 20 15:39:49 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 20 Feb 2009 13:39:49 -0800 Subject: RESOLVED Re: sorta-OT graph snmp values Message-ID: <20090220133949.8C189126@resin17.mta.everyone.net> Thanks to everyone for the help! :-) Especially to Brian Sherwood who helped me finally figure it out. I didn't "set terminal png" because I didn't have a terminal connected to the Solaris box and wasn't using X. However, this needs to be set anyway. Also, "set output graph.png" needs to go *before* the plot statement. The data I mentioned earlier is in /export/home/router/erx-cpu-util/36w/util.txt Here is the very brief gnuplot program that now works: -bash-3.00$ cat graph-36w-cpu.plt #!/usr/local/bin/gnuplot set terminal gif set ylabel "Percent CPU Utilization" set xlabel "time" set output '/export/home/router/erx-cpu-util/gnuplot/36w-cpu-util.gif' plot '/export/home/router/erx-cpu-util/36w/util.txt' using 1:2 title "card1" smooth csplines, '/export/home/router/erx-cpu-util/36w/util.txt' using 1:3 title "card1" smooth csplines Thanks again, scott From simon at darkmere.gen.nz Fri Feb 20 16:41:12 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Sat, 21 Feb 2009 11:41:12 +1300 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From eric at nixwizard.net Fri Feb 20 19:32:34 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Fri, 20 Feb 2009 18:32:34 -0700 Subject: real hardware router VS linux router In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> Message-ID: <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> On Thu, Feb 19, 2009 at 1:30 PM, Bill Nash wrote: > Having carped, I'm obligated to offer a solution: > The technical discussion is certainly interesting to a small subset of NANOG > participants, I'm sure (I do find it interesting, I promise), but I'm > thinking this conversation is better elsewhere, like a beer & gear, or might > I recommend forming some kind of nanog-shoptalk sub list? Is there one like > it? Something for discussing the network substrata and not the weather a few > layers up? I wouldn't mind seeing a nanog-shoptalk list actually... I know according to the NANOG guidelines this thread is off topic: "The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum." (from the email everyone received) ...but I found this thread very interesting, and relevant to at least networking in general. I've had my eyes on Vyatta products in the past, for example, and seeing the smattering of experienced NANOG folks "chew the fat" about Linux routers is something I'm interested in, even if it has nothing specifically to do with really long BGP advertisements or getting to http://lolcats.com Just my .02 -- Eric http://nixwizard.net From jmartinez at zero11.com Fri Feb 20 22:26:00 2009 From: jmartinez at zero11.com (John Martinez) Date: Fri, 20 Feb 2009 20:26:00 -0800 Subject: comcast price check In-Reply-To: <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> Message-ID: <499F8258.1030402@zero11.com> Does any one here use comcast's ethernet services? If so, what is their price range? Thanks in advance. From sking at kingrst.com Fri Feb 20 22:45:48 2009 From: sking at kingrst.com (Steven King) Date: Fri, 20 Feb 2009 23:45:48 -0500 Subject: comcast price check In-Reply-To: <499F8258.1030402@zero11.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> Message-ID: <499F86FC.5020106@kingrst.com> Comcast has an Ethernet service? John Martinez wrote: > Does any one here use comcast's ethernet services? > If so, what is their price range? > > > Thanks in advance. > > > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From ryan at bbnx.net Fri Feb 20 23:46:44 2009 From: ryan at bbnx.net (Ryan A. Krenzischek) Date: Sat, 21 Feb 2009 00:46:44 -0500 (EST) Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: <499F86FC.5020106@kingrst.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> Message-ID: Yes, they do. You can find more information here: http://business.comcast.com/ethernet/dedicated-internet.aspx Although, I'm sufficiently disappointed with Comcast's Business Cable service. I have had them since 6-NOV-2008 and they took 4 months and 1 week to fix a cabling problem at the head-end for my business Internet. Apparently the head-end was wired wrong in regards to how power was supplied to it. I had nothing but dropped packets and latency (400-500 MS, sometimes 1200 MS) problems. I lost so much business. I tried multiple times to speak with a manager but they would only pick up their phone after I sat for 30 minutes with the phone, pressing the redial key and placed 60 calls to them. I had to call their corporate office and file a complaint. I am still having dropped packet issues. Comcast support also had the nerve to say it was my equipment and that I should immediately disconnect everything. Remind me again how is it my problem with *MY* equipment when the modem takes 25 minutes to sync/lock on the upstream channel? I would *highly* recommend a T1 or partial T3. While they are more expensive and highly reliable, AT&T or other major telcos will fix the problem within a reasonable SLA. Comcast does NOT have a SLA. It took 4 months to fix my problems on a business account. A Very Unhappy Comcast Customer, Ryan Krenzischek On Fri, 20 Feb 2009, Steven King wrote: > Date: Fri, 20 Feb 2009 23:45:48 -0500 > From: Steven King > To: John Martinez > Cc: NANOG list > Subject: Re: comcast price check > > Comcast has an Ethernet service? > > John Martinez wrote: >> Does any one here use comcast's ethernet services? >> If so, what is their price range? >> >> >> Thanks in advance. >> >> >> >> > > From jeffrey.lyon at blacklotus.net Sat Feb 21 00:02:12 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 21 Feb 2009 01:02:12 -0500 Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> Message-ID: <16720fe00902202202h375fcb76if0d685bf16447337@mail.gmail.com> Ryan, It's always your equipment. You should know that none of their customers have any clue how to run a network and therefore should remove them immediately. Any customer who is not running Windows and not connected directly to the router is to blame for any problems. Jeff On Sat, Feb 21, 2009 at 12:46 AM, Ryan A. Krenzischek wrote: > > Yes, they do. You can find more information here: > > http://business.comcast.com/ethernet/dedicated-internet.aspx > > Although, I'm sufficiently disappointed with Comcast's Business Cable > service. I have had them since 6-NOV-2008 and they took 4 months and 1 week > to fix a cabling problem at the head-end for my business Internet. > Apparently the head-end was wired wrong in regards to how power was supplied > to it. I had nothing but dropped packets and latency (400-500 MS, sometimes > 1200 MS) problems. I lost so much business. I tried multiple times to > speak with a manager but they would only pick up their phone after I sat for > 30 minutes with the phone, pressing the redial key and placed 60 calls to > them. I had to call their corporate office and file a complaint. I am > still having dropped packet issues. > > Comcast support also had the nerve to say it was my equipment and that I > should immediately disconnect everything. Remind me again how is it my > problem with *MY* equipment when the modem takes 25 minutes to sync/lock on > the upstream channel? > > I would *highly* recommend a T1 or partial T3. While they are more > expensive and highly reliable, AT&T or other major telcos will fix the > problem within a reasonable SLA. Comcast does NOT have a SLA. It took 4 > months to fix my problems on a business account. > > A Very Unhappy Comcast Customer, > > Ryan Krenzischek > > On Fri, 20 Feb 2009, Steven King wrote: > >> Date: Fri, 20 Feb 2009 23:45:48 -0500 >> From: Steven King >> To: John Martinez >> Cc: NANOG list >> Subject: Re: comcast price check >> >> Comcast has an Ethernet service? >> >> John Martinez wrote: >>> >>> Does any one here use comcast's ethernet services? >>> If so, what is their price range? >>> >>> >>> Thanks in advance. >>> >>> >>> >>> >> >> > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From pauldotwall at gmail.com Sat Feb 21 00:21:50 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Sat, 21 Feb 2009 01:21:50 -0500 Subject: external L2 ethernet connections In-Reply-To: <499EC534.1020704@choopa.com> References: <499EC121.9090204@ttec.com> <499EC534.1020704@choopa.com> Message-ID: <620fd17c0902202221r729bbf74td4946c8613caefa1@mail.gmail.com> On Fri, Feb 20, 2009 at 9:59 AM, Adam Davenport wrote: > If you're using a Cisco device on your side, you'll likely want to disable > MOP as well: > > http://www.ciscotaccc.com/kaidara-advisor/lanswitching/showcase?case=K20523308 > > Adam Davenport / adam at choopa.com > www.choopa.com / 1.866.2.CHOOPA A more sensible approach is to not run Enterprise code if you only need to route IP. Paul Wall From pauldotwall at gmail.com Sat Feb 21 00:23:58 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Sat, 21 Feb 2009 01:23:58 -0500 Subject: do I need to maintain with RADB? In-Reply-To: <499DE969.902@verizonbusiness.com> References: <9100725.1431235074175800.JavaMail.zaid@turing-2.local> <499DE969.902@verizonbusiness.com> Message-ID: <620fd17c0902202223t6acd9d41h6569f6105e40f979@mail.gmail.com> On Thu, Feb 19, 2009 at 6:21 PM, Heather Schiller wrote: > No. Use of a routing registry is not required.. ARIN's, RADB's or > otherwise. It's not required, however it's a good operational best-practice, and it helps with automating prefix-list generation/management. > Check w/ your provider, but in most cases you will find that they don't use > a route registry. Most is a very strong word. A number of large providers do, Level3/Savvis/GX to name a few. Verizon might not, but they're becoming increasingly less relevant in the transit marketplace with every passing day... :) Drive Slow, Paul Wall From ryan at bbnx.net Sat Feb 21 00:27:39 2009 From: ryan at bbnx.net (Ryan A. Krenzischek) Date: Sat, 21 Feb 2009 01:27:39 -0500 (EST) Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: <16720fe00902202202h375fcb76if0d685bf16447337@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <16720fe00902202202h375fcb76if0d685bf16447337@mail.gmail.com> Message-ID: Well that explains it all since we are a *BSD shop. Ryan On Sat, 21 Feb 2009, Jeffrey Lyon wrote: > Date: Sat, 21 Feb 2009 01:02:12 -0500 > From: Jeffrey Lyon > To: Ryan A. Krenzischek > Cc: NANOG list > Subject: Re: Craptastic Service! (was: Re: comcast price check) > > Ryan, > > It's always your equipment. You should know that none of their > customers have any clue how to run a network and therefore should > remove them immediately. Any customer who is not running Windows and > not connected directly to the router is to blame for any problems. > > Jeff > > On Sat, Feb 21, 2009 at 12:46 AM, Ryan A. Krenzischek wrote: >> >> Yes, they do. You can find more information here: >> >> http://business.comcast.com/ethernet/dedicated-internet.aspx >> >> Although, I'm sufficiently disappointed with Comcast's Business Cable >> service. I have had them since 6-NOV-2008 and they took 4 months and 1 week >> to fix a cabling problem at the head-end for my business Internet. >> Apparently the head-end was wired wrong in regards to how power was supplied >> to it. I had nothing but dropped packets and latency (400-500 MS, sometimes >> 1200 MS) problems. I lost so much business. I tried multiple times to >> speak with a manager but they would only pick up their phone after I sat for >> 30 minutes with the phone, pressing the redial key and placed 60 calls to >> them. I had to call their corporate office and file a complaint. I am >> still having dropped packet issues. >> >> Comcast support also had the nerve to say it was my equipment and that I >> should immediately disconnect everything. Remind me again how is it my >> problem with *MY* equipment when the modem takes 25 minutes to sync/lock on >> the upstream channel? >> >> I would *highly* recommend a T1 or partial T3. While they are more >> expensive and highly reliable, AT&T or other major telcos will fix the >> problem within a reasonable SLA. Comcast does NOT have a SLA. It took 4 >> months to fix my problems on a business account. >> >> A Very Unhappy Comcast Customer, >> >> Ryan Krenzischek >> >> On Fri, 20 Feb 2009, Steven King wrote: >> >>> Date: Fri, 20 Feb 2009 23:45:48 -0500 >>> From: Steven King >>> To: John Martinez >>> Cc: NANOG list >>> Subject: Re: comcast price check >>> >>> Comcast has an Ethernet service? >>> >>> John Martinez wrote: >>>> >>>> Does any one here use comcast's ethernet services? >>>> If so, what is their price range? >>>> >>>> >>>> Thanks in advance. >>>> >>>> >>>> >>>> >>> >>> >> >> > > > > From jeffrey.lyon at blacklotus.net Sat Feb 21 00:28:30 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 21 Feb 2009 01:28:30 -0500 Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <16720fe00902202202h375fcb76if0d685bf16447337@mail.gmail.com> Message-ID: <16720fe00902202228x2537a93fh749f1a59273e2a91@mail.gmail.com> Ryan, Last I talked to Comcast running BSD meant you're a hacker. Jeff On Sat, Feb 21, 2009 at 1:27 AM, Ryan A. Krenzischek wrote: > > Well that explains it all since we are a *BSD shop. > > Ryan > > On Sat, 21 Feb 2009, Jeffrey Lyon wrote: > >> Date: Sat, 21 Feb 2009 01:02:12 -0500 >> From: Jeffrey Lyon >> To: Ryan A. Krenzischek >> Cc: NANOG list >> Subject: Re: Craptastic Service! (was: Re: comcast price check) >> >> Ryan, >> >> It's always your equipment. You should know that none of their >> customers have any clue how to run a network and therefore should >> remove them immediately. Any customer who is not running Windows and >> not connected directly to the router is to blame for any problems. >> >> Jeff >> >> On Sat, Feb 21, 2009 at 12:46 AM, Ryan A. Krenzischek >> wrote: >>> >>> Yes, they do. You can find more information here: >>> >>> http://business.comcast.com/ethernet/dedicated-internet.aspx >>> >>> Although, I'm sufficiently disappointed with Comcast's Business Cable >>> service. I have had them since 6-NOV-2008 and they took 4 months and 1 >>> week >>> to fix a cabling problem at the head-end for my business Internet. >>> Apparently the head-end was wired wrong in regards to how power was >>> supplied >>> to it. I had nothing but dropped packets and latency (400-500 MS, >>> sometimes >>> 1200 MS) problems. I lost so much business. I tried multiple times to >>> speak with a manager but they would only pick up their phone after I sat >>> for >>> 30 minutes with the phone, pressing the redial key and placed 60 calls to >>> them. I had to call their corporate office and file a complaint. I am >>> still having dropped packet issues. >>> >>> Comcast support also had the nerve to say it was my equipment and that I >>> should immediately disconnect everything. Remind me again how is it my >>> problem with *MY* equipment when the modem takes 25 minutes to sync/lock >>> on >>> the upstream channel? >>> >>> I would *highly* recommend a T1 or partial T3. While they are more >>> expensive and highly reliable, AT&T or other major telcos will fix the >>> problem within a reasonable SLA. Comcast does NOT have a SLA. It took 4 >>> months to fix my problems on a business account. >>> >>> A Very Unhappy Comcast Customer, >>> >>> Ryan Krenzischek >>> >>> On Fri, 20 Feb 2009, Steven King wrote: >>> >>>> Date: Fri, 20 Feb 2009 23:45:48 -0500 >>>> From: Steven King >>>> To: John Martinez >>>> Cc: NANOG list >>>> Subject: Re: comcast price check >>>> >>>> Comcast has an Ethernet service? >>>> >>>> John Martinez wrote: >>>>> >>>>> Does any one here use comcast's ethernet services? >>>>> If so, what is their price range? >>>>> >>>>> >>>>> Thanks in advance. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> >> > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From andrew at prowant.us Sat Feb 21 00:36:37 2009 From: andrew at prowant.us (Andrew Prowant) Date: Sat, 21 Feb 2009 00:36:37 -0600 Subject: comcast price check In-Reply-To: <499F86FC.5020106@kingrst.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> Message-ID: <499FA0F5.6090607@prowant.us> Yes, Comcast started providing transit late last year. A couple hosting providers have connectivity to them here in Chicago. FDCServers.net has 30Gbps or 40Gbps to them. http://www.t1r.com/client/view.php?rid=55765 Steven King wrote: > Comcast has an Ethernet service? > > John Martinez wrote: > >> Does any one here use comcast's ethernet services? >> If so, what is their price range? >> >> >> Thanks in advance. >> >> >> >> >> > > From orion at pirk.com Sat Feb 21 01:18:17 2009 From: orion at pirk.com (Steve Pirk) Date: Fri, 20 Feb 2009 23:18:17 -0800 (PST) Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: <16720fe00902202228x2537a93fh749f1a59273e2a91@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <16720fe00902202202h375fcb76if0d685bf16447337@mail.gmail.com> <16720fe00902202228x2537a93fh749f1a59273e2a91@mail.gmail.com> Message-ID: Ouch! We have some unsatisfied customers... :-) I have had business class for 1.5 years now, and granted, there have been issues and I usually ask for tier 2 within a few minutes, but I am fairly satisfied. Speed just jumped to say 6-10Mbs down, 2+ up a couple of weeks ago and it works well for me. I pay ~$68.00 a month for 5 ips. dsl is not really an option here. Too far to the co. -- Steve On Sat, 21 Feb 2009, Jeffrey Lyon wrote: > Ryan, > > Last I talked to Comcast running BSD meant you're a hacker. > > Jeff > > On Sat, Feb 21, 2009 at 1:27 AM, Ryan A. Krenzischek wrote: >> >> Well that explains it all since we are a *BSD shop. >> >> Ryan >> >> On Sat, 21 Feb 2009, Jeffrey Lyon wrote: >> >>> Date: Sat, 21 Feb 2009 01:02:12 -0500 >>> From: Jeffrey Lyon >>> To: Ryan A. Krenzischek >>> Cc: NANOG list >>> Subject: Re: Craptastic Service! (was: Re: comcast price check) >>> >>> Ryan, >>> >>> It's always your equipment. You should know that none of their >>> customers have any clue how to run a network and therefore should >>> remove them immediately. Any customer who is not running Windows and >>> not connected directly to the router is to blame for any problems. >>> >>> Jeff >>> >>> On Sat, Feb 21, 2009 at 12:46 AM, Ryan A. Krenzischek >>> wrote: >>>> >>>> Yes, they do. You can find more information here: >>>> >>>> http://business.comcast.com/ethernet/dedicated-internet.aspx >>>> >>>> Although, I'm sufficiently disappointed with Comcast's Business Cable >>>> service. I have had them since 6-NOV-2008 and they took 4 months and 1 >>>> week >>>> to fix a cabling problem at the head-end for my business Internet. >>>> Apparently the head-end was wired wrong in regards to how power was >>>> supplied >>>> to it. I had nothing but dropped packets and latency (400-500 MS, >>>> sometimes >>>> 1200 MS) problems. I lost so much business. I tried multiple times to >>>> speak with a manager but they would only pick up their phone after I sat >>>> for >>>> 30 minutes with the phone, pressing the redial key and placed 60 calls to >>>> them. I had to call their corporate office and file a complaint. I am >>>> still having dropped packet issues. >>>> >>>> Comcast support also had the nerve to say it was my equipment and that I >>>> should immediately disconnect everything. Remind me again how is it my >>>> problem with *MY* equipment when the modem takes 25 minutes to sync/lock >>>> on >>>> the upstream channel? >>>> >>>> I would *highly* recommend a T1 or partial T3. While they are more >>>> expensive and highly reliable, AT&T or other major telcos will fix the >>>> problem within a reasonable SLA. Comcast does NOT have a SLA. It took 4 >>>> months to fix my problems on a business account. >>>> >>>> A Very Unhappy Comcast Customer, >>>> >>>> Ryan Krenzischek >>>> >>>> On Fri, 20 Feb 2009, Steven King wrote: >>>> >>>>> Date: Fri, 20 Feb 2009 23:45:48 -0500 >>>>> From: Steven King >>>>> To: John Martinez >>>>> Cc: NANOG list >>>>> Subject: Re: comcast price check >>>>> >>>>> Comcast has an Ethernet service? >>>>> >>>>> John Martinez wrote: >>>>>> >>>>>> Does any one here use comcast's ethernet services? >>>>>> If so, what is their price range? >>>>>> >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > From Kapeel.Sharma at McKesson.com Sat Feb 21 01:44:18 2009 From: Kapeel.Sharma at McKesson.com (Sharma, Kapeel) Date: Fri, 20 Feb 2009 23:44:18 -0800 Subject: Craptastic Service! (was: Re: comcast price check) Message-ID: This is BS how narrow minded our providers are. -------------------------- Sent using BlackBerry ----- Original Message ----- From: Jeffrey Lyon To: Ryan A. Krenzischek Cc: NANOG list Sent: Fri Feb 20 22:28:30 2009 Subject: Re: Craptastic Service! (was: Re: comcast price check) Ryan, Last I talked to Comcast running BSD meant you're a hacker. Jeff On Sat, Feb 21, 2009 at 1:27 AM, Ryan A. Krenzischek wrote: > > Well that explains it all since we are a *BSD shop. > > Ryan > > On Sat, 21 Feb 2009, Jeffrey Lyon wrote: > >> Date: Sat, 21 Feb 2009 01:02:12 -0500 >> From: Jeffrey Lyon >> To: Ryan A. Krenzischek >> Cc: NANOG list >> Subject: Re: Craptastic Service! (was: Re: comcast price check) >> >> Ryan, >> >> It's always your equipment. You should know that none of their >> customers have any clue how to run a network and therefore should >> remove them immediately. Any customer who is not running Windows and >> not connected directly to the router is to blame for any problems. >> >> Jeff >> >> On Sat, Feb 21, 2009 at 12:46 AM, Ryan A. Krenzischek >> wrote: >>> >>> Yes, they do. You can find more information here: >>> >>> http://business.comcast.com/ethernet/dedicated-internet.aspx >>> >>> Although, I'm sufficiently disappointed with Comcast's Business Cable >>> service. I have had them since 6-NOV-2008 and they took 4 months and 1 >>> week >>> to fix a cabling problem at the head-end for my business Internet. >>> Apparently the head-end was wired wrong in regards to how power was >>> supplied >>> to it. I had nothing but dropped packets and latency (400-500 MS, >>> sometimes >>> 1200 MS) problems. I lost so much business. I tried multiple times to >>> speak with a manager but they would only pick up their phone after I sat >>> for >>> 30 minutes with the phone, pressing the redial key and placed 60 calls to >>> them. I had to call their corporate office and file a complaint. I am >>> still having dropped packet issues. >>> >>> Comcast support also had the nerve to say it was my equipment and that I >>> should immediately disconnect everything. Remind me again how is it my >>> problem with *MY* equipment when the modem takes 25 minutes to sync/lock >>> on >>> the upstream channel? >>> >>> I would *highly* recommend a T1 or partial T3. While they are more >>> expensive and highly reliable, AT&T or other major telcos will fix the >>> problem within a reasonable SLA. Comcast does NOT have a SLA. It took 4 >>> months to fix my problems on a business account. >>> >>> A Very Unhappy Comcast Customer, >>> >>> Ryan Krenzischek >>> >>> On Fri, 20 Feb 2009, Steven King wrote: >>> >>>> Date: Fri, 20 Feb 2009 23:45:48 -0500 >>>> From: Steven King >>>> To: John Martinez >>>> Cc: NANOG list >>>> Subject: Re: comcast price check >>>> >>>> Comcast has an Ethernet service? >>>> >>>> John Martinez wrote: >>>>> >>>>> Does any one here use comcast's ethernet services? >>>>> If so, what is their price range? >>>>> >>>>> >>>>> Thanks in advance. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> >> > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From owen at delong.com Sat Feb 21 03:54:08 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 21 Feb 2009 01:54:08 -0800 Subject: comcast price check In-Reply-To: <499F8258.1030402@zero11.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> Message-ID: <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> Fair warning, Comcast is totally into the bait and switch game. Talk to any 3 people at Comcast and you will receive at least 4 different answers about what is or isn't included. Having a particular offer in writing makes no difference to them. I will be contacting the Santa Clara County District Attorney about my experiences with Comcast in violation of CA B&P code S17500 soon. I spent the last two months trying repeatedly to get Comcast to recognize and live up to their obligations under the offer they originally extended to me. They waffled for a very long time before I finally reached someone who flat-out told me that they were not ever going to deliver what was promised. Owen On Feb 20, 2009, at 8:26 PM, John Martinez wrote: > Does any one here use comcast's ethernet services? > If so, what is their price range? > > > Thanks in advance. > > From bruns at 2mbit.com Sat Feb 21 09:41:33 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 21 Feb 2009 08:41:33 -0700 Subject: comcast price check In-Reply-To: <499FA0F5.6090607@prowant.us> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <499FA0F5.6090607@prowant.us> Message-ID: <49A020AD.7070602@2mbit.com> On 2/20/09 11:36 PM, Andrew Prowant wrote: > Yes, Comcast started providing transit late last year. A couple hosting > providers have connectivity to them here in Chicago. FDCServers.net has > 30Gbps or 40Gbps to them. > *raises an eyebrow* FDCservers.net eh? That's always reassuring. Given my past experiences with them, I'm not sure I'd want to use them as a 'great example'. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bpfankuch at cpgreeley.com Sat Feb 21 10:15:18 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sat, 21 Feb 2009 09:15:18 -0700 Subject: comcast price check In-Reply-To: <49A020AD.7070602@2mbit.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <499FA0F5.6090607@prowant.us> <49A020AD.7070602@2mbit.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540E0F3E98@CPExchange1.cpgreeley.com> Back to the original topic on price. I am interested in this as well as we are looking for a failover network and had actually talked with Comcast. They were doing the work to see how far they had to trench. Does anyone out there actually use their Ethernet services? How stable are they? Good pricing? -----Original Message----- From: Brielle Bruns [mailto:bruns at 2mbit.com] Sent: Saturday, February 21, 2009 8:42 AM To: NANOG list Subject: Re: comcast price check On 2/20/09 11:36 PM, Andrew Prowant wrote: > Yes, Comcast started providing transit late last year. A couple hosting > providers have connectivity to them here in Chicago. FDCServers.net has > 30Gbps or 40Gbps to them. > *raises an eyebrow* FDCservers.net eh? That's always reassuring. Given my past experiences with them, I'm not sure I'd want to use them as a 'great example'. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jimpop at gmail.com Sat Feb 21 10:36:56 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 21 Feb 2009 11:36:56 -0500 Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: References: Message-ID: On Sat, Feb 21, 2009 at 02:44, Sharma, Kapeel wrote: > This is BS how narrow minded our providers are. It is also BS how high the expectations are for the $$ spent. ;-) -Jim P. From sking at kingrst.com Sat Feb 21 10:52:23 2009 From: sking at kingrst.com (Steven King) Date: Sat, 21 Feb 2009 11:52:23 -0500 Subject: comcast price check In-Reply-To: <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> Message-ID: <49A03147.5020308@kingrst.com> I can't even get reliable home cable internet service from them. No way I would ever consider using them for transit. I would only consider a stub peer with them to help out the poor Comcast customers who are also trying to get to my data centers. Owen DeLong wrote: > Fair warning, Comcast is totally into the bait and switch game. > Talk to any 3 people at Comcast and you will receive at least 4 > different answers about what is or isn't included. > > Having a particular offer in writing makes no difference to them. > > I will be contacting the Santa Clara County District Attorney about > my experiences with Comcast in violation of CA B&P code S17500 > soon. I spent the last two months trying repeatedly to get Comcast > to recognize and live up to their obligations under the offer they > originally extended to me. They waffled for a very long time before > I finally reached someone who flat-out told me that they were not > ever going to deliver what was promised. > > Owen > > On Feb 20, 2009, at 8:26 PM, John Martinez wrote: > >> Does any one here use comcast's ethernet services? >> If so, what is their price range? >> >> >> Thanks in advance. >> >> > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From sking at kingrst.com Sat Feb 21 11:00:02 2009 From: sking at kingrst.com (Steven King) Date: Sat, 21 Feb 2009 12:00:02 -0500 Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: References: Message-ID: <49A03312.8000601@kingrst.com> I don't think the expectations are that high for the money spent. They are promising a service for a particular price. They either deliver on that service in a 100% working condition or its false advertising and thus is not honest. It isn't the customers fault they decided to promise a service at a price blow market value. Jim Popovitch wrote: > On Sat, Feb 21, 2009 at 02:44, Sharma, Kapeel > wrote: > >> This is BS how narrow minded our providers are. >> > > It is also BS how high the expectations are for the $$ spent. ;-) > > -Jim P. > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From smb at cs.columbia.edu Sat Feb 21 11:02:21 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 21 Feb 2009 12:02:21 -0500 Subject: comcast price check In-Reply-To: <49A03147.5020308@kingrst.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> <49A03147.5020308@kingrst.com> Message-ID: <20090221120221.0a6b0ed9@cs.columbia.edu> On Sat, 21 Feb 2009 11:52:23 -0500 Steven King wrote: > I can't even get reliable home cable internet service from them. No > way I would ever consider using them for transit. I would only > consider a stub peer with them to help out the poor Comcast customers > who are also trying to get to my data centers. > I have decent (though of course by no means perfect) home business-grade cable Internet from them. I can download files from my office at 13M bps disk-to-disk, though of course uploads are slower. And their service people have been excellent since Verizon started offering FIOS in my town... (Yes, there have been glitches, most amusingly when I started seeing 5-20% packet loss and 5-90% packet duplication, and was told to clear my (Internet Explorer, which of course doesn't run on BSD) browser cache...) --Steve Bellovin, http://www.cs.columbia.edu/~smb From mike-nanog at tiedyenetworks.com Sat Feb 21 11:15:04 2009 From: mike-nanog at tiedyenetworks.com (mike) Date: Sat, 21 Feb 2009 09:15:04 -0800 Subject: Consumer broadband please move (was:Re: comcast price check) In-Reply-To: <20090221120221.0a6b0ed9@cs.columbia.edu> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> <49A03147.5020308@kingrst.com> <20090221120221.0a6b0ed9@cs.columbia.edu> Message-ID: <49A03698.106@tiedyenetworks.com> Steven M. Bellovin wrote: > On Sat, 21 Feb 2009 11:52:23 -0500 > Steven King wrote: > > >> I can't even get reliable home cable internet service from them. No >> way I would ever consider using them for transit. I would only >> consider a stub peer with them to help out the poor Comcast customers >> who are also trying to get to my data centers. >> >> Guys, I mean no offense, but this discussion probabbly belongs on a home user oriented forum like broadbandreports.com or similar. Thanks. From bpfankuch at cpgreeley.com Sat Feb 21 11:16:01 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sat, 21 Feb 2009 10:16:01 -0700 Subject: comcast price check In-Reply-To: <49A03147.5020308@kingrst.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> <49A03147.5020308@kingrst.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540E0F3E9F@CPExchange1.cpgreeley.com> Maybe it just depends on the area I have had Comcast Business Class at my residences through the past 7 years with no problems at all. Infact my current connection has almost a better uptime than our t1's at our office. Connected (165d 13h 29m 37s) with 16/2 minimum speed. I personally would use Comcast over Global Crossing based on personal experience :P Ive got a /29 awesome reliability and the name of my business rep who I can call when I need something. $99 a month doesn't seem bad for that. -----Original Message----- From: Steven King [mailto:sking at kingrst.com] Sent: Saturday, February 21, 2009 9:52 AM To: Owen DeLong Cc: NANOG list Subject: Re: comcast price check I can't even get reliable home cable internet service from them. No way I would ever consider using them for transit. I would only consider a stub peer with them to help out the poor Comcast customers who are also trying to get to my data centers. Owen DeLong wrote: > Fair warning, Comcast is totally into the bait and switch game. > Talk to any 3 people at Comcast and you will receive at least 4 > different answers about what is or isn't included. > > Having a particular offer in writing makes no difference to them. > > I will be contacting the Santa Clara County District Attorney about > my experiences with Comcast in violation of CA B&P code S17500 > soon. I spent the last two months trying repeatedly to get Comcast > to recognize and live up to their obligations under the offer they > originally extended to me. They waffled for a very long time before > I finally reached someone who flat-out told me that they were not > ever going to deliver what was promised. > > Owen > > On Feb 20, 2009, at 8:26 PM, John Martinez wrote: > >> Does any one here use comcast's ethernet services? >> If so, what is their price range? >> >> >> Thanks in advance. >> >> > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From bpfankuch at cpgreeley.com Sat Feb 21 11:22:07 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sat, 21 Feb 2009 10:22:07 -0700 Subject: Consumer broadband please move (was:Re: comcast price check) In-Reply-To: <49A03698.106@tiedyenetworks.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> <49A03147.5020308@kingrst.com> <20090221120221.0a6b0ed9@cs.columbia.edu> <49A03698.106@tiedyenetworks.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540E0F3EA0@CPExchange1.cpgreeley.com> The original inquiry was aimed at comcast's Ethernet service, which no one has actually responded to and the whole thread turned south from there. >> Does any one here use comcast's ethernet services? >> If so, what is their price range? >> >> >> Thanks in advance. -----Original Message----- From: mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Saturday, February 21, 2009 10:15 AM Cc: NANOG list Subject: Consumer broadband please move (was:Re: comcast price check) Steven M. Bellovin wrote: > On Sat, 21 Feb 2009 11:52:23 -0500 > Steven King wrote: > > >> I can't even get reliable home cable internet service from them. No >> way I would ever consider using them for transit. I would only >> consider a stub peer with them to help out the poor Comcast customers >> who are also trying to get to my data centers. >> >> Guys, I mean no offense, but this discussion probabbly belongs on a home user oriented forum like broadbandreports.com or similar. Thanks. From eddy+public+spam at noc.everquick.net Sat Feb 21 11:21:01 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Sat, 21 Feb 2009 17:21:01 +0000 (GMT) Subject: hardware choices (Re: real hardware router VS linux router) In-Reply-To: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Message-ID: DK> Date: Thu, 19 Feb 2009 09:30:16 -0500 DK> From: Deric Kwok [ snip ] Let's blur the line a bit more: CompactPCI? NICs such as those [apparently] offered by Cavium... or any other number of places working ARM/Freescale, MIPS, or PowerPC magic on NICs? What is "real" hardware, anyway? Would a 26xx, 38xx, et cetera qualify under said definition? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita LinkedIn: http://www.linkedin.com/in/0xebd ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From jimpop at gmail.com Sat Feb 21 11:49:56 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 21 Feb 2009 12:49:56 -0500 Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: <49A03312.8000601@kingrst.com> References: <49A03312.8000601@kingrst.com> Message-ID: On Sat, Feb 21, 2009 at 12:00, Steven King wrote: > I don't think the expectations are that high for the money spent. They > are promising a service for a particular price. They either deliver on > that service in a 100% working condition or its false advertising and > thus is not honest. It isn't the customers fault they decided to promise > a service at a price blow market value. What did the customer's contract state? I suspect the contract differs greatly from your text above. Never let marketing madness deliver non-legally binding expectations. ;-) -Jim P. From ryan at bbnx.net Sat Feb 21 12:50:08 2009 From: ryan at bbnx.net (Ryan A. Krenzischek) Date: Sat, 21 Feb 2009 13:50:08 -0500 (EST) Subject: Craptastic Service! (was: Re: comcast price check) In-Reply-To: References: Message-ID: While this is true, I had a 4 hour negotiated SLA with Bellsouth (AT&T) for any outages on my DSL business circuit and I was paying alot less. Ryan On Sat, 21 Feb 2009, Jim Popovitch wrote: > It is also BS how high the expectations are for the $$ spent. ;-) > > -Jim P. From ryan at bbnx.net Sat Feb 21 13:02:14 2009 From: ryan at bbnx.net (Ryan A. Krenzischek) Date: Sat, 21 Feb 2009 14:02:14 -0500 (EST) Subject: Consumer broadband please move (was:Re: comcast price check) In-Reply-To: <49A03698.106@tiedyenetworks.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> <49A03147.5020308@kingrst.com> <20090221120221.0a6b0ed9@cs.columbia.edu> <49A03698.106@tiedyenetworks.com> Message-ID: Mike, Comcast sells these business services but expects to be held to no SLA. It was a clear warning before going to use them, that you could run into potential problems with their "Enterprise-Grade" ethernet service. It took 4 months for their techs to figure out it was something wired wrong on their equipment. The bottom line is if you want your mission-critical services to work reliably 100% of the time, don't use Comcast. Ryan On Sat, 21 Feb 2009, mike wrote: > Guys, I mean no offense, but this discussion probabbly belongs on a home user > oriented forum like broadbandreports.com or similar. > > Thanks. > > From leen at consolejunkie.net Sat Feb 21 13:27:26 2009 From: leen at consolejunkie.net (Leen Besselink) Date: Sat, 21 Feb 2009 20:27:26 +0100 Subject: real hardware router VS linux router In-Reply-To: <499D754A.6030008@tiedyenetworks.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D754A.6030008@tiedyenetworks.com> Message-ID: <49A0559E.4050103@consolejunkie.net> mike wrote: > Well, > > Our operation uses linux everywhere and we have our own in house tiny > embedded flavor with all the tools and things that make it suited for > use in big and small boxes as many kinds of router and general packet > flipping appliance. I have confidence built on long term, real world > experience that says I can do this sucessfully, but the price I pay for > it is the knowledge curve and having had to invent the 'right' mix of > stuff, which includes compact flash based boot media, read-only > filesystem, and minimal management (command line via ssh, you need to be > an expert), and as well as having had to select the right hardware > (constraints include power on always, no dumb bios to stop the boot > process, and other issues). > > I would never ever reccomend that anyone just 'use linux' for network > appliances. It *can* do the job, but all the baggage of 'pc hardware' > typically conspires to make for less than rock solid. Stuff like hard > disks, which crash malfunction corrupt, and issues like - does the box > power on when power is applied or does someone have to press a button? > (You will note, most commercial hardware like routers and switches > either don't have a power button, or simply default to being 'on' unless > you take pains to flip buttons somewhere. But, PC's typically have a > power button you have to press to make it come on). And there's other > issues too - PC Bios's also conspire to get in the way and stop the boot > process. If they detect some sort of error, a key press, a missing disk, > or many other excuses, they stop cold waiting for someone to 'press f1 > to continue', or worse. Also most PC systems also have single power > supply units, and that which are less sturdy construction and are more > likely to burn out at some point than the more heavy duty commercial > grade units you see in commercial router/switch equipment). > > The difference then between linux and 'a hardware router' then is > that the manufacturer - cisco, juniper, whomever - has a large degree of > control over the integration between their software and the hardware it > runs on, and can dictate all of the things that makes the product work > like the boot process and it's internal storage and wether there are > sufficient fans and what kind of power supplie(s) are present and wether > there's a hardware watchdog (that works!) and the type of chips serving > as the ethernet controllers (which dictates all kinds of things that the > mnf considers 'features'). It's a long list. > > To summarize, you can do many jobs with linux. How WELL you do them, > however, is more of a function of how much exerience and knowledge that > you have. You can also do many jobs with commercial boxes, but how well > you do that job can be expressed more in terms of selecting the right > platform and plugging the right configuration lines into it, and both of > these can easilly be 'done well' in exchange for money (router vendor > support team, etc). > If you had to choose, it's probably smarted to go with OpenBSD, it has a lot better integration of packet filter, bgpd-daemon, ospf, vrrp-like, etc. Also depending on the structure and needs of your network, PC-routers may be cheaper and thus you can buy more of them for redundancy. Linux has other qualities, for smaller router and firewall setups I would prefer OpenBSD. But people can do whatever they want, hell even my (Sony Bravia) TV runs Linux. > Mike- > > Deric Kwok wrote: >> Hi All >> >> Actually, what is the different hardware router VS linux router? >> >> Have you had experience to compare real router eg: cisco VS linux router? >> >> eg: streaming speed... tcp / udp >> >> Thank you for your information >> > > From adrian at creative.net.au Sat Feb 21 13:42:15 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 22 Feb 2009 04:42:15 +0900 Subject: real hardware router VS linux router In-Reply-To: <49A0559E.4050103@consolejunkie.net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D754A.6030008@tiedyenetworks.com> <49A0559E.4050103@consolejunkie.net> Message-ID: <20090221194215.GH17366@skywalker.creative.net.au> On Sat, Feb 21, 2009, Leen Besselink wrote: > If you had to choose, it's probably smarted to go with OpenBSD, it has a > lot better integration of packet filter, bgpd-daemon, ospf, vrrp-like, etc. If you'd like a hope in hell of handling higher packet rates, where "higher packet rates" is "more than an NPE-200", then evaluate all of the open source operating systems before making that choice. Evaluate means "build test rig and test", not "read blog articles about how cool OpenBSD + PF is and how it worked for one person who bothered to write a glowing review." Too often do I come across people who have setup OpenBSD + PF, put it into production, then wonder why things perform craptastically after a couple hundred megabits. Convert to FreeBSD + PF, or Linux + iptables; this mostly goes away. (Same with Linux and freeBSD with big firewall rulesets, because they followed blog posts and didn't bother reading the documentation..) 2c, Adrian From chris at chrisserafin.com Sat Feb 21 13:46:22 2009 From: chris at chrisserafin.com (ChrisSerafin) Date: Sat, 21 Feb 2009 13:46:22 -0600 Subject: comcast price check In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540E0F3E98@CPExchange1.cpgreeley.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <499FA0F5.6090607@prowant.us> <49A020AD.7070602@2mbit.com> <01759D50DC387C45A018FE1817CE27D7540E0F3E98@CPExchange1.cpgreeley.com> Message-ID: <49A05A0E.4070501@chrisserafin.com> I have a client that has a number of business AT&T DSL and Comcast cable circuits for small remote VPN sites.....AT&T is great, rarely goes down.... Their Comcast circuits ALWAYS go down and are problems upstream per Comcast. I 'm not sure how much they cost thought, sorry. Chris Serafin Blake Pfankuch wrote: > Back to the original topic on price. I am interested in this as well as we are looking for a failover network and had actually talked with Comcast. They were doing the work to see how far they had to trench. > > Does anyone out there actually use their Ethernet services? How stable are they? Good pricing? > > > > -----Original Message----- > From: Brielle Bruns [mailto:bruns at 2mbit.com] > Sent: Saturday, February 21, 2009 8:42 AM > To: NANOG list > Subject: Re: comcast price check > > On 2/20/09 11:36 PM, Andrew Prowant wrote: > >> Yes, Comcast started providing transit late last year. A couple hosting >> providers have connectivity to them here in Chicago. FDCServers.net has >> 30Gbps or 40Gbps to them. >> >> > > > *raises an eyebrow* > > FDCservers.net eh? That's always reassuring. > > Given my past experiences with them, I'm not sure I'd want to use them > as a 'great example'. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.1/1962 - Release Date: 02/20/09 07:26:00 > > From bfeeny at mac.com Sat Feb 21 13:52:19 2009 From: bfeeny at mac.com (Brian Feeny) Date: Sat, 21 Feb 2009 14:52:19 -0500 Subject: T.38 IP carriers? Message-ID: <99C94D1D-73BD-4CBC-9CDB-1CD221D1E1A8@mac.com> Is anyone aware of a large (preferably tier 1 or tier 2) carrier that has a solid network that supports T.38 fax on-ramp and off-ramp services? I have a client that needs to originate and terminate several DS3's worth of T.38 fax traffic and is trying to find a carrier that supports this. I have a seen a list on the voip wiki, but its less than impressive and a referral from this list would mean so much more. Obviously said carrier would need to have a fairly robust IP backbone, ideally that only dumps to T.30/PSTN on the local terminating CO, or as close to it as possible. Brian From bpfankuch at cpgreeley.com Sat Feb 21 14:32:37 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sat, 21 Feb 2009 13:32:37 -0700 Subject: comcast price check In-Reply-To: <49A05A0E.4070501@chrisserafin.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <499FA0F5.6090607@prowant.us> <49A020AD.7070602@2mbit.com> <01759D50DC387C45A018FE1817CE27D7540E0F3E98@CPExchange1.cpgreeley.com> <49A05A0E.4070501@chrisserafin.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540E0F3EA2@CPExchange1.cpgreeley.com> Ok lets clarify. Comcast recently started offering Ethernet (read fiber delivery) circuits. Anyone know about stability and pricing on these. Please exclude all the commentary on any Comcast services that are "cable" based. -----Original Message----- From: ChrisSerafin [mailto:chris at chrisserafin.com] Sent: Saturday, February 21, 2009 12:46 PM To: Blake Pfankuch Cc: Brielle Bruns; NANOG list Subject: Re: comcast price check I have a client that has a number of business AT&T DSL and Comcast cable circuits for small remote VPN sites.....AT&T is great, rarely goes down.... Their Comcast circuits ALWAYS go down and are problems upstream per Comcast. I 'm not sure how much they cost thought, sorry. Chris Serafin Blake Pfankuch wrote: > Back to the original topic on price. I am interested in this as well as we are looking for a failover network and had actually talked with Comcast. They were doing the work to see how far they had to trench. > > Does anyone out there actually use their Ethernet services? How stable are they? Good pricing? > > > > -----Original Message----- > From: Brielle Bruns [mailto:bruns at 2mbit.com] > Sent: Saturday, February 21, 2009 8:42 AM > To: NANOG list > Subject: Re: comcast price check > > On 2/20/09 11:36 PM, Andrew Prowant wrote: > >> Yes, Comcast started providing transit late last year. A couple hosting >> providers have connectivity to them here in Chicago. FDCServers.net has >> 30Gbps or 40Gbps to them. >> >> > > > *raises an eyebrow* > > FDCservers.net eh? That's always reassuring. > > Given my past experiences with them, I'm not sure I'd want to use them > as a 'great example'. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.1/1962 - Release Date: 02/20/09 07:26:00 > > From eric at nixwizard.net Sat Feb 21 15:06:57 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Sat, 21 Feb 2009 14:06:57 -0700 Subject: comcast price check In-Reply-To: <49A03147.5020308@kingrst.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <85EA1A2E-1D09-4101-AC03-BE6AC7687271@delong.com> <49A03147.5020308@kingrst.com> Message-ID: <5792267e0902211306n2c59918eo34f4be98d70701bb@mail.gmail.com> On Sat, Feb 21, 2009 at 9:52 AM, Steven King wrote: > I can't even get reliable home cable internet service from them. No way > I would ever consider using them for transit. I would only consider a > stub peer with them to help out the poor Comcast customers who are also > trying to get to my data centers. Whaa? You're using your home internet service as your guide for business-class carrier service? Isn't that a bit like comparing home DSL versus a business T1 that has SLAs attached to it? You're comparing apples to oranges when you compare home vs. business service, IMO... -- Eric http://nixwizard.net From joshpotter at gmail.com Sat Feb 21 16:57:48 2009 From: joshpotter at gmail.com (Josh Potter) Date: Sat, 21 Feb 2009 16:57:48 -0600 Subject: hardware choices (Re: real hardware router VS linux router) In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> Message-ID: <4a64e2f70902211457v6b4c392aj71afcd4ad4b72038@mail.gmail.com> I think it's safe to define "real hardware" as hardware with ASIC's as opposed to software based solutions. On Sat, Feb 21, 2009 at 11:21 AM, Edward B. DREGER < eddy+public+spam at noc.everquick.net >wrote: > DK> Date: Thu, 19 Feb 2009 09:30:16 -0500 > DK> From: Deric Kwok > > [ snip ] > > Let's blur the line a bit more: > > CompactPCI? NICs such as those [apparently] offered by Cavium... or any > other number of places working ARM/Freescale, MIPS, or PowerPC magic on > NICs? > > What is "real" hardware, anyway? Would a 26xx, 38xx, et cetera qualify > under said definition? > > > Eddy > -- > Everquick Internet - http://www.everquick.net/ > A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 785 865 5885 Lawrence and [inter]national > Phone: +1 316 794 8922 Wichita > LinkedIn: http://www.linkedin.com/in/0xebd > ________________________________________________________________________ > DO NOT send mail to the following addresses: > davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net > Sending mail to spambait addresses is a great way to get blocked. > Ditto for broken OOO autoresponders and foolish AV software backscatter. > > -- Josh Potter From nrauhauser at gmail.com Sun Feb 22 00:28:37 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Sun, 22 Feb 2009 00:28:37 -0600 Subject: Great outage of 1997 - Does anyone recall? Message-ID: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> I recall a marvelous eighteen hour long global internet outage which I believe occurred in 1997, but this was before I'd ever touched BGP. Does anyone have the full story on this? I'm writing on article on the recent troubles with Supro and my silly editor wants fact checking and all sorts of stuff like that ... -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From rdobbins at cisco.com Sun Feb 22 00:39:19 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Sun, 22 Feb 2009 14:39:19 +0800 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> Message-ID: On Feb 22, 2009, at 2:28 PM, neal rauhauser wrote: > Does anyone have the full story on this? ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Some things are just too precious to entrust to computers. -- Seth Hanford From patrick at ianai.net Sun Feb 22 00:46:28 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 22 Feb 2009 01:46:28 -0500 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> Message-ID: <0F48A565-8998-4F15-93C1-7922529DF568@ianai.net> On Feb 22, 2009, at 1:39 AM, Roland Dobbins wrote: > On Feb 22, 2009, at 2:28 PM, neal rauhauser wrote: > >> Does anyone have the full story on this? > > Avi happened to be next to me when I read the first post in this thread - and re-read it out loud. I didn't even get to the end of the first sentence before he laughed and said "7007". (Avi & Vinny owned that together back then.) Operational content: Who still has 7007 filtered? -- TTFN, patrick From randy at psg.com Sun Feb 22 00:47:57 2009 From: randy at psg.com (Randy Bush) Date: Sun, 22 Feb 2009 14:47:57 +0800 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> Message-ID: >> Does anyone have the full story on this? > bottom line: o do not redistribute bgp into igp o do not redistribute dynamic igp into bgp o filter your peers and customers randy From richard at electrophobia.com Sun Feb 22 00:54:20 2009 From: richard at electrophobia.com (Richard Parker) Date: Sat, 21 Feb 2009 22:54:20 -0800 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> Message-ID: On Feb 21, 2009, at 10:28 PM, neal rauhauser wrote: > Does anyone have the full story on this? See: http://www.flix.net/ -Richard From patrick at ianai.net Sun Feb 22 00:55:31 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 22 Feb 2009 01:55:31 -0500 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> Message-ID: <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> On Feb 22, 2009, at 1:47 AM, Randy Bush wrote: >>> Does anyone have the full story on this? >> > > bottom line: > o do not redistribute bgp into igp > o do not redistribute dynamic igp into bgp > o filter your peers and customers And don't put all your most important infrastructure stuff (e.g. name server, mail server, shell host, etc.) in the first /24 of your / allocation. The biggest problem with 7007 was not that it announced a bunch of prefixes. It is that 7007 announced _classful_ prefix (it had been filtered through RIP, remember?) with AS_PATH of ^7007$. This means if you had a 194.1.0.0/16, you saw 194.1.0.0/24 from 7007, which is more specific. Why this is bad is left as an exercise to the reader. And, of course, the problem persisted after the router in question was actually unplugged - not powered up or attached to any fibers/cables. Thank you Sprint for running beta code. :) -- TTFN, patrick From nrauhauser at gmail.com Sun Feb 22 01:11:16 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Sun, 22 Feb 2009 01:11:16 -0600 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> Message-ID: <9515c62d0902212311w5e5b6029n58af6f9859a6ebb@mail.gmail.com> Well, I hope I'm not butchering the story up too badly - got an 800 word piece going up Monday on The Cutting Edge News and I'm doing something more lengthly and bloggy tonight for DailyKos, whilst hanging around abusing one of our spare 7507s with various new IOS versions. On Sun, Feb 22, 2009 at 12:55 AM, Patrick W. Gilmore wrote: > On Feb 22, 2009, at 1:47 AM, Randy Bush wrote: > > Does anyone have the full story on this? >>>> >>> >>> >> >> bottom line: >> o do not redistribute bgp into igp >> o do not redistribute dynamic igp into bgp >> o filter your peers and customers >> > > And don't put all your most important infrastructure stuff (e.g. name > server, mail server, shell host, etc.) in the first /24 of your / > allocation. > > The biggest problem with 7007 was not that it announced a bunch of > prefixes. It is that 7007 announced _classful_ prefix (it had been filtered > through RIP, remember?) with AS_PATH of ^7007$. This means if you had a > 194.1.0.0/16, you saw 194.1.0.0/24 from 7007, which is more specific. Why > this is bad is left as an exercise to the reader. > > And, of course, the problem persisted after the router in question was > actually unplugged - not powered up or attached to any fibers/cables. Thank > you Sprint for running beta code. :) > > -- > TTFN, > patrick > > > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From chaim.rieger at gmail.com Sun Feb 22 01:26:13 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Sun, 22 Feb 2009 07:26:13 +0000 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <9515c62d0902212324h68941227x17386973e6c0c9c5@mail.gmail.com> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> <9515c62d0902212311w5e5b6029n58af6f9859a6ebb@mail.gmail.com> <2116492819-1235287310-cardhu_decombobulator_blackberry.rim.net-1064508903-@bxe1146.bisx.prod.on.blackberry><9515c62d0902212324h68941227x17386973e6c0c9c5@mail.gmail.com> Message-ID: <137324094-1235287595-cardhu_decombobulator_blackberry.rim.net-1178612991-@bxe1146.bisx.prod.on.blackberry> Back on list I doubt you will get skewered, I promise to read it Sent via BlackBerry from T-Mobile -----Original Message----- From: neal rauhauser Date: Sun, 22 Feb 2009 01:24:08 To: Subject: Re: Great outage of 1997 - Does anyone recall? Oh, you guys will skewer me for it :-) Shall I post the text here so it gets vetted first? On Sun, Feb 22, 2009 at 1:21 AM, wrote: > Do post a link when its up. > > > Sent via BlackBerry from T-Mobile > > -----Original Message----- > From: neal rauhauser > > Date: Sun, 22 Feb 2009 01:11:16 > To: Patrick W. Gilmore > Cc: NANOG list > Subject: Re: Great outage of 1997 - Does anyone recall? > > > Well, I hope I'm not butchering the story up too badly - got an 800 word > piece going up Monday on The Cutting Edge News and I'm doing something more > lengthly and bloggy tonight for DailyKos, whilst hanging around abusing one > of our spare 7507s with various new IOS versions. > > > > > On Sun, Feb 22, 2009 at 12:55 AM, Patrick W. Gilmore >wrote: > > > On Feb 22, 2009, at 1:47 AM, Randy Bush wrote: > > > > Does anyone have the full story on this? > >>>> > >>> > >>> > >> > >> bottom line: > >> o do not redistribute bgp into igp > >> o do not redistribute dynamic igp into bgp > >> o filter your peers and customers > >> > > > > And don't put all your most important infrastructure stuff (e.g. name > > server, mail server, shell host, etc.) in the first /24 of your > / > > allocation. > > > > The biggest problem with 7007 was not that it announced a bunch of > > prefixes. It is that 7007 announced _classful_ prefix (it had been > filtered > > through RIP, remember?) with AS_PATH of ^7007$. This means if you had a > > 194.1.0.0/16, you saw 194.1.0.0/24 from 7007, which is more specific. > Why > > this is bad is left as an exercise to the reader. > > > > And, of course, the problem persisted after the router in question was > > actually unplugged - not powered up or attached to any fibers/cables. > Thank > > you Sprint for running beta code. :) > > > > -- > > TTFN, > > patrick > > > > > > > > > -- > mailto:Neal at layer3arts.com // > GoogleTalk: nrauhauser at gmail.com > IM: nealrauhauser > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From hank at efes.iucc.ac.il Sun Feb 22 01:28:43 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 22 Feb 2009 09:28:43 +0200 Subject: SLAs for colo sites? Message-ID: <5.1.0.14.2.20090222092606.00abfe28@efes.iucc.ac.il> A neutral colo site has to just provide two things really: A/C and power. What happens when a colo site loses power even though they have all the necessary bells and whistles - generators, UPSs, multiple electrical carrier feeds, etc. Can anyone point me at actual online SLAs for colo sites that not only state 100% uptime but also state what happens if they fail that promise? Thanks, Hank From rdobbins at cisco.com Sun Feb 22 01:34:53 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Sun, 22 Feb 2009 15:34:53 +0800 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <9515c62d0902212311w5e5b6029n58af6f9859a6ebb@mail.gmail.com> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> <9515c62d0902212311w5e5b6029n58af6f9859a6ebb@mail.gmail.com> Message-ID: On Feb 22, 2009, at 3:11 PM, neal rauhauser wrote: > Well, I hope I'm not butchering the story up too badly This has been written up several times before - in addition to the links in Richard's post, take a look at the following, including the links at the bottom of the page: Here's a thorough writeup on the Supro incident: For examples of specific applications of *deliberate* (as opposed to accidental, like AS7007) route hijacking, see the following: and then for extra credit, think about this: and this: ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Some things are just too precious to entrust to computers. -- Seth Hanford From nrauhauser at gmail.com Sun Feb 22 01:37:25 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Sun, 22 Feb 2009 01:37:25 -0600 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <137324094-1235287595-cardhu_decombobulator_blackberry.rim.net-1178612991-@bxe1146.bisx.prod.on.blackberry> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> <9515c62d0902212311w5e5b6029n58af6f9859a6ebb@mail.gmail.com> <2116492819-1235287310-cardhu_decombobulator_blackberry.rim.net-1064508903-@bxe1146.bisx.prod.on.blackberry> <9515c62d0902212324h68941227x17386973e6c0c9c5@mail.gmail.com> <137324094-1235287595-cardhu_decombobulator_blackberry.rim.net-1178612991-@bxe1146.bisx.prod.on.blackberry> Message-ID: <9515c62d0902212337y5a96b231u3cdd12fab97419ec@mail.gmail.com> OK, here is the expanded, bloggy one. Some time Monday the more professionally written entry on The Cutting Edge News will be out and I'll share that one, too. http://www.dailykos.com/story/2009/2/22/23440/2313/339/700368 On Sun, Feb 22, 2009 at 1:26 AM, Chaim Rieger wrote: > Back on list > > I doubt you will get skewered, I promise to read it > > Sent via BlackBerry from T-Mobile > > ------------------------------ > *From*: neal rauhauser > *Date*: Sun, 22 Feb 2009 01:24:08 -0600 > *To*: > > *Subject*: Re: Great outage of 1997 - Does anyone recall? > > Oh, you guys will skewer me for it :-) Shall I post the text here so it > gets vetted first? > > > > On Sun, Feb 22, 2009 at 1:21 AM, wrote: > >> Do post a link when its up. >> >> >> Sent via BlackBerry from T-Mobile >> >> -----Original Message----- >> From: neal rauhauser >> >> Date: Sun, 22 Feb 2009 01:11:16 >> To: Patrick W. Gilmore >> Cc: NANOG list >> Subject: Re: Great outage of 1997 - Does anyone recall? >> >> >> Well, I hope I'm not butchering the story up too badly - got an 800 word >> piece going up Monday on The Cutting Edge News and I'm doing something >> more >> lengthly and bloggy tonight for DailyKos, whilst hanging around abusing >> one >> of our spare 7507s with various new IOS versions. >> >> >> >> >> On Sun, Feb 22, 2009 at 12:55 AM, Patrick W. Gilmore > >wrote: >> >> > On Feb 22, 2009, at 1:47 AM, Randy Bush wrote: >> > >> > Does anyone have the full story on this? >> >>>> >> >>> >> >>> >> >> >> >> bottom line: >> >> o do not redistribute bgp into igp >> >> o do not redistribute dynamic igp into bgp >> >> o filter your peers and customers >> >> >> > >> > And don't put all your most important infrastructure stuff (e.g. name >> > server, mail server, shell host, etc.) in the first /24 of your >> / >> > allocation. >> > >> > The biggest problem with 7007 was not that it announced a bunch of >> > prefixes. It is that 7007 announced_classful_ prefix (it had been >> filtered >> > through RIP, remember?) with AS_PATH of ^7007$. This means if you had a >> > 194.1.0.0/16, you saw 194.1.0.0/24 from 7007, which is more specific. >> Why >> > this is bad is left as an exercise to the reader. >> > >> > And, of course, the problem persisted after the router in question was >> > actually unplugged - not powered up or attached to any fibers/cables. >> Thank >> > you Sprint for running beta code. :) >> > >> > -- >> > TTFN, >> > patrick >> > >> > >> > >> >> >> -- >> mailto:Neal at layer3arts.com // >> GoogleTalk: nrauhauser at gmail.com >> IM: nealrauhauser >> > > > > -- > mailto:Neal at layer3arts.com // > GoogleTalk: nrauhauser at gmail.com > IM: nealrauhauser > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From blackham at gmail.com Sun Feb 22 01:52:03 2009 From: blackham at gmail.com (Kevin Blackham) Date: Sun, 22 Feb 2009 00:52:03 -0700 Subject: Comprehensive community Guideline and Policies for an AS In-Reply-To: <499F1CAB.6040003@ttec.com> References: <499EBFB7.5040001@ttec.com> <499F1CAB.6040003@ttec.com> Message-ID: See nLayer. That should be the gold standard. :) On 2/20/09, Joe Maimon wrote: > > > Charles Gucker wrote: >>> What I am looking for is a best practice guide on community policy setup. >>> >>> Barring that, I plan to continue examining every publicly published >>> guideline to try to produce one, but likely as not it will suffer from >>> the >>> all to common human failing of shortsightedness. >> >> Feel free to look at our online collection of BGP Community guides. >> Some are more extensive than others and some intentionally leave off >> internal identifers. >> >> http://www.onesc.net/communities >> >> As a yearly request, if anybody knows of guides out there that we do >> not have listed, please let me know. >> >> thanks, >> charles >> >> > > Its a great list and resource, and the real problem I am looking to > address is trying to create a best of breed out of them all. > > I want to express my appreciation to you and to anyone else involved in > maintaining this resource. > > Thanks, > > Joe > > From ge at linuxbox.org Sun Feb 22 01:57:44 2009 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 22 Feb 2009 01:57:44 -0600 (CST) Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> Message-ID: What was that story with an African routes some years back, any memories anyone? I am looking for a reference. On Sun, 22 Feb 2009, Patrick W. Gilmore wrote: > On Feb 22, 2009, at 1:47 AM, Randy Bush wrote: > >>>> Does anyone have the full story on this? >>> >> >> bottom line: >> o do not redistribute bgp into igp >> o do not redistribute dynamic igp into bgp >> o filter your peers and customers > > And don't put all your most important infrastructure stuff (e.g. name server, > mail server, shell host, etc.) in the first /24 of your / > allocation. > > The biggest problem with 7007 was not that it announced a bunch of prefixes. > It is that 7007 announced _classful_ prefix (it had been filtered through > RIP, remember?) with AS_PATH of ^7007$. This means if you had a > 194.1.0.0/16, you saw 194.1.0.0/24 from 7007, which is more specific. Why > this is bad is left as an exercise to the reader. > > And, of course, the problem persisted after the router in question was > actually unplugged - not powered up or attached to any fibers/cables. Thank > you Sprint for running beta code. :) > > -- > TTFN, > patrick > From nanog at daork.net Sun Feb 22 02:52:09 2009 From: nanog at daork.net (Nathan Ward) Date: Sun, 22 Feb 2009 21:52:09 +1300 Subject: real hardware router VS linux router In-Reply-To: <49A0559E.4050103@consolejunkie.net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D754A.6030008@tiedyenetworks.com> <49A0559E.4050103@consolejunkie.net> Message-ID: <7BF22750-2082-4169-A5B2-8E61E20FAE33@daork.net> On 22/02/2009, at 8:27 AM, Leen Besselink wrote: > If you had to choose, it's probably smarted to go with OpenBSD, it > has a > lot better integration of packet filter, bgpd-daemon, ospf, vrrp- > like, etc. If you have one eBGP session in your whole network, sure. However if you have more than one, BGP cannot do the "Prefer the path with the lowest IGP next-hop metric" thing, as OpenBGPd does not know metrics from OpenOSPFd. Someone commented that OpenBSD would be able to do this soon as metrics were added in to the routing code in - current, but I have not tried this personally and a quick couple of queries on Google didn't reveal anything other than internal OpenOSPFd stuff. I have however used OpenBGPd and OpenOSPFd with great success on routers we put at single-homed customer sites for a small business- only ISP I used to work at. We used BGP communities to put prefixes in to PF tables, and then shaped and accounted based on that. (Here in NZ we have a few thousand domestic prefixes, which transit to/from is often cheaper than transit off-shore). -- Nathan Ward From tme at multicasttech.com Sun Feb 22 10:26:30 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 22 Feb 2009 11:26:30 -0500 Subject: Fwd: Security Assessment of the Transmission Control Protocol (TCP) References: <49A09284.8010005@gont.com.ar> Message-ID: Completing various circles... Marshall Begin forwarded message: > From: Fernando Gont > Date: February 21, 2009 6:47:16 PM EST > To: ietf at ietf.org > Subject: Security Assessment of the Transmission Control Protocol > (TCP) > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello, folks, > > I have just seen that there has been a thread about this document in > this list, so here's a related "announcement": > > Last week the UK CPNI (United Kingdom's Centre for the Protection of > National Infrastructure) released the document "Security Assessment of > the Transmission Control Protocol (TCP)". The document analyzes the > relevant specifications from a security point of view, and also > analyzes > the implications of some implementation strategies taken by popular > TCP implementations. This document is available at: > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf > > As part of the same project, we have produced an IETF I-D version of > the > UK CPNI document, in the hope that the IETF works on this stuff and > hopefully publishes some version of the aforementioned document. The > resulting IETF I-D is entitled "Security Assessment of the > Transmission > Control Protocol (TCP)" (draft-gont-tcp-security-00.txt) and is > available at: http://tools.ietf.org/id/draft-gont-tcp-security-00.txt > > Any comments will be more than welcome. > > Thanks! > > Kind regards, > - -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBCAAGBQJJoJJ8AAoJEJbuqe/Qdv/xQ1gH/RYY8imAcxLInFgMoVAR0OLR > UuTtYXxclpieRWNjEkJTpyiAA/q8czubkuP4kupp11CiL6nQxYZwV2mexG2/lQ91 > Y1TWh9H1ofroWyU9ZMrYcz1PPOSeAY929Sn3U2yHKrm4QSVhH1NSBAVodTu2zKV6 > jvhzny+IDtCrTIeRDZBZYKrFgkxA74vvzasXgj/A8JiPjbhN4zGABWxpsWV+d9Ti > ceZBz8Ny+Mld/AQpag51OqFAVg4Xtzb9omDbxyc43B/YFzT+bTKMSLr3u68tH2xR > xBFYJ50AZxuiayHxDZVHCAf4XrTFyCiD+iXpzlVWiSGcXBcLd6pziYBWdHVEbUo= > =ftHE > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www.ietf.org/mailman/listinfo/ietf From pmm at igtc.com Sun Feb 22 12:02:39 2009 From: pmm at igtc.com (Paul M. Moriarty) Date: Sun, 22 Feb 2009 10:02:39 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! (was: Re: comcast price check)] In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> Message-ID: <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> I've been using their biz offering for the past 18 months and have had a very good experience, including same day fixes all three times I reported problems (no truck dispatch required). For $105/month I get excellent speed and routable IP's. A good deal from my perspective. Oh, and you might want to read those SLA's you get from AT&T or any other carrier. Typically, all they give you for not meeting the SLA is "credits" and you typically have to ask for them, in writing within 30 days to actually get them. - Paul - On Feb 20, 2009, at 9:46 PM, Ryan A. Krenzischek wrote: > > Yes, they do. You can find more information here: > > http://business.comcast.com/ethernet/dedicated-internet.aspx > > Although, I'm sufficiently disappointed with Comcast's Business > Cable service. I have had them since 6-NOV-2008 and they took 4 > months and 1 week to fix a cabling problem at the head-end for my > business Internet. Apparently the head-end was wired wrong in > regards to how power was supplied to it. I had nothing but dropped > packets and latency (400-500 MS, sometimes 1200 MS) problems. I > lost so much business. I tried multiple times to speak with a > manager but they would only pick up their phone after I sat for 30 > minutes with the phone, pressing the redial key and placed 60 calls > to them. I had to call their corporate office and file a > complaint. I am still having dropped packet issues. > > Comcast support also had the nerve to say it was my equipment and > that I should immediately disconnect everything. Remind me again > how is it my problem with *MY* equipment when the modem takes 25 > minutes to sync/lock on the upstream channel? > > I would *highly* recommend a T1 or partial T3. While they are more > expensive and highly reliable, AT&T or other major telcos will fix > the problem within a reasonable SLA. Comcast does NOT have a SLA. > It took 4 months to fix my problems on a business account. > > A Very Unhappy Comcast Customer, > > Ryan Krenzischek > > On Fri, 20 Feb 2009, Steven King wrote: > >> Date: Fri, 20 Feb 2009 23:45:48 -0500 >> From: Steven King >> To: John Martinez >> Cc: NANOG list >> Subject: Re: comcast price check >> Comcast has an Ethernet service? >> >> John Martinez wrote: >>> Does any one here use comcast's ethernet services? >>> If so, what is their price range? >>> >>> >>> Thanks in advance. >>> >>> >>> >>> >> >> From john at vanoppen.com Sun Feb 22 12:08:05 2009 From: john at vanoppen.com (John van Oppen) Date: Sun, 22 Feb 2009 10:08:05 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! (was: Re:comcast price check)] References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com><499D6E99.1090706@uiuc.edu><6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us><499D8FB0.6000000@bogus.com><499DACC0.8040709@ibctech.ca><5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com><499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> Message-ID: Back on the original topic of Comcast fiber. It is sold by region, shoot me an off-list email and I can put you in touch with someone at national who can at least point you in the correct direction. I must say that it appears their metroE services take a back seat to the coax services and thus I never purchased that service when looking into it. On the peering/transit side, the guys at national (AS7922) are really professional (albeit a bit overworked). Our peering link to them is awesome for getting rid of Comcast user complaints. :) John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -----Original Message----- From: Paul M. Moriarty [mailto:pmm at igtc.com] Sent: Sunday, February 22, 2009 10:03 AM To: Ryan A. Krenzischek Cc: NANOG list Subject: Comcast - No complaints! [was: Re: Craptastic Service! (was: Re:comcast price check)] I've been using their biz offering for the past 18 months and have had a very good experience, including same day fixes all three times I reported problems (no truck dispatch required). For $105/month I get excellent speed and routable IP's. A good deal from my perspective. Oh, and you might want to read those SLA's you get from AT&T or any other carrier. Typically, all they give you for not meeting the SLA is "credits" and you typically have to ask for them, in writing within 30 days to actually get them. - Paul - On Feb 20, 2009, at 9:46 PM, Ryan A. Krenzischek wrote: > > Yes, they do. You can find more information here: > > http://business.comcast.com/ethernet/dedicated-internet.aspx > > Although, I'm sufficiently disappointed with Comcast's Business > Cable service. I have had them since 6-NOV-2008 and they took 4 > months and 1 week to fix a cabling problem at the head-end for my > business Internet. Apparently the head-end was wired wrong in > regards to how power was supplied to it. I had nothing but dropped > packets and latency (400-500 MS, sometimes 1200 MS) problems. I > lost so much business. I tried multiple times to speak with a > manager but they would only pick up their phone after I sat for 30 > minutes with the phone, pressing the redial key and placed 60 calls > to them. I had to call their corporate office and file a > complaint. I am still having dropped packet issues. > > Comcast support also had the nerve to say it was my equipment and > that I should immediately disconnect everything. Remind me again > how is it my problem with *MY* equipment when the modem takes 25 > minutes to sync/lock on the upstream channel? > > I would *highly* recommend a T1 or partial T3. While they are more > expensive and highly reliable, AT&T or other major telcos will fix > the problem within a reasonable SLA. Comcast does NOT have a SLA. > It took 4 months to fix my problems on a business account. > > A Very Unhappy Comcast Customer, > > Ryan Krenzischek > > On Fri, 20 Feb 2009, Steven King wrote: > >> Date: Fri, 20 Feb 2009 23:45:48 -0500 >> From: Steven King >> To: John Martinez >> Cc: NANOG list >> Subject: Re: comcast price check >> Comcast has an Ethernet service? >> >> John Martinez wrote: >>> Does any one here use comcast's ethernet services? >>> If so, what is their price range? >>> >>> >>> Thanks in advance. >>> >>> >>> >>> >> >> From sethm at rollernet.us Sun Feb 22 12:09:31 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 22 Feb 2009 10:09:31 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> Message-ID: <49A194DB.2060301@rollernet.us> Paul M. Moriarty wrote: > > Oh, and you might want to read those SLA's you get from AT&T or any > other carrier. Typically, all they give you for not meeting the SLA is > "credits" and you typically have to ask for them, in writing within 30 > days to actually get them. > If I give someone money to do something, and they fail to meet the contracted metrics, what else can they give me except money back? ~Seth From jcdill.lists at gmail.com Sun Feb 22 12:26:24 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 22 Feb 2009 10:26:24 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <49A194DB.2060301@rollernet.us> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> Message-ID: <49A198D0.8080501@gmail.com> Seth Mattinen wrote: > Paul M. Moriarty wrote: > >> Oh, and you might want to read those SLA's you get from AT&T or any >> other carrier. Typically, all they give you for not meeting the SLA is >> "credits" and you typically have to ask for them, in writing within 30 >> days to actually get them. >> >> > > If I give someone money to do something, and they fail to meet the > contracted metrics, what else can they give me except money back? > They can pay a penalty. Simply giving you your money back may not make you whole. Many businesses could make out like a bandit if they don't have to pay a penalty when they don't perform, but just give you your money back. In some lines of business (e.g. residential rental housing) we have laws to protect buyers (renters) that stipulate penalties when sellers (landlords) don't provide the services (livable housing) required by law, in addition to refund of the fee (rent) paid for the services. Giving you your money back when you didn't get the goods isn't really providing an SLA, it's simply not defrauding the customer. jc From patrick at ianai.net Sun Feb 22 12:30:44 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 22 Feb 2009 13:30:44 -0500 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <49A198D0.8080501@gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D6E99.1090706@uiuc.edu> <6069A203FD01884885C037F81DD75080C447EB4C@wsc-mail-01.intra.nwresd.k12.or.us> <499D8FB0.6000000@bogus.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> Message-ID: <14AC26F0-63B2-44AA-8AE0-296E3C13F3CD@ianai.net> On Feb 22, 2009, at 1:26 PM, JC Dill wrote: > Seth Mattinen wrote: >> >> If I give someone money to do something, and they fail to meet the >> contracted metrics, what else can they give me except money back? >> > They can pay a penalty. Simply giving you your money back may not > make you whole. Many businesses could make out like a bandit if > they don't have to pay a penalty when they don't perform, but just > give you your money back. In some lines of business (e.g. > residential rental housing) we have laws to protect buyers (renters) > that stipulate penalties when sellers (landlords) don't provide the > services (livable housing) required by law, in addition to refund of > the fee (rent) paid for the services. > > Giving you your money back when you didn't get the goods isn't > really providing an SLA, it's simply not defrauding the customer. That ain't gonna happen. The housing laws you mention are the exception, not the rule. Very, very, very few businesses have any liability for lack of performance other than the money you paid them. And some not even that. -- TTFN, patrick From brandon.galbraith at gmail.com Sun Feb 22 12:45:13 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sun, 22 Feb 2009 12:45:13 -0600 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <14AC26F0-63B2-44AA-8AE0-296E3C13F3CD@ianai.net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> <14AC26F0-63B2-44AA-8AE0-296E3C13F3CD@ianai.net> Message-ID: <366100670902221045r26658ec6j98d3384d6caf91b8@mail.gmail.com> Very true. You'll be hard pressed to find an IP/transit/dark fiber provider who is going to agree to be liable for anything except what you've paid in the event of an SLA violation. -brandon On 2/22/09, Patrick W. Gilmore wrote: > On Feb 22, 2009, at 1:26 PM, JC Dill wrote: >> Seth Mattinen wrote: >>> > >>> If I give someone money to do something, and they fail to meet the >>> contracted metrics, what else can they give me except money back? >>> >> They can pay a penalty. Simply giving you your money back may not >> make you whole. Many businesses could make out like a bandit if >> they don't have to pay a penalty when they don't perform, but just >> give you your money back. In some lines of business (e.g. >> residential rental housing) we have laws to protect buyers (renters) >> that stipulate penalties when sellers (landlords) don't provide the >> services (livable housing) required by law, in addition to refund of >> the fee (rent) paid for the services. >> >> Giving you your money back when you didn't get the goods isn't >> really providing an SLA, it's simply not defrauding the customer. > > That ain't gonna happen. > > The housing laws you mention are the exception, not the rule. Very, > very, very few businesses have any liability for lack of performance > other than the money you paid them. And some not even that. > > -- > TTFN, > patrick > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From jcdill.lists at gmail.com Sun Feb 22 13:34:52 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 22 Feb 2009 11:34:52 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <366100670902221045r26658ec6j98d3384d6caf91b8@mail.gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> <14AC26F0-63B2-44AA-8AE0-296E3C13F3CD@ianai.net> <366100670902221045r26658ec6j98d3384d6caf91b8@mail.gmail.com> Message-ID: <49A1A8DC.6010002@gmail.com> Just because no network provider today offers to do better than refund your money doesn't mean this is all they "can" do. Perhaps someday one of the networks will be confident enough about their services to offer a better SLA that includes paying a penalty when they fail to deliver what they promised. It would make a great marketing point - we are so confident in our services that our SLA is better than the Other Guys. Like the ads that promise to price match and give you 10% extra if you find a "lower price elsewhere". This marketing strategy would play well when talking to bean counters and suits. jc Brandon Galbraith wrote: > Very true. You'll be hard pressed to find an IP/transit/dark fiber > provider who is going to agree to be liable for anything except what > you've paid in the event of an SLA violation. > > -brandon > > On 2/22/09, Patrick W. Gilmore wrote: > >> On Feb 22, 2009, at 1:26 PM, JC Dill wrote: >> >>> Seth Mattinen wrote: >>> >>>> If I give someone money to do something, and they fail to meet the >>>> contracted metrics, what else can they give me except money back? >>>> >>>> >>> They can pay a penalty. Simply giving you your money back may not >>> make you whole. Many businesses could make out like a bandit if >>> they don't have to pay a penalty when they don't perform, but just >>> give you your money back. In some lines of business (e.g. >>> residential rental housing) we have laws to protect buyers (renters) >>> that stipulate penalties when sellers (landlords) don't provide the >>> services (livable housing) required by law, in addition to refund of >>> the fee (rent) paid for the services. >>> >>> Giving you your money back when you didn't get the goods isn't >>> really providing an SLA, it's simply not defrauding the customer. >>> >> That ain't gonna happen. >> >> The housing laws you mention are the exception, not the rule. Very, >> very, very few businesses have any liability for lack of performance >> other than the money you paid them. And some not even that. >> >> -- >> TTFN, >> patrick >> >> >> >> > > From jimpop at gmail.com Sun Feb 22 13:48:19 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Sun, 22 Feb 2009 14:48:19 -0500 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <49A198D0.8080501@gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> Message-ID: On Sun, Feb 22, 2009 at 13:26, JC Dill wrote: > Many businesses could make out like a bandit if they don't have to > pay a penalty when they don't perform, but just give you your money back. I'm curious, when traveling by car or by plane, do you often demand imposition of penalties for travel latency? -Jim P. From jcdill.lists at gmail.com Sun Feb 22 14:00:24 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 22 Feb 2009 12:00:24 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> Message-ID: <49A1AED8.600@gmail.com> Jim Popovitch wrote: > On Sun, Feb 22, 2009 at 13:26, JC Dill wrote: > >> Many businesses could make out like a bandit if they don't have to >> pay a penalty when they don't perform, but just give you your money back. >> > > I'm curious, when traveling by car or by plane, do you often demand > imposition of penalties for travel latency? Airlines pay "penalties" when they bump passengers even if you get there eventually - just later than you expected. When I am bumped because the plane is overbooked, they don't just put me on the next flight they also compensate me for not putting me on the flight I had a reservation for. When I traveled from SFO to San Diego for Thanksgiving 2 years ago I was bumped both ways. I was compensated each time with a guaranteed seat on the next flight, a meal voucher, and a ticket voucher that I used to fly to the east coast last fall, and will be flying to the east coast again this fall on the second voucher. When traveling by car I have far more control over the proposed route, time-of-day for travel, planned or spontaneous stops, etc. In exchange for this control I am also responsible for the outcome of my own travel plans. jc From brandon.galbraith at gmail.com Sun Feb 22 14:05:15 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sun, 22 Feb 2009 14:05:15 -0600 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <49A1AED8.600@gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> <49A1AED8.600@gmail.com> Message-ID: <366100670902221205v6b40b293qa847683d60750dc7@mail.gmail.com> Notice you said voucher and not cash, which I'd consider the same as a network provider providing a credit and not cash. -brandon On 2/22/09, JC Dill wrote: > Jim Popovitch wrote: >> On Sun, Feb 22, 2009 at 13:26, JC Dill wrote: >> >>> Many businesses could make out like a bandit if they don't have to >>> pay a penalty when they don't perform, but just give you your money back. >>> >> >> I'm curious, when traveling by car or by plane, do you often demand >> imposition of penalties for travel latency? > > Airlines pay "penalties" when they bump passengers even if you get there > eventually - just later than you expected. > > When I am bumped because the plane is overbooked, they don't just put me > on the next flight they also compensate me for not putting me on the > flight I had a reservation for. When I traveled from SFO to San Diego > for Thanksgiving 2 years ago I was bumped both ways. I was compensated > each time with a guaranteed seat on the next flight, a meal voucher, and > a ticket voucher that I used to fly to the east coast last fall, and > will be flying to the east coast again this fall on the second voucher. > > When traveling by car I have far more control over the proposed route, > time-of-day for travel, planned or spontaneous stops, etc. In exchange > for this control I am also responsible for the outcome of my own travel > plans. > > jc > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From pstewart at nexicomgroup.net Sun Feb 22 14:06:13 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sun, 22 Feb 2009 15:06:13 -0500 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <49A1AED8.600@gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com><499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us><49A198D0.8080501@gmail.com> <49A1AED8.600@gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A0209A17F@nexus.nexicomgroup.net> *Some* airlines pay penalties - not all. I was in Florida on business last summer and when I went to do "web checkin" I was told "call this number 1-800xxxxxx". When I did, they apologized and said they couldn't get me out of Florida for 2 additional days. Quite upset, I wanted to know what they were going to do to cover my additional hotel/food costs plus lost time. Their answer was "we'll honor the same seat pricing for the Sunday flight even though it's normally considerably higher"... oh gee, thanks! So for the additional $4-500 in additional expenses incurred I got "a deal" on their screwup. The worst part was that I booked that particular flight and chose my seat there was ZERO others booked on it as I booked it almost 9 months in advance. So more on topic, make sure the SLA is good and perhaps confirm via references that they back it up. SLA's are no good if they are not willing to "put their money where their mouth is".... ;) Paul -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: February 22, 2009 3:00 PM Cc: NANOG list Subject: Re: Comcast - No complaints! [was: Re: Craptastic Service! Jim Popovitch wrote: > On Sun, Feb 22, 2009 at 13:26, JC Dill wrote: > >> Many businesses could make out like a bandit if they don't have to >> pay a penalty when they don't perform, but just give you your money back. >> > > I'm curious, when traveling by car or by plane, do you often demand > imposition of penalties for travel latency? Airlines pay "penalties" when they bump passengers even if you get there eventually - just later than you expected. When I am bumped because the plane is overbooked, they don't just put me on the next flight they also compensate me for not putting me on the flight I had a reservation for. When I traveled from SFO to San Diego for Thanksgiving 2 years ago I was bumped both ways. I was compensated each time with a guaranteed seat on the next flight, a meal voucher, and a ticket voucher that I used to fly to the east coast last fall, and will be flying to the east coast again this fall on the second voucher. When traveling by car I have far more control over the proposed route, time-of-day for travel, planned or spontaneous stops, etc. In exchange for this control I am also responsible for the outcome of my own travel plans. jc ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From jmaimon at ttec.com Sun Feb 22 15:34:08 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 22 Feb 2009 16:34:08 -0500 Subject: Comprehensive community Guideline and Policies for an AS In-Reply-To: References: <499EBFB7.5040001@ttec.com> <499F1CAB.6040003@ttec.com> Message-ID: <49A1C4D0.2@ttec.com> Kevin Blackham wrote: > See nLayer. That should be the gold standard. :) > A gold standard is precisely what I am looking for. http://onesc.net/communities/as4436/ nLayer's does look fairly comprehensive. A few nitpick that lead me to hesitate to adopt it. " The informational tags comprised of 4436:TCRPP T The type of relationship that the route was learned through C The continent where the route was learned R The region where the route was learned PP The POP location (city code) " *) Type of routes have a maximum of 6 possible types. That could be limiting. nLayer lists 1-5 types already, granted those are the typical relationships and should cover most needs. *) Pop location code has a maximum of 99. nLayer is already up to 30. What are they going to do when they reach 100? Suppose instead of cities you wanted to number pops? Quite conceivable to have multiple pops in the same city. " Import/Export Action Communities These communities define specific import/export behaviors, and contain location codes to specify which BGP sessions the actions should be applied to. The second half of the Community will always be 4 digits long, and will have the following structure: ASN:A0CR -or- ASN:A1PP ASN The Autonomous System Number to affect A The export action to perform C Continental code (or 0 for all continents) R Regional code (or 0 for all regions) PP POP Location code (city code) " Using other ASN's as part of your communities policy raises two issues: - Is it a good idea without drawback (sprint does this also but only with private ASNs)? - How will this scale to 4byte ASN's? Anyways, the point I am working from is that there are too many divergent approaches and all networks cant be that different and there should be one general approach that will work for all. Thanks, Joe From jcdill.lists at gmail.com Sun Feb 22 15:37:06 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 22 Feb 2009 13:37:06 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0209A17F@nexus.nexicomgroup.net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499DACC0.8040709@ibctech.ca> <5792267e0902201732x7891a5a0p9e5323903763fba8@mail.gmail.com> <499F8258.1030402@zero11.com><499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us><49A198D0.8080501@gmail.com> <49A1AED8.600@gmail.com> <89D27DE3375BB6428DDCC2927489826A0209A17F@nexus.nexicomgroup.net> Message-ID: <49A1C582.4010201@gmail.com> Paul Stewart wrote: > *Some* airlines pay penalties - not all. > When you have a confirmed reservation, airlines in the US and EU are required to pay "delayed boarding compensation" when you are involuntarily bumped, unless the reason is something completely outside their control (such as the weather or when planes are ordered grounded as happened after 9/11), or they are flying smaller jets (special exceptions because of weight-and-balance safety rules). This is in addition to allowing you to use your ticket on the next available flight. If you elect to make alternate travel arrangements US airlines also have to refund your ticket, even when it's a "non-refundable" ticket. http://law.justia.com/us/cfr/title14/14-4.0.1.1.28.0.8.10.html http://www.itourist.com/members/tips/view.php?id=45 http://www.discountairfares.com/deniedbo.htm From jimpop at gmail.com Sun Feb 22 16:31:17 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Sun, 22 Feb 2009 17:31:17 -0500 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <49A1C582.4010201@gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> <49A1AED8.600@gmail.com> <89D27DE3375BB6428DDCC2927489826A0209A17F@nexus.nexicomgroup.net> <49A1C582.4010201@gmail.com> Message-ID: On Sun, Feb 22, 2009 at 16:37, JC Dill wrote: > When you have a confirmed reservation, airlines in the US and EU are > required to pay "delayed boarding compensation" when you are involuntarily > bumped, unless the reason is something completely outside their control > (such as the weather or when planes are ordered grounded as happened after > 9/11), or they are flying smaller jets (special exceptions because of > weight-and-balance safety rules). This is in addition to allowing you to > use your ticket on the next available flight. If you elect to make > alternate travel arrangements US airlines also have to refund your ticket, > even when it's a "non-refundable" ticket. But that doesn't really equate to network traffic (IMHO). If your upstream has an outage, it is more akin to a delayed departure rather than an airline bump or flight cancellation. You reach your destination later than planned (latency) and you may have to take a different route, but your packet^Wbutt gets through. Neither of those situations involve cash compensation, or penalties paid, by major airlines. At most you might get a few loyalty points. Now if your upstream network provider disconnected you and/or was unable to route your packets to their final destination.... -Jim P. From jcdill.lists at gmail.com Sun Feb 22 16:58:29 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 22 Feb 2009 14:58:29 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> <49A1AED8.600@gmail.com> <89D27DE3375BB6428DDCC2927489826A0209A17F@nexus.nexicomgroup.net> <49A1C582.4010201@gmail.com> Message-ID: <49A1D895.1050801@gmail.com> Jim Popovitch wrote: > But that doesn't really equate to network traffic (IMHO). No, it doesn't. I didn't make the analogy to airlines, I responded to the analogy made by someone else. > If your > upstream has an outage, it is more akin to a delayed departure rather > than an airline bump or flight cancellation. You reach your > destination later than planned (latency) and you may have to take a > different route, but your packet^Wbutt gets through. Neither of > those situations involve cash compensation, or penalties paid, by > major airlines. At most you might get a few loyalty points. When overbooking results in a passenger being bumped to a flight that departs 2 hours later, your packet^Wbutt gets through too, but you also get compensation for the delay. An argument could be made that extensive outage/network problems (longer than 2 hours?) are similar in duration/effect, and that similar compensation should be due. I'm not saying that I expect this to happen, I'm just saying that there's plenty of precedent for other types of businesses compensating customers beyond merely giving refunds. jc From jmartinez at zero11.com Sun Feb 22 17:31:27 2009 From: jmartinez at zero11.com (John Martinez) Date: Sun, 22 Feb 2009 15:31:27 -0800 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <49A1D895.1050801@gmail.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499F86FC.5020106@kingrst.com> <67911119-2CE9-4EBF-985E-12D2207FCBA2@igtc.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> <49A1AED8.600@gmail.com> <89D27DE3375BB6428DDCC2927489826A0209A17F@nexus.nexicomgroup.net> <49A1C582.4010201@gmail.com> <49A1D895.1050801@gmail.com> Message-ID: <49A1E04F.1070006@zero11.com> So the most constructive answer that I received related to this thread is that someone is using Comcast Ethernet services for $5.25/MB for a 500MB pipe. I wonder how much 10MB synchronous would cost? JC Dill wrote: > Jim Popovitch wrote: >> But that doesn't really equate to network traffic (IMHO). > > No, it doesn't. I didn't make the analogy to airlines, I responded to > the analogy made by someone else. > >> If your >> upstream has an outage, it is more akin to a delayed departure rather >> than an airline bump or flight cancellation. You reach your >> destination later than planned (latency) and you may have to take a >> different route, but your packet^Wbutt gets through. Neither of >> those situations involve cash compensation, or penalties paid, by >> major airlines. At most you might get a few loyalty points. > When overbooking results in a passenger being bumped to a flight that > departs 2 hours later, your packet^Wbutt gets through too, but you also > get compensation for the delay. An argument could be made that > extensive outage/network problems (longer than 2 hours?) are similar in > duration/effect, and that similar compensation should be due. > > I'm not saying that I expect this to happen, I'm just saying that > there's plenty of precedent for other types of businesses compensating > customers beyond merely giving refunds. > > jc > From jimpop at gmail.com Sun Feb 22 17:35:45 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Sun, 22 Feb 2009 18:35:45 -0500 Subject: Comcast - No complaints! [was: Re: Craptastic Service! In-Reply-To: <49A1E04F.1070006@zero11.com> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <49A194DB.2060301@rollernet.us> <49A198D0.8080501@gmail.com> <49A1AED8.600@gmail.com> <89D27DE3375BB6428DDCC2927489826A0209A17F@nexus.nexicomgroup.net> <49A1C582.4010201@gmail.com> <49A1D895.1050801@gmail.com> <49A1E04F.1070006@zero11.com> Message-ID: On Sun, Feb 22, 2009 at 18:31, John Martinez wrote: > So the most constructive answer that I received related to this thread > is that someone is using Comcast Ethernet services for $5.25/MB for a > 500MB pipe. > I wonder how much 10MB synchronous would cost? From: http://business.comcast.com/large/index.aspx "call 1-866-511-6489, option1 to speak with an Account Manager" Same page also has other contact resources. -Jim P. From ras at e-gerbil.net Sun Feb 22 17:58:41 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sun, 22 Feb 2009 17:58:41 -0600 Subject: Comprehensive community Guideline and Policies for an AS Message-ID: <20090222235841.GZ51443@gerbil.cluepon.net> > nLayer's does look fairly comprehensive. > > A few nitpick that lead me to hesitate to adopt it. > > The informational tags comprised of > > 4436:TCRPP > > T The type of relationship that the route was learned through > C The continent where the route was learned > R The region where the route was learned > PP The POP location (city code) > > Type of routes have a maximum of 6 possible types. That could be > limiting. nLayer lists 1-5 types already, granted those are the > typical relationships and should cover most needs. Designing a community system requires coming up with creative ways to stuff as much data as possible into a fairly limited amount of space, which obviously means you're going to have to make some compromises from what might be ideal. I addressed a lot of these design considerations in my NANOG presentation on the subject: http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf Since the underlying field is only 16 bits, the maximum possible value is 65535. If each character is going to be used as a "field", then obviously you either have to limit the first digit to 6 and the second digit to 5, or the first digit to 5 to allow a full range of values in the second digit. Since there were really only 5 relationship types which I ever need to express, but more than 5 potential continents to cover, I decided to go with the system above. If you have different considerations in your network, it only makes sense to design this differently. > Pop location code has a maximum of 99. nLayer is already up to 30. > > What are they going to do when they reach 100? Suppose instead of > cities you wanted to number pops? Quite conceivable to have multiple > pops in the same city. Again, this was part of the design consideration. Given the limited amount of space and all the data we wanted to include, the decision was made to limit city codes to 99. Given our plans for network expansion, which don't involve becoming a telco and going into a massive number of cities, this was a reasonable compromise. One possible way to encode more data is to split things into multiple community tags, each one defining a specific type of information. The reason we didn't go this route was that it makes it harder for end users to match on combinations of information, since they would have to do AND type matching with multiple regexp statements. If this is less of a consideration for you than you can certainly fit more and bigger data using multiple communities, but we decided we were happy enough with what we had and wanted it keep it user friendly. > Using other ASN's as part of your communities policy raises two > issues: > > - Is it a good idea without drawback (sprint does this also but only > with private ASNs)? > > - How will this scale to 4byte ASN's? > > Anyways, the point I am working from is that there are too many > divergent approaches and all networks cant be that different and there > should be one general approach that will work for all. I also talked about this point in my presentation. Our motiviation for using the real target ASN in the first half of the community was to implement script-based automatic support for communities targetting all eBGP neighbors rather than just a limited handful. This causes several other areas of "increased difficulty" as well, but I personally think it is valuable enough to make it worth the effort. Another way we considered but decided against was the use of private ASNs on the left side to control actions, and the data side on the right half to select a target, for example: 64512:1239 (apply some action 64512 to neighbors AS1239) But we decided against this due to the extreme limitations this would place on the action fields. The private ASN range of 64512-65535 only supports 2 characters with a full range, and just shifts the potential community conflicts into the private ASN space anyways. As far as 4 byte ASN support goes, in order to provide any real support for them we're all going to have to switch to extended communities, which will probably be far trickier than the actual AS4 implementation itself. The format for 4 byte ASN support is: http://tools.ietf.org/id/draft-rekhter-as4octet-ext-community-03.txt Which defines: 16 bits of Type and Subtype values 32 bits of Global Administrator value (i.e. the ASN) 16 bits of actual user-defined data One very nice thing this brings to the table is the addition of the type and subtype fields. Just in the two basic type definitions which are a part of the RFC we already have a very useful innovation, the use of "origin" (i.e. informational communities set by the specified ASN) and "target" (i.e. action communities to be applied to the specified ASN) communities. Unfortunately vendor support is very basic right now, and nobody seems to have given much thought to how we're all going to successfully transition to them. I personally think the only reasonable way to do it is to add a policy mechanism for converting between types on network borders, but nobody seems to have gone this route so far. I think people are assuming vendors are more prepared than they actually are, not understanding that most of the functionality and testing is for little more than l3vpn support. Try rewriting your policies to support both regular and extended communities and see how easy it is. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From kurtis at kurtis.pp.se Sun Feb 22 20:13:33 2009 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 23 Feb 2009 03:13:33 +0100 Subject: Global Crossing announcing prefixes they do not own Message-ID: <3DD50BE5-4D6B-4722-8920-A5B0978DF9BA@kurtis.pp.se> Can someone from Global Crossing that actually reads and responds to email (as opposed to their NOC and contacts listed in their ASN object) and care that they are announcing prefixes that are not theirs - please contact me off-list... Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From pauldotwall at gmail.com Sun Feb 22 23:06:05 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 23 Feb 2009 00:06:05 -0500 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> Message-ID: <620fd17c0902222106p6a6e5a8budce1e793486b4343@mail.gmail.com> On Sun, Feb 22, 2009 at 2:57 AM, Gadi Evron wrote: > What was that story with an African routes some years back, any memories > anyone? I am looking for a reference. 146.20.0.0/16? Paul From morrowc.lists at gmail.com Sun Feb 22 23:10:47 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 Feb 2009 00:10:47 -0500 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <620fd17c0902222106p6a6e5a8budce1e793486b4343@mail.gmail.com> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> <620fd17c0902222106p6a6e5a8budce1e793486b4343@mail.gmail.com> Message-ID: <75cb24520902222110g79166d2td0bc7a35a49fb6d0@mail.gmail.com> On Mon, Feb 23, 2009 at 12:06 AM, Paul Wall wrote: > On Sun, Feb 22, 2009 at 2:57 AM, Gadi Evron wrote: >> What was that story with an African routes some years back, any memories >> anyone? I am looking for a reference. > > 146.20.0.0/16? that's erie forge/steal... I think maybe Gadi's referring to the 41/8 used by an italian DSL provider for their internal network?? (not announced outside their ASN I don't think) -Chris From danny at tcb.net Sun Feb 22 23:15:11 2009 From: danny at tcb.net (Danny McPherson) Date: Sun, 22 Feb 2009 22:15:11 -0700 Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: <75cb24520902222110g79166d2td0bc7a35a49fb6d0@mail.gmail.com> References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> <620fd17c0902222106p6a6e5a8budce1e793486b4343@mail.gmail.com> <75cb24520902222110g79166d2td0bc7a35a49fb6d0@mail.gmail.com> Message-ID: On Feb 22, 2009, at 10:10 PM, Christopher Morrow wrote: > On Mon, Feb 23, 2009 at 12:06 AM, Paul Wall > wrote: >> On Sun, Feb 22, 2009 at 2:57 AM, Gadi Evron wrote: >>> What was that story with an African routes some years back, any >>> memories >>> anyone? I am looking for a reference. >> >> 146.20.0.0/16? > > that's erie forge/steal... I think maybe Gadi's referring to the 41/8 > used by an italian DSL provider for their internal network?? (not > announced outside their ASN I don't think) Or the AFOL-KE thing with Above last March: -danny From zartash at gmail.com Mon Feb 23 02:19:31 2009 From: zartash at gmail.com (Zartash Uzmi) Date: Mon, 23 Feb 2009 13:19:31 +0500 Subject: Network SLA In-Reply-To: <499DBE2A.6020907@gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <499DBE2A.6020907@gmail.com> Message-ID: <4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> As I gather, there is a mix of answers, ranging from "building the resources according to requirements and HOPE for the best" to "use of arguably sophisticated tools and perhaps sharing the results with the legal department". I would be particularly interested in hearing the service providers' viewpoint on the following situation. Consider a service provider with MPLS deployed within its own network. (A) When the SP enters into a relation with the customer, does the SP establish new MPLS paths based on customer demands (this is perhaps similar to "building" based on requirements as pointed out by David)? If yes, between what sites/POPs? I assume the answer may be different depending upon a single-site customer or a customer with multiple sites. (B) For entering into the relationship for providing X units of bandwidth (to another site of same customer or to the Tier-1 backbone), does the SP use any wisdom (in addition to MRTG and the likes)? If so, what scientific parameters are kept in mind? (C) How does the customer figure out that a promise for X units of bandwidth is maintained by the SP? I believe customers may install some measuring tools but is that really the case in practice? Thanks, Zartash On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: > Saqib Ilyas wrote: > >> Greetings >> I am curious to know about any tools/techniques that a service provider >> uses >> to assess an SLA before signing it. That is to say, how does an >> administrator know if he/she can meet what he is promising. Is it based on >> experience? Are there commonly used tools for this? >> Thanks and best regards >> >> > Not necessarily as a direct answer (I am pretty sure there'll be others on > this list giving details in the area of specific tools and standards), but I > think this may be a question (especially considering your end result > concern: *signing the SLA!) equally applicable to your legal department. In > the environment we live, nowadays, the SLA could (should?!? ... > unfortunately) be "refined" and (at the other end - i.e. receiving) > "interpreted" by the lawyers, with possibly equal effects (mostly financial > and as overall impact on the business) as the tools we (the technical > people) would be using to measure latency, uptime, bandwidth, jitter, etc... > > Stefan > > From bruce at yoafrica.com Mon Feb 23 02:22:03 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Mon, 23 Feb 2009 10:22:03 +0200 Subject: FW: Ctrl+Shift+6 then X Message-ID: <002801c9958f$ced9c510$6c8d4f30$@com> Hi Guys, If anyone can tell me how to resolve this issue there's a strong possibility of a fedex'd beer. Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 then X (on a cisco) works only sometimes after beating your keyboard multiple times with a hammer, has anyone else come across or had a solution to this problem ? Regards, Bruce Grobler Yo!Africa - Network Engineer Landline: +263-4-701300, Cellphone: +263-91-2364532 Skype ID: bruce.grobler From elmi at 4ever.de Mon Feb 23 02:42:03 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 23 Feb 2009 09:42:03 +0100 Subject: FW: Ctrl+Shift+6 then X In-Reply-To: <002801c9958f$ced9c510$6c8d4f30$@com> References: <002801c9958f$ced9c510$6c8d4f30$@com> Message-ID: <20090223084203.GX27070@ronin.4ever.de> Re Bruce, bruce at yoafrica.com (Bruce Grobler) wrote: > Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 then X > (on a cisco) works only sometimes after beating your keyboard multiple times > with a hammer, has anyone else come across or had a solution to this problem > ? I have found that using "Ctrl-6" (through putty) gives me breaks on Ciscos. You usually have to wait for the device to poll for a break (especially in pings/traceroutes), but it does actually work. Elmar. PS: Please don't fedex beer to Germany... From shon at unwiredbb.com Mon Feb 23 02:48:03 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Mon, 23 Feb 2009 00:48:03 -0800 Subject: FW: Ctrl+Shift+6 then X In-Reply-To: <002801c9958f$ced9c510$6c8d4f30$@com> References: <002801c9958f$ced9c510$6c8d4f30$@com> Message-ID: <49A262C3.4040904@unwiredbb.com> Bruce, I have that problem using any terminal program (I use SecureCRT).. I have to bang the command like 10-20 times for the device to recognize it. Kind of wished CTRL-C or something worked better and actually worked well. Shon Elliott Senior Network Engineer unWired Broadband, Inc. Bruce Grobler wrote: > Hi Guys, > > > > If anyone can tell me how to resolve this issue there's a strong possibility > of a fedex'd beer. > > > > Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 then X > (on a cisco) works only sometimes after beating your keyboard multiple times > with a hammer, has anyone else come across or had a solution to this problem > ? > > > > Regards, > > > > Bruce Grobler > > Yo!Africa - Network Engineer > > Landline: +263-4-701300, Cellphone: +263-91-2364532 > > Skype ID: bruce.grobler > > > > From bruce at yoafrica.com Mon Feb 23 03:02:48 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Mon, 23 Feb 2009 11:02:48 +0200 Subject: FW: Ctrl+Shift+6 then X In-Reply-To: <49A262C3.4040904@unwiredbb.com> References: <002801c9958f$ced9c510$6c8d4f30$@com> <49A262C3.4040904@unwiredbb.com> Message-ID: <003001c99595$7fc5e070$7f51a150$@com> Ye, exact same things happens for me, then after it decides to execute it you have a nice long line of 6x6x66x6x666x66666, tried the Ctrl+6 no such luck... -----Original Message----- From: Shon Elliott [mailto:shon at unwiredbb.com] Sent: Monday, February 23, 2009 10:48 AM To: nanog at nanog.org >> nanog Subject: Re: FW: Ctrl+Shift+6 then X Bruce, I have that problem using any terminal program (I use SecureCRT).. I have to bang the command like 10-20 times for the device to recognize it. Kind of wished CTRL-C or something worked better and actually worked well. Shon Elliott Senior Network Engineer unWired Broadband, Inc. Bruce Grobler wrote: > Hi Guys, > > > > If anyone can tell me how to resolve this issue there's a strong possibility > of a fedex'd beer. > > > > Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 then X > (on a cisco) works only sometimes after beating your keyboard multiple times > with a hammer, has anyone else come across or had a solution to this problem > ? > > > > Regards, > > > > Bruce Grobler > > Yo!Africa - Network Engineer > > Landline: +263-4-701300, Cellphone: +263-91-2364532 > > Skype ID: bruce.grobler > > > > From mmoriniaux at prosodie.com Mon Feb 23 03:18:27 2009 From: mmoriniaux at prosodie.com (Moriniaux Michel) Date: Mon, 23 Feb 2009 10:18:27 +0100 Subject: Ctrl+Shift+6 then X References: <002801c9958f$ced9c510$6c8d4f30$@com> Message-ID: Hi, Yep does that all the time the worst is on a traceroute where it seems you need to wait for the end of line to send the ctrl+shift+6. Workaround on cisco: Line con 0 Escape-character 3 Line vty 0 4 Escape-character 3 Whith this you can just CTRL+C Cheers, Michel Moriniaux -----Message d'origine----- De?: Bruce Grobler [mailto:bruce at yoafrica.com] Envoy??: lundi 23 f?vrier 2009 09:22 ??: nanog at nanog.org Objet?: FW: Ctrl+Shift+6 then X Hi Guys, If anyone can tell me how to resolve this issue there's a strong possibility of a fedex'd beer. Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 then X (on a cisco) works only sometimes after beating your keyboard multiple times with a hammer, has anyone else come across or had a solution to this problem ? Regards, Bruce Grobler Yo!Africa - Network Engineer Landline: +263-4-701300, Cellphone: +263-91-2364532 Skype ID: bruce.grobler From herrin-nanog at dirtside.com Mon Feb 23 03:20:24 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 23 Feb 2009 04:20:24 -0500 Subject: FW: Ctrl+Shift+6 then X In-Reply-To: <49A262C3.4040904@unwiredbb.com> References: <002801c9958f$ced9c510$6c8d4f30$@com> <49A262C3.4040904@unwiredbb.com> Message-ID: <3c3e3fca0902230120h3531cf93pea2200d13014bcc6@mail.gmail.com> On Mon, Feb 23, 2009 at 3:48 AM, Shon Elliott wrote: > I have that problem using any terminal program (I use SecureCRT).. I have to > bang the command like 10-20 times for the device to recognize it. Kind of wished > CTRL-C or something worked better and actually worked well. I usually change the escape character to ctrl-C using: line vty 0 15 escape-character 3 Then you can escape with Ctrl-C followed by x. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ip at ioshints.info Mon Feb 23 03:54:09 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 23 Feb 2009 10:54:09 +0100 Subject: FW: Ctrl+Shift+6 then X In-Reply-To: <003001c99595$7fc5e070$7f51a150$@com> References: <002801c9958f$ced9c510$6c8d4f30$@com><49A262C3.4040904@unwiredbb.com> <003001c99595$7fc5e070$7f51a150$@com> Message-ID: <001501c9959c$b18eeaa0$0a00000a@nil.si> Just configure a different escape character with "terminal escape x". For example, "term esc 3" will make Ctrl/C the escape character (and Ctrl/C+X the escape sequence). Ctrl/^ is "somewhat" hard to get on "some" terminal emulators :) Ivan > > If anyone can tell me how to resolve this issue there's a strong > possibility > > of a fedex'd beer. > > > > Using Putty or any other ssh/telnet terminal I find that > Ctrl+Shift+6 > > then > X > > (on a cisco) works only sometimes after beating your > keyboard multiple > times > > with a hammer, has anyone else come across or had a solution to this > problem From ge at linuxbox.org Mon Feb 23 04:03:20 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 23 Feb 2009 04:03:20 -0600 (CST) Subject: Great outage of 1997 - Does anyone recall? In-Reply-To: References: <9515c62d0902212228m111009cascdf185c8e1d95373@mail.gmail.com> <7268D289-F3B7-4ECD-8DEA-995B7DEEA058@ianai.net> <620fd17c0902222106p6a6e5a8budce1e793486b4343@mail.gmail.com> <75cb24520902222110g79166d2td0bc7a35a49fb6d0@mail.gmail.com> Message-ID: On Sun, 22 Feb 2009, Danny McPherson wrote: > > On Feb 22, 2009, at 10:10 PM, Christopher Morrow wrote: > >> On Mon, Feb 23, 2009 at 12:06 AM, Paul Wall wrote: >>> On Sun, Feb 22, 2009 at 2:57 AM, Gadi Evron wrote: >>>> What was that story with an African routes some years back, any memories >>>> anyone? I am looking for a reference. >>> >>> 146.20.0.0/16? >> >> that's erie forge/steal... I think maybe Gadi's referring to the 41/8 >> used by an italian DSL provider for their internal network?? (not >> announced outside their ASN I don't think) > > Or the AFOL-KE thing with Above last March: > > Thanks for all the references! > -danny From bruce at yoafrica.com Mon Feb 23 03:28:17 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Mon, 23 Feb 2009 11:28:17 +0200 Subject: Ctrl+Shift+6 then X In-Reply-To: References: <002801c9958f$ced9c510$6c8d4f30$@com> Message-ID: <003601c99599$0f2ef3c0$2d8cdb40$@com> Oh wow, that worked like a charm !!!! Thanks a bunch!!! :D -----Original Message----- From: Moriniaux Michel [mailto:mmoriniaux at prosodie.com] Sent: Monday, February 23, 2009 11:18 AM To: Bruce Grobler; nanog at nanog.org Subject: RE: Ctrl+Shift+6 then X Hi, Yep does that all the time the worst is on a traceroute where it seems you need to wait for the end of line to send the ctrl+shift+6. Workaround on cisco: Line con 0 Escape-character 3 Line vty 0 4 Escape-character 3 Whith this you can just CTRL+C Cheers, Michel Moriniaux -----Message d'origine----- De?: Bruce Grobler [mailto:bruce at yoafrica.com] Envoy??: lundi 23 f?vrier 2009 09:22 ??: nanog at nanog.org Objet?: FW: Ctrl+Shift+6 then X Hi Guys, If anyone can tell me how to resolve this issue there's a strong possibility of a fedex'd beer. Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 then X (on a cisco) works only sometimes after beating your keyboard multiple times with a hammer, has anyone else come across or had a solution to this problem ? Regards, Bruce Grobler Yo!Africa - Network Engineer Landline: +263-4-701300, Cellphone: +263-91-2364532 Skype ID: bruce.grobler From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Feb 23 05:35:01 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 23 Feb 2009 22:05:01 +1030 Subject: Ctrl+Shift+6 then X In-Reply-To: <003601c99599$0f2ef3c0$2d8cdb40$@com> References: <002801c9958f$ced9c510$6c8d4f30$@com> <003601c99599$0f2ef3c0$2d8cdb40$@com> Message-ID: <20090223220501.662b2c5e.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Mon, 23 Feb 2009 11:28:17 +0200 "Bruce Grobler" wrote: > Oh wow, that worked like a charm !!!! Thanks a bunch!!! :D > What, nobody's using vt220s anymore? (Almost bought one (or rather a vt420) off ebay for fun to plug in to one of our 2500 terminal servers for the machine room - but realised that not having cut-and-paste would be very annoying.) > -----Original Message----- > From: Moriniaux Michel [mailto:mmoriniaux at prosodie.com] > Sent: Monday, February 23, 2009 11:18 AM > To: Bruce Grobler; nanog at nanog.org > Subject: RE: Ctrl+Shift+6 then X > > Hi, > Yep does that all the time the worst is on a traceroute where it seems you > need to wait for the end of line to send the ctrl+shift+6. > Workaround on cisco: > Line con 0 > Escape-character 3 > Line vty 0 4 > Escape-character 3 > > Whith this you can just CTRL+C > > Cheers, > Michel Moriniaux > > -----Message d'origine----- > De?: Bruce Grobler [mailto:bruce at yoafrica.com] > Envoy??: lundi 23 f?vrier 2009 09:22 > ??: nanog at nanog.org > Objet?: FW: Ctrl+Shift+6 then X > > Hi Guys, > > > > If anyone can tell me how to resolve this issue there's a strong possibility > of a fedex'd beer. > > > > Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 then X > (on a cisco) works only sometimes after beating your keyboard multiple times > with a hammer, has anyone else come across or had a solution to this problem > ? > > > > Regards, > > > > Bruce Grobler > > Yo!Africa - Network Engineer > > Landline: +263-4-701300, Cellphone: +263-91-2364532 > > Skype ID: bruce.grobler > > > > From deric.kwok2000 at gmail.com Mon Feb 23 09:08:26 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Mon, 23 Feb 2009 10:08:26 -0500 Subject: switch speed question Message-ID: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> Hi Can you share your experience what is fastest Gig switch? I see there is CEF feature in cisco. ls it big different when i enable it in switch vs other switch? ls there any problem? Thank you From bfeeny at mac.com Mon Feb 23 09:20:13 2009 From: bfeeny at mac.com (Brian Feeny) Date: Mon, 23 Feb 2009 10:20:13 -0500 Subject: switch speed question In-Reply-To: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> References: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> Message-ID: <0DBE8406-4C1E-43A3-8FD2-3B2CC22D827A@mac.com> Can you elaborate a bit on your question? The fastest "Gig switches" can do 1GB full speed on the port. There are many that can do that. Do you have a particular density you need to do full speed with? Any particular features? Are you looking at any particular models now, in others words have you even begun to explore this before posting here? Are you looking at Layer 3 switching, I assume you are since you are asking about CEF. Every manufacturer has a way of switching the packets, Cisco uses CEF, and yes if you enable CEF its a big difference vs. a netgear gig switch from best buy, but I think you are wanting more of an answer than that and you just need to give us some more info. Brian On Feb 23, 2009, at 10:08 AM, Deric Kwok wrote: > Hi > > Can you share your experience what is fastest Gig switch? > > I see there is CEF feature in cisco. > > ls it big different when i enable it in switch vs other switch? > > ls there any problem? > > Thank you From lists at mtin.net Mon Feb 23 10:46:13 2009 From: lists at mtin.net (Justin Wilson - MTIN) Date: Mon, 23 Feb 2009 11:46:13 -0500 Subject: comcast price check In-Reply-To: <20090221120221.0a6b0ed9@cs.columbia.edu> Message-ID: In a "Former Life" we used Comcast for transport for a school corporation. In the 3 years we used them we have 10 minutes of unscheduled downtime. Justin From dholmes at mwdh2o.com Mon Feb 23 11:47:28 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 23 Feb 2009 09:47:28 -0800 Subject: external L2 ethernet connections In-Reply-To: <499EC121.9090204@ttec.com> References: <499EC121.9090204@ttec.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E086A2DD9@usmsxt104.mwd.h2o> All of the protocols below should be turned off; my understanding is that with dot1q trunking vlan1 cannot be removed from the trunk, although Cisco's isl trunking allows the removal of all vlans. If Cisco equipment is used, the "bpdu filter" command is useful as it instructs the switch to neither send bpdus nor accept them. These are good practices not just for connectivity to other AS's, but also in cases where Ethernet switches comprise a geographically dispersed WAN backbone. The key is to turn off all layer 2 state machines in the connected Ethernet switches, enabling only layer 3 state machines. We have found with some vendors' equipment that the layer 2/layer 3 state machines are not tightly integrated so, for instance, a cam timeout in layer 2 will remove the underlying port/mac table entry for a destination layer 3 network, resulting in unknown unicast flooding with noticeable effects on user response time. -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Friday, February 20, 2009 6:42 AM To: nanog at nanog.org Subject: external L2 ethernet connections Does anyone have a best practice list of things to disable/filter/turn off on ethernet ports l2 connected to other AS's cdp stp switchport negotiate vtp if trunking, limit vlans, no vlan1 So on so forth. Switches do so many darn things all by themselves, as any packet capture shows. Thanks, Joe From nrauhauser at gmail.com Mon Feb 23 12:09:49 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Mon, 23 Feb 2009 12:09:49 -0600 Subject: NANOG in the news Message-ID: <9515c62d0902231009j7b4eea86kb4e4eee65309cb84@mail.gmail.com> http://www.thecuttingedgenews.com/index.php?article=11111&pageid=28&pagename=Sci-Tech -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From trall at almaden.ibm.com Mon Feb 23 12:26:42 2009 From: trall at almaden.ibm.com (Tony Rall) Date: Mon, 23 Feb 2009 10:26:42 -0800 Subject: NANOG in the news In-Reply-To: <9515c62d0902231009j7b4eea86kb4e4eee65309cb84@mail.gmail.com> Message-ID: Very nice. But note that our group's name is "North American Network Operators' Group" (not "Operations"). -- Tony Rall From nrauhauser at gmail.com Mon Feb 23 12:43:15 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Mon, 23 Feb 2009 12:43:15 -0600 Subject: NANOG in the news In-Reply-To: References: <9515c62d0902231009j7b4eea86kb4e4eee65309cb84@mail.gmail.com> Message-ID: <9515c62d0902231043u5f97ccddu1c62b038c466b618@mail.gmail.com> Whoops - will have to go dig and see if that's my error or the editors. They've wound it up a bit over my reporting ... the audience there is educated but non-technical. On Mon, Feb 23, 2009 at 12:26 PM, Tony Rall wrote: > Very nice. But note that our group's name is "North American Network > Operators' Group" (not "Operations"). > > -- > Tony Rall > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From jbates at brightok.net Mon Feb 23 15:26:06 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 23 Feb 2009 15:26:06 -0600 Subject: ISIS route summarization Message-ID: <49A3146E.30106@brightok.net> In a level2 only ISIS network (not using multiple areas due to MPLS limitations), is there a better method for handling aggregate routes than creating an aggregate and redistributing it into ISIS for each router? Primarily Cisco/Juniper based. Cisco I believe has an aggregate option in ISIS (similar to OSPF) and Juniper has a separate aggregate function which can be distributed into ISIS. Neither can do summarization per say unless they cross between levels; unless I'm mistaken. Offlist input is fine. Just trying to double check my brain while setting up IPv6 on the access edges. Link state does have it's limitations. ;) -Jack From tom at snnap.net Mon Feb 23 17:02:28 2009 From: tom at snnap.net (Tom Storey) Date: Tue, 24 Feb 2009 09:32:28 +1030 (CST) Subject: FW: Ctrl+Shift+6 then X Message-ID: <65459.172.25.144.4.1235430148.squirrel@imap.snnap.net> FWIW Ive rarely had a problem breaking out of ping/traceroute/etc on a Cisco. I have found that Shift-Ctrl, then a very very small delay and 6 (while still holding down Shift-Ctrl) works like a charm every time. Maybe the terminals I use are just more friendly towards that sort of key sequence than others. :-) Though the only thing it doesnt seem to help with is when you have no DNS servers configured and mistype "configt", or some other command that doesnt exist and it tries to resolve it through broadcast several times. Ive found its futile to try and get out of that. Tom > Ye, exact same things happens for me, then after it decides to execute it > you have a nice long line of 6x6x66x6x666x66666, tried the Ctrl+6 no such > luck... > > -----Original Message----- > From: Shon Elliott [mailto:shon at unwiredbb.com] > Sent: Monday, February 23, 2009 10:48 AM > To: nanog at nanog.org >> nanog > Subject: Re: FW: Ctrl+Shift+6 then X > > Bruce, > > I have that problem using any terminal program (I use SecureCRT).. I have > to > bang the command like 10-20 times for the device to recognize it. Kind of > wished > CTRL-C or something worked better and actually worked well. > > > Shon Elliott > Senior Network Engineer > unWired Broadband, Inc. > > > > Bruce Grobler wrote: >> Hi Guys, >> >> >> >> If anyone can tell me how to resolve this issue there's a strong > possibility >> of a fedex'd beer. >> >> >> >> Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 >> then > X >> (on a cisco) works only sometimes after beating your keyboard multiple > times >> with a hammer, has anyone else come across or had a solution to this > problem >> ? >> >> >> >> Regards, >> >> >> >> Bruce Grobler >> >> Yo!Africa - Network Engineer >> >> Landline: +263-4-701300, Cellphone: +263-91-2364532 >> >> Skype ID: bruce.grobler >> >> >> >> > > > From nick at foobar.org Mon Feb 23 17:08:43 2009 From: nick at foobar.org (Nick Hilliard) Date: Mon, 23 Feb 2009 23:08:43 +0000 Subject: FW: Ctrl+Shift+6 then X In-Reply-To: <65459.172.25.144.4.1235430148.squirrel@imap.snnap.net> References: <65459.172.25.144.4.1235430148.squirrel@imap.snnap.net> Message-ID: <49A32C7B.6060700@foobar.org> On 23/02/2009 23:02, Tom Storey wrote: > Though the only thing it doesnt seem to help with is when you have no DNS > servers configured and mistype "configt", or some other command that > doesnt exist and it tries to resolve it through broadcast several times. > Ive found its futile to try and get out of that. line con 0 transport preferred none line vty 0 15 transport preferred none Nick From chris.stebner at gmail.com Mon Feb 23 17:11:15 2009 From: chris.stebner at gmail.com (Chris Stebner) Date: Mon, 23 Feb 2009 23:11:15 +0000 Subject: FW: Ctrl+Shift+6 then X In-Reply-To: <65459.172.25.144.4.1235430148.squirrel@imap.snnap.net> References: <65459.172.25.144.4.1235430148.squirrel@imap.snnap.net> Message-ID: <1994626464-1235430613-cardhu_decombobulator_blackberry.rim.net-919916099-@bxe1161.bisx.prod.on.blackberry> 'No ip domain lookup' will solve your problem instance below. Eg dns resolution attempt on typos. -----Original Message----- From: "Tom Storey" Date: Tue, 24 Feb 2009 09:32:28 To: Bruce Grobler Cc: Subject: RE: FW: Ctrl+Shift+6 then X FWIW Ive rarely had a problem breaking out of ping/traceroute/etc on a Cisco. I have found that Shift-Ctrl, then a very very small delay and 6 (while still holding down Shift-Ctrl) works like a charm every time. Maybe the terminals I use are just more friendly towards that sort of key sequence than others. :-) Though the only thing it doesnt seem to help with is when you have no DNS servers configured and mistype "configt", or some other command that doesnt exist and it tries to resolve it through broadcast several times. Ive found its futile to try and get out of that. Tom > Ye, exact same things happens for me, then after it decides to execute it > you have a nice long line of 6x6x66x6x666x66666, tried the Ctrl+6 no such > luck... > > -----Original Message----- > From: Shon Elliott [mailto:shon at unwiredbb.com] > Sent: Monday, February 23, 2009 10:48 AM > To: nanog at nanog.org >> nanog > Subject: Re: FW: Ctrl+Shift+6 then X > > Bruce, > > I have that problem using any terminal program (I use SecureCRT).. I have > to > bang the command like 10-20 times for the device to recognize it. Kind of > wished > CTRL-C or something worked better and actually worked well. > > > Shon Elliott > Senior Network Engineer > unWired Broadband, Inc. > > > > Bruce Grobler wrote: >> Hi Guys, >> >> >> >> If anyone can tell me how to resolve this issue there's a strong > possibility >> of a fedex'd beer. >> >> >> >> Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 >> then > X >> (on a cisco) works only sometimes after beating your keyboard multiple > times >> with a hammer, has anyone else come across or had a solution to this > problem >> ? >> >> >> >> Regards, >> >> >> >> Bruce Grobler >> >> Yo!Africa - Network Engineer >> >> Landline: +263-4-701300, Cellphone: +263-91-2364532 >> >> Skype ID: bruce.grobler >> >> >> >> > > > From tom at snnap.net Mon Feb 23 17:51:14 2009 From: tom at snnap.net (Tom Storey) Date: Tue, 24 Feb 2009 10:21:14 +1030 (CST) Subject: FW: Ctrl+Shift+6 then X Message-ID: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> Erm, what does that have to do with DNS lookups? :-) > line con 0 > transport preferred none > line vty 0 15 > transport preferred none > > Nick > From tom at snnap.net Mon Feb 23 17:55:04 2009 From: tom at snnap.net (Tom Storey) Date: Tue, 24 Feb 2009 10:25:04 +1030 (CST) Subject: FW: Ctrl+Shift+6 then X Message-ID: <51797.172.25.144.4.1235433304.squirrel@imap.snnap.net> > 'No ip domain lookup' will solve your problem instance below. Eg dns True, but only really useful until you configure the device and it can reach a DNS server, at which point you lose the ability to resolve any hostname, but would be very handy in a lab where DNS is never likely to exist I must say. I might include that into my lab template. :-) From nick at foobar.org Mon Feb 23 18:17:13 2009 From: nick at foobar.org (Nick Hilliard) Date: Tue, 24 Feb 2009 00:17:13 +0000 Subject: FW: Ctrl+Shift+6 then X In-Reply-To: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> References: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> Message-ID: <49A33C89.8060101@foobar.org> On 23/02/2009 23:51, Tom Storey wrote: > Erm, what does that have to do with DNS lookups? :-) Nothing at all, except that it stops this behaviour: > ... when you have no DNS > servers configured and mistype "configt", or some other command that > doesnt exist and it tries to resolve it through broadcast several times. More specifically, IOS command mode will assume by default that any non recognised command is actually a hostname which it should try to connect to - a fossilised relic of times past, when routers were often terminal servers. You can stop it doing this by using "transport preferred none" on the appropriate line configuration. Nick From jmartinez at zero11.com Mon Feb 23 18:36:28 2009 From: jmartinez at zero11.com (John Martinez) Date: Mon, 23 Feb 2009 16:36:28 -0800 Subject: Charter.net email routing issues In-Reply-To: <49A33C89.8060101@foobar.org> References: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> <49A33C89.8060101@foobar.org> Message-ID: <49A3410C.5000207@zero11.com> Is anyone else seeing a high rejection rate from charter.net email clients? From jmartinez at zero11.com Mon Feb 23 19:53:06 2009 From: jmartinez at zero11.com (John Martinez) Date: Mon, 23 Feb 2009 17:53:06 -0800 Subject: Charter.net email routing issues In-Reply-To: <49A350D3.8090907@u13.net> References: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> <49A33C89.8060101@foobar.org> <49A3410C.5000207@zero11.com> <49A350D3.8090907@u13.net> Message-ID: <49A35302.8020004@zero11.com> Yup, I knew that, sorry. Ryan Rawdon wrote: > You may want to try the mailop mailing list, which was created to try > and shift mail operations traffic volume from NANOG: http://www.mailop.org/ > > Good luck with your issue, > Ryan > > John Martinez wrote: >> Is anyone else seeing a high rejection rate from charter.net email >> clients? >> >> >> > From ops.lists at gmail.com Mon Feb 23 20:20:55 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 24 Feb 2009 07:50:55 +0530 Subject: Charter.net email routing issues In-Reply-To: <49A35302.8020004@zero11.com> References: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> <49A33C89.8060101@foobar.org> <49A3410C.5000207@zero11.com> <49A350D3.8090907@u13.net> <49A35302.8020004@zero11.com> Message-ID: Anybody actually on that list? Most of the serious mailops work is on some other, entirely different lists. And why do people have to think nanog is solely for packet pushing related ops? Email is operational, and its often the first ops failure that your users notice, right after the ones that go "I cant get to my pr0n". On Tue, Feb 24, 2009 at 7:23 AM, John Martinez wrote: > Yup, I knew that, sorry. > > Ryan Rawdon wrote: >> You may want to try the mailop mailing list, which was created to try >> and shift mail operations traffic volume from NANOG: http://www.mailop.org/ >> >> Good luck with your issue, >> Ryan From kgasso-lists at visp.net Mon Feb 23 23:44:03 2009 From: kgasso-lists at visp.net (Kameron Gasso) Date: Mon, 23 Feb 2009 21:44:03 -0800 Subject: Charter.net email routing issues In-Reply-To: References: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> <49A33C89.8060101@foobar.org> <49A3410C.5000207@zero11.com> <49A350D3.8090907@u13.net> <49A35302.8020004@zero11.com> Message-ID: <49A38923.2020706@visp.net> Suresh Ramasubramanian wrote: > Anybody actually on that list? Most of the serious mailops work is on > some other, entirely different lists. I followed up to John's message there. We're currently seeing intermittent timeouts when connecting TCP/25 on ib1.charter.net as well as timeouts after the TCP session is established. Thanks, -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From graeme at graemef.net Tue Feb 24 02:02:13 2009 From: graeme at graemef.net (Graeme Fowler) Date: Tue, 24 Feb 2009 08:02:13 +0000 Subject: Charter.net email routing issues In-Reply-To: References: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> <49A33C89.8060101@foobar.org> <49A3410C.5000207@zero11.com> <49A350D3.8090907@u13.net> <49A35302.8020004@zero11.com> Message-ID: <1235462533.29475.7.camel@ernie.internal.graemef.net> Meta: I'm one of the mailop list admins... On Tue, 2009-02-24 at 07:50 +0530, Suresh Ramasubramanian wrote: > Anybody actually on that list? Most of the serious mailops work is on > some other, entirely different lists. There are almost 400 on the list now, and it grows with every single mention here and on other lists. The reason Andy created it was in response to the plethora of "any ISP XYZ mail admins contact me off list" messages NANOG used to see, along with several threads which some posters saw as non-operational. I'd be very pleased to know about the other lists, especially as in previous years I've always come up against brick walls - "you're not big enough, go away" or "we don't know you, go away". Not especially helpful, especially as the latter case would be resolved by allowing more open subscription. > And why do people have to think nanog is solely for packet pushing > related ops? Email is operational, and its often the first ops > failure that your users notice, right after the ones that go "I cant > get to my pr0n". Email is operational, yes. But there are many on NANOG who feel that it isn't, judging by the reaction in the past to long-running threads about it. Graeme From ops.lists at gmail.com Tue Feb 24 02:27:16 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 24 Feb 2009 13:57:16 +0530 Subject: Charter.net email routing issues In-Reply-To: <1235462533.29475.7.camel@ernie.internal.graemef.net> References: <50223.172.25.144.4.1235433074.squirrel@imap.snnap.net> <49A33C89.8060101@foobar.org> <49A3410C.5000207@zero11.com> <49A350D3.8090907@u13.net> <49A35302.8020004@zero11.com> <1235462533.29475.7.camel@ernie.internal.graemef.net> Message-ID: On Tue, Feb 24, 2009 at 1:32 PM, Graeme Fowler wrote: > I'd be very pleased to know about the other lists, especially as in > previous years I've always come up against brick walls - "you're not big > enough, go away" or "we don't know you, go away". Not especially > helpful, especially as the latter case would be resolved by allowing > more open subscription. Yes, that is a problem with vetted communities at some stage or the other of their vetting career. Try asking again, depending on where you asked you might get a different answer now. From bruce at yoafrica.com Tue Feb 24 03:33:14 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Tue, 24 Feb 2009 11:33:14 +0200 Subject: switch speed question In-Reply-To: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> References: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> Message-ID: <003901c99662$eacdff60$c069fe20$@com> Hi, It depends on how heavily loaded your switch is expected to be, for instance two machines using the switch will be able to get a full 1Gbps, however depending on the backplane (switching fabric), it limits how many ports will receive full 1Gbps when the switch is congested, e.g. a 2 gig backplane against a 24 gig. Regards, Bruce -----Original Message----- From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] Sent: Monday, February 23, 2009 5:08 PM To: nanog at nanog.org Subject: switch speed question Hi Can you share your experience what is fastest Gig switch? I see there is CEF feature in cisco. ls it big different when i enable it in switch vs other switch? ls there any problem? Thank you From ip at ioshints.info Tue Feb 24 04:00:44 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 24 Feb 2009 11:00:44 +0100 Subject: ISIS route summarization In-Reply-To: <49A3146E.30106@brightok.net> References: <49A3146E.30106@brightok.net> Message-ID: <001c01c99666$c6dbe460$0a00000a@nil.si> The short answer is "NO". L2 IS-IS is a single SPF domain and all routers are supposed to have identical view of the network. If you want IS-IS-provided aggregation, you need to use L1 and L2. There are only two protocols that allow unlimited levels of aggregation: BGP and EIGRP :) Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Monday, February 23, 2009 10:26 PM > To: nanog at nanog.org > Subject: ISIS route summarization > > In a level2 only ISIS network (not using multiple areas due > to MPLS limitations), is there a better method for handling > aggregate routes than creating an aggregate and > redistributing it into ISIS for each router? Primarily > Cisco/Juniper based. Cisco I believe has an aggregate option > in ISIS (similar to OSPF) and Juniper has a separate > aggregate function which can be distributed into ISIS. > Neither can do summarization per say unless they cross > between levels; unless I'm mistaken. > > Offlist input is fine. Just trying to double check my brain > while setting up IPv6 on the access edges. > > Link state does have it's limitations. ;) > > > -Jack > > > From hank at efes.iucc.ac.il Tue Feb 24 05:05:37 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 24 Feb 2009 13:05:37 +0200 (IST) Subject: Gmail down? Message-ID: -Hank From bortzmeyer at nic.fr Tue Feb 24 05:12:02 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 24 Feb 2009 12:12:02 +0100 Subject: Gmail down? In-Reply-To: References: Message-ID: <20090224111202.GA14750@nic.fr> Indeed, down for me too, from France: % telnet mail.google.com http Trying 72.14.221.19... Connected to googlemail.l.google.com. Escape character is '^]'. GET / HTTP/1.0 Host: mail.google.com [Nothing] From t.bartholdi at msc-gmbh.ch Tue Feb 24 05:12:17 2009 From: t.bartholdi at msc-gmbh.ch (Tobias Bartholdi) Date: Tue, 24 Feb 2009 12:12:17 +0100 Subject: Gmail down? References: <20090224111202.GA14750@nic.fr> Message-ID: yup, down in switzerland too... -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] Sent: Dienstag, 24. Februar 2009 12:12 To: Hank Nussbacher Cc: nanog at nanog.org Subject: Re: Gmail down? Indeed, down for me too, from France: % telnet mail.google.com http Trying 72.14.221.19... Connected to googlemail.l.google.com. Escape character is '^]'. GET / HTTP/1.0 Host: mail.google.com [Nothing] From chrissch at adobe.com Tue Feb 24 05:25:14 2009 From: chrissch at adobe.com (Christian Schmuck) Date: Tue, 24 Feb 2009 11:25:14 +0000 Subject: Gmail down? In-Reply-To: References: <20090224111202.GA14750@nic.fr> Message-ID: <102606650A0D73429AB8133D0F1BE8F10167F26D59@eurmbx01.eur.adobe.com> There is a notice on the Gmail support page (http://mail.google.com/support/): Status Update 2/24/2009 We're aware of a problem with Gmail affecting a number of users. This problem occurred at approximately 1.30AM Pacific Time. We're working hard to resolve this problem and will post updates as we have them. We apologize for any inconvenience that this has caused. Christian Schmuck Data Center and Systems Administrator Adobe Systems Software Ireland Ltd. 4 - 6 Riverwalk Citywest Business Campus Saggart, D24 Ireland +353 1 242 6781 86781 (Internal) christian at adobe.com Adobe Systems Software Ireland Limited Registered office: 4 - 6 Riverwalk, Citywest Business Park, Saggart, Dublin 24 , Ireland?? Company Number: 344992 -----Original Message----- From: Tobias Bartholdi [mailto:t.bartholdi at msc-gmbh.ch] Sent: 24 February 2009 11:12 To: Stephane Bortzmeyer; Hank Nussbacher Cc: nanog at nanog.org Subject: RE: Gmail down? yup, down in switzerland too... -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] Sent: Dienstag, 24. Februar 2009 12:12 To: Hank Nussbacher Cc: nanog at nanog.org Subject: Re: Gmail down? Indeed, down for me too, from France: % telnet mail.google.com http Trying 72.14.221.19... Connected to googlemail.l.google.com. Escape character is '^]'. GET / HTTP/1.0 Host: mail.google.com [Nothing] From netfortius at gmail.com Tue Feb 24 05:52:15 2009 From: netfortius at gmail.com (Stefan) Date: Tue, 24 Feb 2009 05:52:15 -0600 Subject: Gmail down? In-Reply-To: <102606650A0D73429AB8133D0F1BE8F10167F26D59@eurmbx01.eur.adobe.com> References: <20090224111202.GA14750@nic.fr> <102606650A0D73429AB8133D0F1BE8F10167F26D59@eurmbx01.eur.adobe.com> Message-ID: Only account-level failure - same system, using different browsers, going after different accounts - fails one in three. Stefan On Tue, Feb 24, 2009 at 5:25 AM, Christian Schmuck wrote: > There is a notice on the Gmail support page (http://mail.google.com/support/): > > Status Update > 2/24/2009 > We're aware of a problem with Gmail affecting a number of users. This problem occurred at approximately 1.30AM Pacific Time. We're working hard to resolve this problem and will post updates as we have them. We apologize for any inconvenience that this has caused. > > > > Christian Schmuck > Data Center and Systems Administrator > Adobe Systems Software Ireland Ltd. > 4 - 6 Riverwalk > Citywest Business Campus > Saggart, D24 > Ireland > +353 1 242 6781 > 86781 (Internal) > christian at adobe.com > From leothelion.murtaza at gmail.com Tue Feb 24 05:54:55 2009 From: leothelion.murtaza at gmail.com (Murtaza) Date: Tue, 24 Feb 2009 16:54:55 +0500 Subject: Gmail down? In-Reply-To: References: <20090224111202.GA14750@nic.fr> <102606650A0D73429AB8133D0F1BE8F10167F26D59@eurmbx01.eur.adobe.com> Message-ID: <949b74980902240354h1ebcc6e1m462dcf9ff87bd692@mail.gmail.com> Problem was seen here in Pakistan too. But, now its ok as I am sending this email :). On Tue, Feb 24, 2009 at 4:52 PM, Stefan wrote: > Only account-level failure - same system, using different browsers, > going after different accounts - fails one in three. > > Stefan > > On Tue, Feb 24, 2009 at 5:25 AM, Christian Schmuck > wrote: > > There is a notice on the Gmail support page ( > http://mail.google.com/support/): > > > > Status Update > > 2/24/2009 > > We're aware of a problem with Gmail affecting a number of users. This > problem occurred at approximately 1.30AM Pacific Time. We're working hard to > resolve this problem and will post updates as we have them. We apologize for > any inconvenience that this has caused. > > > > > > > > Christian Schmuck > > Data Center and Systems Administrator > > Adobe Systems Software Ireland Ltd. > > 4 - 6 Riverwalk > > Citywest Business Campus > > Saggart, D24 > > Ireland > > +353 1 242 6781 > > 86781 (Internal) > > christian at adobe.com > > > > -- Ghulam Murtaza Lahore University of Management Sciences From tme at multicasttech.com Tue Feb 24 06:16:16 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 24 Feb 2009 07:16:16 -0500 Subject: Gmail down? In-Reply-To: <949b74980902240354h1ebcc6e1m462dcf9ff87bd692@mail.gmail.com> References: <20090224111202.GA14750@nic.fr> <102606650A0D73429AB8133D0F1BE8F10167F26D59@eurmbx01.eur.adobe.com> <949b74980902240354h1ebcc6e1m462dcf9ff87bd692@mail.gmail.com> Message-ID: <94C523A6-BE2A-4714-A86B-3BE4219A962F@multicasttech.com> On Feb 24, 2009, at 6:54 AM, Murtaza wrote: > Problem was seen here in Pakistan too. But, now its ok as I am > sending this > email :). > > On Tue, Feb 24, 2009 at 4:52 PM, Stefan wrote: > >> Only account-level failure - same system, using different browsers, >> going after different accounts - fails one in three. >> Report in the UK Guardian : http://www.guardian.co.uk/media/pda/2009/feb/24/google-email It is not coming up for me, BTW. Regards Marshall >> Stefan >> >> On Tue, Feb 24, 2009 at 5:25 AM, Christian Schmuck > > >> wrote: >>> There is a notice on the Gmail support page ( >> http://mail.google.com/support/): >>> >>> Status Update >>> 2/24/2009 >>> We're aware of a problem with Gmail affecting a number of users. >>> This >> problem occurred at approximately 1.30AM Pacific Time. We're >> working hard to >> resolve this problem and will post updates as we have them. We >> apologize for >> any inconvenience that this has caused. >>> >>> >>> >>> Christian Schmuck >>> Data Center and Systems Administrator >>> Adobe Systems Software Ireland Ltd. >>> 4 - 6 Riverwalk >>> Citywest Business Campus >>> Saggart, D24 >>> Ireland >>> +353 1 242 6781 >>> 86781 (Internal) >>> christian at adobe.com >>> >> >> > > > -- > Ghulam Murtaza > Lahore University of Management Sciences From svan at redbrick.dcu.ie Tue Feb 24 06:16:54 2009 From: svan at redbrick.dcu.ie (Sarunas Vancevicius) Date: Tue, 24 Feb 2009 12:16:54 +0000 Subject: Gmail down? In-Reply-To: References: <20090224111202.GA14750@nic.fr> Message-ID: <20090224121654.GA21158@minerva.redbrick.dcu.ie> The web interface is down in Ireland too. But IMAP access is working fine. On 12:12, Tue 24 Feb 09, Tobias Bartholdi wrote: > yup, down in switzerland too... > > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] > Sent: Dienstag, 24. Februar 2009 12:12 > To: Hank Nussbacher > Cc: nanog at nanog.org > Subject: Re: Gmail down? > > Indeed, down for me too, from France: > > % telnet mail.google.com http > Trying 72.14.221.19... > Connected to googlemail.l.google.com. > Escape character is '^]'. > GET / HTTP/1.0 > Host: mail.google.com > > > [Nothing] > > > > > From luigi at net.t-labs.tu-berlin.de Tue Feb 24 07:06:12 2009 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Tue, 24 Feb 2009 14:06:12 +0100 Subject: Gmail down? In-Reply-To: <20090224121654.GA21158@minerva.redbrick.dcu.ie> References: <20090224111202.GA14750@nic.fr> <20090224121654.GA21158@minerva.redbrick.dcu.ie> Message-ID: In Germany was down as well, but now works fine again. Luigi On Feb 24, 2009, at 13:16 , Sarunas Vancevicius wrote: > The web interface is down in Ireland too. > But IMAP access is working fine. > > On 12:12, Tue 24 Feb 09, Tobias Bartholdi wrote: >> yup, down in switzerland too... >> >> -----Original Message----- >> From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] >> Sent: Dienstag, 24. Februar 2009 12:12 >> To: Hank Nussbacher >> Cc: nanog at nanog.org >> Subject: Re: Gmail down? >> >> Indeed, down for me too, from France: >> >> % telnet mail.google.com http >> Trying 72.14.221.19... >> Connected to googlemail.l.google.com. >> Escape character is '^]'. >> GET / HTTP/1.0 >> Host: mail.google.com >> >> >> [Nothing] >> >> >> >> >> > From mailinglists at uebi.net Tue Feb 24 07:11:44 2009 From: mailinglists at uebi.net (Bernd) Date: Tue, 24 Feb 2009 14:11:44 +0100 Subject: Gmail down? In-Reply-To: References: <20090224111202.GA14750@nic.fr> <20090224121654.GA21158@minerva.redbrick.dcu.ie> Message-ID: <006b01c99681$75b280b0$61178210$@net> I guess gmail is working everywhere on the globe again. We encountered the same problems here in Austria (web, imap was working all the time), too, but everything seems to be fine at the moment. Greets from the snowy Tyrol, Bernd -----Original Message----- From: Luigi Iannone [mailto:luigi at net.t-labs.tu-berlin.de] Sent: Dienstag, 24. Februar 2009 14:06 Cc: nanog at nanog.org Subject: Re: Gmail down? In Germany was down as well, but now works fine again. Luigi On Feb 24, 2009, at 13:16 , Sarunas Vancevicius wrote: > The web interface is down in Ireland too. > But IMAP access is working fine. > > On 12:12, Tue 24 Feb 09, Tobias Bartholdi wrote: >> yup, down in switzerland too... >> >> -----Original Message----- >> From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] >> Sent: Dienstag, 24. Februar 2009 12:12 >> To: Hank Nussbacher >> Cc: nanog at nanog.org >> Subject: Re: Gmail down? >> >> Indeed, down for me too, from France: >> >> % telnet mail.google.com http >> Trying 72.14.221.19... >> Connected to googlemail.l.google.com. >> Escape character is '^]'. >> GET / HTTP/1.0 >> Host: mail.google.com >> >> >> [Nothing] >> >> >> >> >> > From jbates at brightok.net Tue Feb 24 07:28:59 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 24 Feb 2009 07:28:59 -0600 Subject: ISIS route summarization (it's a wrap) In-Reply-To: <49A3146E.30106@brightok.net> References: <49A3146E.30106@brightok.net> Message-ID: <49A3F61B.9020007@brightok.net> People were nice to point out that my memory does function correctly, but I did receive a single suggestion to spark the fire back to life in my brain. The suggestion was ISIS for infrastructure only, and iBGP for carrying all customer routes, which will lower the ISIS costs during a state change and give aggregation abilities at any level (useful for IPv4 primarily while we finish up adding IPv6). Thanks for the help. Life slowly returns to normal in Lone Grove, OK, but it's amazing how much a tornado takes out of you; even when it doesn't take your IP network down. Jack Jack Bates wrote: > In a level2 only ISIS network (not using multiple areas due to MPLS > limitations), is there a better method for handling aggregate routes > than creating an aggregate and redistributing it into ISIS for each > router? Primarily Cisco/Juniper based. Cisco I believe has an aggregate > option in ISIS (similar to OSPF) and Juniper has a separate aggregate > function which can be distributed into ISIS. Neither can do > summarization per say unless they cross between levels; unless I'm > mistaken. > > Offlist input is fine. Just trying to double check my brain while > setting up IPv6 on the access edges. > > Link state does have it's limitations. ;) > > > -Jack > From hrlinneweh at sbcglobal.net Tue Feb 24 08:24:58 2009 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Tue, 24 Feb 2009 06:24:58 -0800 (PST) Subject: Gmail down? References: <20090224111202.GA14750@nic.fr> <20090224121654.GA21158@minerva.redbrick.dcu.ie> <006b01c99681$75b280b0$61178210$@net> Message-ID: <956904.77833.qm@web82901.mail.mud.yahoo.com> Status Update 2/24/2009 Many of our users had difficulty accessing Gmail today. The problem is now resolved and users have had access restored. We know how important Gmail is to our users, so we take issues like this very seriously, and we apologize for the inconvenience. -henry ? ________________________________ From: Bernd To: nanog at nanog.org Sent: Tuesday, February 24, 2009 5:11:44 AM Subject: RE: Gmail down? I guess gmail is working everywhere on the globe again. We encountered the same problems here in Austria (web, imap was working all the time), too, but everything seems to be fine at the moment. Greets from the snowy Tyrol, Bernd -----Original Message----- From: Luigi Iannone [mailto:luigi at net.t-labs.tu-berlin.de] Sent: Dienstag, 24. Februar 2009 14:06 Cc: nanog at nanog.org Subject: Re: Gmail down? In Germany was down as well, but now works fine again. Luigi On Feb 24, 2009, at 13:16 , Sarunas Vancevicius wrote: > The web interface is down in Ireland too. > But IMAP access is working fine. > > On 12:12, Tue 24 Feb 09, Tobias Bartholdi wrote: >> yup, down in switzerland too... >> >> -----Original Message----- >> From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] >> Sent: Dienstag, 24. Februar 2009 12:12 >> To: Hank Nussbacher >> Cc: nanog at nanog.org >> Subject: Re: Gmail down? >> >> Indeed, down for me too, from France: >> >> % telnet mail.google.com http >> Trying 72.14.221.19... >> Connected to googlemail.l.google.com. >> Escape character is '^]'. >> GET / HTTP/1.0 >> Host: mail.google.com >> >> >> [Nothing] >> >> >> >> >> > From mhuff at ox.com Tue Feb 24 08:48:46 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 24 Feb 2009 09:48:46 -0500 Subject: Illegal header length in BGP error In-Reply-To: <49A3F61B.9020007@brightok.net> References: <49A3146E.30106@brightok.net> <49A3F61B.9020007@brightok.net> Message-ID: <483E6B0272B0284BA86D7596C40D29F9B5BB3DC52F@PUR-EXCH07.ox.com> One of our upstream providers flapped this morning, and since then they are sending corrupted BPG data. I'm running 12.4(22)T on cisco 7200s. I'm getting no BGP errors from that providers and the number of routes and basic sanity check looks okay. However, when it tries to redistribute the bgp routes via iBGP to our other board routers, we get: 003372: Feb 24 09:17:13.963 EST: %BGP-5-ADJCHANGE: neighbor x.x.x.x Down BGP Notification sent 003373: Feb 24 09:17:13.963 EST: %BGP-3-NOTIFICATION: sent to neighbor x.x.x.x 1/2 (illegal header length) 2 bytes All routes have identical hardware and IOS versions. My google and cisco search fu leads me to the AS path length bug, but the interesting thing is that since we have "bgp maxas-limit 75" configured and a recent IOS, we haven't had the problem before when other people were reporting issues. I've also looked at the path mtu issue, and although we haven't had a problem before I disabled bgp mtu path discovery, but have the same issues. Anyone seeing something like this today, and or does anyone have a suggestion on finding out more specific info (which as path for example so I can filter it)? ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From renaud at rakotomalala.com Tue Feb 24 09:48:56 2009 From: renaud at rakotomalala.com (Renaud RAKOTOMALALA) Date: Tue, 24 Feb 2009 16:48:56 +0100 Subject: Illegal header length in BGP error In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9B5BB3DC52F@PUR-EXCH07.ox.com> References: <49A3146E.30106@brightok.net> <49A3F61B.9020007@brightok.net> <483E6B0272B0284BA86D7596C40D29F9B5BB3DC52F@PUR-EXCH07.ox.com> Message-ID: <49A416E8.2000508@rakotomalala.com> Hello Matthew, We changed the motherboard from cisco one of our from 7206VXR (NPE-G1) to 7206VXR (NPE-G2). Due to incompability with the IOS 12.3(4r)T3 we upgraded this IOS to 12.4(12.2r)T. At the end we've got the same problem as you between one of our 7200 in 12.3 and the new one in 12.4 .... We solved the problem by upgrading the cisco withe the IOS from 12.4(12.2r) to 12.4(4)XD10 and the BGP session came back alive .... So now everything work fine between our 7200 (IOS 12.3) and the other 7200 in IOS 12.4(4)XD10 I hope it could help you ... Cheers, Renaud Matthew Huff a ?crit : > One of our upstream providers flapped this morning, and since then they are > sending corrupted BPG data. I'm running 12.4(22)T on cisco 7200s. I'm > getting no BGP errors from that providers and the number of routes and basic > sanity check looks okay. However, when it tries to redistribute the bgp > routes via iBGP to our other board routers, we get: > > 003372: Feb 24 09:17:13.963 EST: %BGP-5-ADJCHANGE: neighbor x.x.x.x Down BGP > Notification sent > 003373: Feb 24 09:17:13.963 EST: %BGP-3-NOTIFICATION: sent to neighbor > x.x.x.x 1/2 (illegal header length) 2 bytes > > > All routes have identical hardware and IOS versions. My google and cisco > search fu leads me to the AS path length bug, but the interesting thing is > that since we have "bgp maxas-limit 75" configured and a recent IOS, we > haven't had the problem before when other people were reporting issues. I've > also looked at the path mtu issue, and although we haven't had a problem > before I disabled bgp mtu path discovery, but have the same issues. > > Anyone seeing something like this today, and or does anyone have a > suggestion on finding out more specific info (which as path for example so I > can filter it)? > From mhuff at ox.com Tue Feb 24 09:50:14 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 24 Feb 2009 10:50:14 -0500 Subject: Illegal header length in BGP error In-Reply-To: <49A416E8.2000508@rakotomalala.com> References: <49A3146E.30106@brightok.net> <49A3F61B.9020007@brightok.net> <483E6B0272B0284BA86D7596C40D29F9B5BB3DC52F@PUR-EXCH07.ox.com> <49A416E8.2000508@rakotomalala.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9B5BB3DC533@PUR-EXCH07.ox.com> Yep, got a reply from cisco. It's a cisco bug: " CSCsj36133 Internally found severe defect: Resolved (R) Invalid header length BGP notification when sending withdraw The router that is running the affected software generates enough withdraws to fill an entire BGP update message and can generate an update message that is 1 or 2 bytes too large when formatting withdraws close to the 4096 size boundary. The error message you attached to the service request indicates that you're receiving the BGP update with the illegal header length from the provider, correct? This issue was caused when new features were introduced into the 12.4(20)T train. The fix has been integrated into 12.4(20)T2 and will also be integrated into 12.4(24)T, when it is released on CCO. The 12.4(15)T train is unaffected. So the affected routers could also safely move to the latest 12.4(15)T image." ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Renaud RAKOTOMALALA [mailto:renaud at rakotomalala.com] > Sent: Tuesday, February 24, 2009 10:49 AM > To: Matthew Huff; 'nanog at nanog.org' > Subject: Re: Illegal header length in BGP error > > Hello Matthew, > > We changed the motherboard from cisco one of our from 7206VXR (NPE-G1) > to 7206VXR (NPE-G2). > > Due to incompability with the IOS 12.3(4r)T3 we upgraded this IOS to > 12.4(12.2r)T. At the end we've got the same problem as you between one > of our 7200 in 12.3 and the new one in 12.4 .... > > We solved the problem by upgrading the cisco withe the IOS from > 12.4(12.2r) to 12.4(4)XD10 and the BGP session came back alive .... > > So now everything work fine between our 7200 (IOS 12.3) and the other > 7200 in IOS 12.4(4)XD10 > > I hope it could help you ... > > Cheers, > Renaud > > > Matthew Huff a ?crit : > > One of our upstream providers flapped this morning, and since then > they are > > sending corrupted BPG data. I'm running 12.4(22)T on cisco 7200s. I'm > > getting no BGP errors from that providers and the number of routes > and basic > > sanity check looks okay. However, when it tries to redistribute the > bgp > > routes via iBGP to our other board routers, we get: > > > > 003372: Feb 24 09:17:13.963 EST: %BGP-5-ADJCHANGE: neighbor x.x.x.x > Down BGP > > Notification sent > > 003373: Feb 24 09:17:13.963 EST: %BGP-3-NOTIFICATION: sent to > neighbor > > x.x.x.x 1/2 (illegal header length) 2 bytes > > > > > > All routes have identical hardware and IOS versions. My google and > cisco > > search fu leads me to the AS path length bug, but the interesting > thing is > > that since we have "bgp maxas-limit 75" configured and a recent IOS, > we > > haven't had the problem before when other people were reporting > issues. I've > > also looked at the path mtu issue, and although we haven't had a > problem > > before I disabled bgp mtu path discovery, but have the same issues. > > > > Anyone seeing something like this today, and or does anyone have a > > suggestion on finding out more specific info (which as path for > example so I > > can filter it)? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From eric at nixwizard.net Tue Feb 24 09:51:12 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Tue, 24 Feb 2009 08:51:12 -0700 Subject: switch speed question In-Reply-To: <003901c99662$eacdff60$c069fe20$@com> References: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> <003901c99662$eacdff60$c069fe20$@com> Message-ID: <5792267e0902240751w2021e473k33f02acd5acb4304@mail.gmail.com> On Tue, Feb 24, 2009 at 2:33 AM, Bruce Grobler wrote: > Hi, > > It depends on how heavily loaded your switch is expected to be, for instance > two machines using the switch will be able to get a full 1Gbps, however > depending on the backplane (switching fabric), it limits how many ports will > receive full 1Gbps when the switch is congested, e.g. a 2 gig backplane > against a 24 gig. > > Regards, > > Bruce Note that the traffic to a switch is bi-directional (full duplex) - so a 24 port gigabit switch can max out its 32 Gig backplane, if all 24 ports have a gig coming in and going out (24 X 2 is 48, more than the 32 gig backplane). This isn't immediately apparent - the other day someone at my work asked the exact question "Why's the 32 gig backplane > the 24 ports on the switch?" -- Eric http://nixwizard.net From cmills at accessdc.com Tue Feb 24 09:53:56 2009 From: cmills at accessdc.com (Mills, Charles) Date: Tue, 24 Feb 2009 10:53:56 -0500 Subject: Illegal header length in BGP error In-Reply-To: <49A416E8.2000508@rakotomalala.com> References: <49A3146E.30106@brightok.net> <49A3F61B.9020007@brightok.net><483E6B0272B0284BA86D7596C40D29F9B5BB3DC52F@PUR-EXCH07.ox.com> <49A416E8.2000508@rakotomalala.com> Message-ID: <58E0B21FC367B24485855A1DBD96B0BB11C056DD@adc-prd-exch1.internal.accessdc.com> I ran into exactly the same thing during a code upgrade a few weeks ago. I wrote it off as a bug in BGP and backed off the code until a new release was out. I was also running 12.4(22)T On an NPE-G2. Chuck -----Original Message----- From: Renaud RAKOTOMALALA [mailto:renaud at rakotomalala.com] Sent: Tuesday, February 24, 2009 10:49 AM To: Matthew Huff; 'nanog at nanog.org' Subject: Re: Illegal header length in BGP error Hello Matthew, We changed the motherboard from cisco one of our from 7206VXR (NPE-G1) to 7206VXR (NPE-G2). Due to incompability with the IOS 12.3(4r)T3 we upgraded this IOS to 12.4(12.2r)T. At the end we've got the same problem as you between one of our 7200 in 12.3 and the new one in 12.4 .... We solved the problem by upgrading the cisco withe the IOS from 12.4(12.2r) to 12.4(4)XD10 and the BGP session came back alive .... So now everything work fine between our 7200 (IOS 12.3) and the other 7200 in IOS 12.4(4)XD10 I hope it could help you ... Cheers, Renaud Matthew Huff a ?crit : > One of our upstream providers flapped this morning, and since then they are > sending corrupted BPG data. I'm running 12.4(22)T on cisco 7200s. I'm > getting no BGP errors from that providers and the number of routes and basic > sanity check looks okay. However, when it tries to redistribute the bgp > routes via iBGP to our other board routers, we get: > > 003372: Feb 24 09:17:13.963 EST: %BGP-5-ADJCHANGE: neighbor x.x.x.x Down BGP > Notification sent > 003373: Feb 24 09:17:13.963 EST: %BGP-3-NOTIFICATION: sent to neighbor > x.x.x.x 1/2 (illegal header length) 2 bytes > > > All routes have identical hardware and IOS versions. My google and cisco > search fu leads me to the AS path length bug, but the interesting thing is > that since we have "bgp maxas-limit 75" configured and a recent IOS, we > haven't had the problem before when other people were reporting issues. I've > also looked at the path mtu issue, and although we haven't had a problem > before I disabled bgp mtu path discovery, but have the same issues. > > Anyone seeing something like this today, and or does anyone have a > suggestion on finding out more specific info (which as path for example so I > can filter it)? > This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From tvarriale at comcast.net Tue Feb 24 10:04:36 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Tue, 24 Feb 2009 10:04:36 -0600 Subject: switch speed question References: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com><003901c99662$eacdff60$c069fe20$@com> <5792267e0902240751w2021e473k33f02acd5acb4304@mail.gmail.com> Message-ID: <1564C550DE704D4CAC755EBFD24C96F7@flamdt01> That isn't always true. Some switches are already speced as full. It's best to read the product docs or speak with a rep to be sure. tv ----- Original Message ----- From: "Eric Gearhart" To: "NANOG list" Sent: Tuesday, February 24, 2009 9:51 AM Subject: Re: switch speed question > On Tue, Feb 24, 2009 at 2:33 AM, Bruce Grobler wrote: >> Hi, >> >> It depends on how heavily loaded your switch is expected to be, for >> instance >> two machines using the switch will be able to get a full 1Gbps, however >> depending on the backplane (switching fabric), it limits how many ports >> will >> receive full 1Gbps when the switch is congested, e.g. a 2 gig backplane >> against a 24 gig. >> >> Regards, >> >> Bruce > > Note that the traffic to a switch is bi-directional (full duplex) - so > a 24 port gigabit switch can max out its 32 Gig backplane, if all 24 > ports have a gig coming in and going out (24 X 2 is 48, more than the > 32 gig backplane). > > This isn't immediately apparent - the other day someone at my work > asked the exact question "Why's the 32 gig backplane > the 24 ports on > the switch?" > > -- > Eric > http://nixwizard.net > From dholmes at mwdh2o.com Tue Feb 24 11:03:33 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 24 Feb 2009 09:03:33 -0800 Subject: switch speed question In-Reply-To: <003901c99662$eacdff60$c069fe20$@com> References: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> <003901c99662$eacdff60$c069fe20$@com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0877F3C6@usmsxt104.mwd.h2o> Arista claims to have the fastest 1/10 Gig 24 and 48 port 1RU switch, with a backplane capacity guaranteeing 10 Gig full duplex line rate per port. Cisco's CEF is local only and functions to download the arp cache and routing table into ASICs for hardware switching; but look at Cisco's NSF/SSO for cases where adjacent devices are all defined in the same packet forwarding state machine. -----Original Message----- From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] Sent: Monday, February 23, 2009 5:08 PM To: nanog at nanog.org Subject: switch speed question Hi Can you share your experience what is fastest Gig switch? I see there is CEF feature in cisco. ls it big different when i enable it in switch vs other switch? ls there any problem? Thank you From r.engehausen at gmail.com Tue Feb 24 11:15:24 2009 From: r.engehausen at gmail.com (Roy) Date: Tue, 24 Feb 2009 09:15:24 -0800 Subject: switch speed question In-Reply-To: <5792267e0902240751w2021e473k33f02acd5acb4304@mail.gmail.com> References: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> <003901c99662$eacdff60$c069fe20$@com> <5792267e0902240751w2021e473k33f02acd5acb4304@mail.gmail.com> Message-ID: <49A42B2C.1040507@gmail.com> Eric Gearhart wrote: > .... > > Note that the traffic to a switch is bi-directional (full duplex) - so > a 24 port gigabit switch can max out its 32 Gig backplane, if all 24 > ports have a gig coming in and going out (24 X 2 is 48, more than the > 32 gig backplane). > > .... > I think your math is faulty. While there may be 24G going in and 24G going out, there is only 24G crossing the backplane. You can't count a bit twice (once on in and once on out). Its the same bit. From cmadams at hiwaay.net Tue Feb 24 11:25:28 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 24 Feb 2009 11:25:28 -0600 Subject: switch speed question In-Reply-To: <49A42B2C.1040507@gmail.com> References: <40d8a95a0902230708p3d53ec83qf5ed31c564f05825@mail.gmail.com> <003901c99662$eacdff60$c069fe20$@com> <5792267e0902240751w2021e473k33f02acd5acb4304@mail.gmail.com> <49A42B2C.1040507@gmail.com> Message-ID: <20090224172528.GM1315887@hiwaay.net> Once upon a time, Roy said: > I think your math is faulty. While there may be 24G going in and 24G > going out, there is only 24G crossing the backplane. You can't count a > bit twice (once on in and once on out). Its the same bit. Not every bit in results in just one bit out. Broadcast, multicast, flooding for unknown MACs (or switching failures), ... -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From paul.cosgrove at heanet.ie Tue Feb 24 11:26:13 2009 From: paul.cosgrove at heanet.ie (Paul Cosgrove) Date: Tue, 24 Feb 2009 17:26:13 +0000 Subject: Illegal header length in BGP error In-Reply-To: <58E0B21FC367B24485855A1DBD96B0BB11C056DD@adc-prd-exch1.internal.accessdc.com> References: <49A3146E.30106@brightok.net> <49A3F61B.9020007@brightok.net><483E6B0272B0284BA86D7596C40D29F9B5BB3DC52F@PUR-EXCH07.ox.com> <49A416E8.2000508@rakotomalala.com> <58E0B21FC367B24485855A1DBD96B0BB11C056DD@adc-prd-exch1.internal.accessdc.com> Message-ID: <49A42DB5.9050003@heanet.ie> Are you using PMTUD? We saw this on a couple of our route reflectors and on one occasion picked it up in a capture. So I can say that the issue is due to bad packets being sent, rather than an inaccurate error. It can be reported differently according to where the corruption occurs (e.g. unsupported message type, update malformed etc.). Two production BGP sessions were affected at different times, and one showed errors every few days, the other weeks apart. Both sessions were from route reflectors to other routers receiving full tables, and both traversed multiple hops. All other sessions of these routers were fine. Whilst investigating we identified that different MTUs were being used on the device interfaces at each end of the sessions. The session on which we saw most errors also had lower MTUs on intervening links, so PMTUD was suspected to be a factor. I replaced one of the paths with a direct link, using identical MTUs, and that stopped the errors on that session (since PMTUD had nothing to do anymore). Just to be sure we recreated a multiple hop topology from our production route reflectors to isolated lab routers, with low intervening link MTUs and ACLs to keep out other unwanted traffic - which also produced the same error on those sessions (but only once each over three months). After correcting all the MTUs in the production network the errors ceased completely. Our test routers shared these links, but also used an additional link with a low mtu which we deliberately did not fix; as it turned out we not see it again there either so the trigger was not entirely clear. One other thing to note is that, at the time, we were seeing some other problems with these production routers, whichcisco believed may have been due to SNMP polling of BGP stats. If you have been changing that recently I would also consider it a possibility. Paul. Mills, Charles wrote: > I ran into exactly the same thing during a code upgrade a few weeks ago. > > I wrote it off as a bug in BGP and backed off the code until a new release was out. I was also running 12.4(22)T > On an NPE-G2. > > Chuck > > -----Original Message----- > From: Renaud RAKOTOMALALA [mailto:renaud at rakotomalala.com] > Sent: Tuesday, February 24, 2009 10:49 AM > To: Matthew Huff; 'nanog at nanog.org' > Subject: Re: Illegal header length in BGP error > > Hello Matthew, > > We changed the motherboard from cisco one of our from 7206VXR (NPE-G1) > to 7206VXR (NPE-G2). > > Due to incompability with the IOS 12.3(4r)T3 we upgraded this IOS to > 12.4(12.2r)T. At the end we've got the same problem as you between one > of our 7200 in 12.3 and the new one in 12.4 .... > > We solved the problem by upgrading the cisco withe the IOS from > 12.4(12.2r) to 12.4(4)XD10 and the BGP session came back alive .... > > So now everything work fine between our 7200 (IOS 12.3) and the other > 7200 in IOS 12.4(4)XD10 > > I hope it could help you ... > > Cheers, > Renaud > > > Matthew Huff a ?crit : > >> One of our upstream providers flapped this morning, and since then they are >> sending corrupted BPG data. I'm running 12.4(22)T on cisco 7200s. I'm >> getting no BGP errors from that providers and the number of routes and basic >> sanity check looks okay. However, when it tries to redistribute the bgp >> routes via iBGP to our other board routers, we get: >> >> 003372: Feb 24 09:17:13.963 EST: %BGP-5-ADJCHANGE: neighbor x.x.x.x Down BGP >> Notification sent >> 003373: Feb 24 09:17:13.963 EST: %BGP-3-NOTIFICATION: sent to neighbor >> x.x.x.x 1/2 (illegal header length) 2 bytes >> >> >> All routes have identical hardware and IOS versions. My google and cisco >> search fu leads me to the AS path length bug, but the interesting thing is >> that since we have "bgp maxas-limit 75" configured and a recent IOS, we >> haven't had the problem before when other people were reporting issues. I've >> also looked at the path mtu issue, and although we haven't had a problem >> before I disabled bgp mtu path discovery, but have the same issues. >> >> Anyone seeing something like this today, and or does anyone have a >> suggestion on finding out more specific info (which as path for example so I >> can filter it)? >> >> > > > > This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. > Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. > > > > > From mhuff at ox.com Tue Feb 24 11:29:29 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 24 Feb 2009 12:29:29 -0500 Subject: Illegal header length in BGP error In-Reply-To: <49A42DB5.9050003@heanet.ie> References: <49A3146E.30106@brightok.net> <49A3F61B.9020007@brightok.net><483E6B0272B0284BA86D7596C40D29F9B5BB3DC52F@PUR-EXCH07.ox.com> <49A416E8.2000508@rakotomalala.com> <58E0B21FC367B24485855A1DBD96B0BB11C056DD@adc-prd-exch1.internal.accessdc.com> <49A42DB5.9050003@heanet.ie> Message-ID: <483E6B0272B0284BA86D7596C40D29F9B5BB3DC539@PUR-EXCH07.ox.com> We were using PMTUD. However: 1) The link was iBGP and was done via crossever with both having default MTU 2) I tried disabling PMTUD with no difference 3) Cisco admitted it was a known bug, and downreving it to 12.4(15)T resolved the issue. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Paul Cosgrove [mailto:paul.cosgrove at heanet.ie] > Sent: Tuesday, February 24, 2009 12:26 PM > To: Mills, Charles > Cc: Renaud RAKOTOMALALA; Matthew Huff; nanog at nanog.org > Subject: Re: Illegal header length in BGP error > > Are you using PMTUD? > > We saw this on a couple of our route reflectors and on one occasion > picked it up in a capture. So I can say that the issue is due to bad > packets being sent, rather than an inaccurate error. It can be > reported > differently according to where the corruption occurs (e.g. unsupported > message type, update malformed etc.). > > Two production BGP sessions were affected at different times, and one > showed errors every few days, the other weeks apart. Both sessions > were > from route reflectors to other routers receiving full tables, and both > traversed multiple hops. All other sessions of these routers were fine. > Whilst investigating we identified that different MTUs were being used > on the device interfaces at each end of the sessions. The session on > which we saw most errors also had lower MTUs on intervening links, so > PMTUD was suspected to be a factor. > > I replaced one of the paths with a direct link, using identical MTUs, > and that stopped the errors on that session (since PMTUD had nothing to > do anymore). Just to be sure we recreated a multiple hop topology from > our production route reflectors to isolated lab routers, with low > intervening link MTUs and ACLs to keep out other unwanted traffic - > which also produced the same error on those sessions (but only once > each > over three months). > > After correcting all the MTUs in the production network the errors > ceased completely. Our test routers shared these links, but also used > an additional link with a low mtu which we deliberately did not fix; as > it turned out we not see it again there either so the trigger was not > entirely clear. > > One other thing to note is that, at the time, we were seeing some other > problems with these production routers, whichcisco believed may have > been due to SNMP polling of BGP stats. If you have been changing that > recently I would also consider it a possibility. > > Paul. > > > > Mills, Charles wrote: > > I ran into exactly the same thing during a code upgrade a few weeks > ago. > > > > I wrote it off as a bug in BGP and backed off the code until a new > release was out. I was also running 12.4(22)T > > On an NPE-G2. > > > > Chuck > > > > -----Original Message----- > > From: Renaud RAKOTOMALALA [mailto:renaud at rakotomalala.com] > > Sent: Tuesday, February 24, 2009 10:49 AM > > To: Matthew Huff; 'nanog at nanog.org' > > Subject: Re: Illegal header length in BGP error > > > > Hello Matthew, > > > > We changed the motherboard from cisco one of our from 7206VXR (NPE- > G1) > > to 7206VXR (NPE-G2). > > > > Due to incompability with the IOS 12.3(4r)T3 we upgraded this IOS to > > 12.4(12.2r)T. At the end we've got the same problem as you between > one > > of our 7200 in 12.3 and the new one in 12.4 .... > > > > We solved the problem by upgrading the cisco withe the IOS from > > 12.4(12.2r) to 12.4(4)XD10 and the BGP session came back alive .... > > > > So now everything work fine between our 7200 (IOS 12.3) and the other > > 7200 in IOS 12.4(4)XD10 > > > > I hope it could help you ... > > > > Cheers, > > Renaud > > > > > > Matthew Huff a ?crit : > > > >> One of our upstream providers flapped this morning, and since then > they are > >> sending corrupted BPG data. I'm running 12.4(22)T on cisco 7200s. > I'm > >> getting no BGP errors from that providers and the number of routes > and basic > >> sanity check looks okay. However, when it tries to redistribute the > bgp > >> routes via iBGP to our other board routers, we get: > >> > >> 003372: Feb 24 09:17:13.963 EST: %BGP-5-ADJCHANGE: neighbor x.x.x.x > Down BGP > >> Notification sent > >> 003373: Feb 24 09:17:13.963 EST: %BGP-3-NOTIFICATION: sent to > neighbor > >> x.x.x.x 1/2 (illegal header length) 2 bytes > >> > >> > >> All routes have identical hardware and IOS versions. My google and > cisco > >> search fu leads me to the AS path length bug, but the interesting > thing is > >> that since we have "bgp maxas-limit 75" configured and a recent IOS, > we > >> haven't had the problem before when other people were reporting > issues. I've > >> also looked at the path mtu issue, and although we haven't had a > problem > >> before I disabled bgp mtu path discovery, but have the same issues. > >> > >> Anyone seeing something like this today, and or does anyone have a > >> suggestion on finding out more specific info (which as path for > example so I > >> can filter it)? > >> > >> > > > > > > > > This e-mail message and any files transmitted with it contain > confidential information intended only for the person(s) to whom this > email message is addressed. If you have received this e-mail message in > error, please notify the sender immediately by telephone or e-mail and > destroy the original message without making a copy. Thank you. > > Neither this information block, the typed name of the sender, nor > anything else in this message is intended to constitute an electronic > signature unless a specific statement to the contrary is included in > this message. > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From crpopovi at nauticom.net Tue Feb 24 12:30:07 2009 From: crpopovi at nauticom.net (Clinton Popovich) Date: Tue, 24 Feb 2009 13:30:07 -0500 Subject: Routing issue to Lunarpages/California Regional Internet Message-ID: <200902241830.n1OIU7xL032950@outbound.mail.nauticom.net> Does anyone have a contact for either of these two companies, we are seeing some routing issues somewhere on their network and would like to contact their network engineers. I have tired all contacts listed on their whois as well as their general support phone number to no avail. 67.210.117.26 = Lunar Pages 74.50.25.3 = Lunar Pages 74.50.26.3 = Lunar Pages 67.210.126.125 = Lunar Pages 216.75.16.199 = California Regional Intranet, Inc. 216.75.16.207 = California Regional Intranet, Inc. 66.240.211.13 = California Regional Intranet, Inc. Lunar Pages RTechHandle: LNTS1-ARIN RTechName: Lunarpages NOC Technical Support RTechPhone: +1-877-586-2772 RTechEmail: hostmaster at lunarpages.com California Regional Intranet, Inc. RTechHandle: IC63-ARIN RTechName: System Administration RTechPhone: +1-858-974-5080 RTechEmail: sysadmin at cari.net Clinton Popovich Systems Engineer Consolidated Communications Gibsonia Pa, 15044 Clint.popovich at consolidated.com From chair at pc.nanog.org Tue Feb 24 12:59:17 2009 From: chair at pc.nanog.org (Todd Underwood) Date: Tue, 24 Feb 2009 13:59:17 -0500 Subject: [NANOG-announce] NANOG 46 Call for Presentations Message-ID: <65b1fd2e0902241059y5d06d30agaefb35110c3e6b11@mail.gmail.com> NANOG 46 Call for Presentations ============================== The North American Network Operators' Group (NANOG) will hold its 46th meeting June 14-17, 2009 in Philadelphia, Pennsylvania. NANOG 46 will be hosted by Comcast. The NANOG Program Committee is now seeking proposals for Presentations, Panels, Tutorials, and Birds of a Feather sessions (BOFs) for the NANOG46 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet. Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. NANOG 46 submissions are welcome at http://pc.nanog.org. Conditional acceptance notifications for NANOG 46 will be sent by 19 May 2009. Detail of the submission process, as well as NANOG 46 dates of interest are described below. About NANOG =========== NANOG is the premiere meeting for network operators in North America, and provides a forum for information exchange among network operators, engineers, and researchers. NANOG meets three times each year, and include panels, presentations, tutorial sessions, and BOFs. NANOG attendees include operators from networks of all sizes, enterprise operators, peering coordinators, transport and switching equipment vendors, and network researchers. NANOG attendees will share ideas and interact with leaders in the field of network operations, discuss current operational events and issues, and learn about state of the art operational techniques. Materials from NANOG46 will be archived on http://www.nanog.org/meetings/nanog46. Key Dates for NANOG46 ===================== Call for Presentations Opens: 02 March 2009 Please use http://pc.nanog.org Deadline for Speaker Submissions: 27 March 2009 Final Slides: 06 April 2009 Final Program Published: 17 April 2009 Lightning talk submissions open: 15 May 2009 Technical Conference ==================== The NANOG Program Committee seeks proposals for presentations, panels, tutorial sessions, and BOFs in all areas of network operations, including (but not limited to): - Power and facilities Topics may include power reliability and engineering, green power, power efficiency, cooling, and facilities management. - Interconnections Topics may include IXes, intra-building, MMR, metro-wide connections, peering, and transit purchasing tactics and strategies. - Security Topics may include routing security, route filtering of large peers/customers, and inter-as security and cooperation. - DNS Topics may include using DNS data for network metrics, botnet discovery, and geolocation. - IPv6 Topics may include real-world deployment challenges, Carrier Grade NAT, NAT-PT implementations that work and scale, and allocation strategies. - Content Topics may include Distribution (p2p, IPTV), content payment models, content distribution technologies and networks, and storage/archiving. - Disaster recovery Topics may include Risk analysis, training, agencies, planning methods, hardware portability, key tools, transport audits, and other lessons learned. In general, presentations are being sought by and for network operators of all sizes. Presentations about difficult problems (and interesting solutions) that you encounter in the course of your job are encouraged. If you think you have an interesting topic but want some feedback or assistance working it into a presentation, please email the Program Committee chair (chair at pc.nanog.org), and a representative on the Program Committee will give you the feedback needed to work it into a presentation. Talks ===== Plenary Session --------------- A plenary session talk should be on a topic of interest to the general NANOG audience, and may be up to 30 minutes long (including time for questions and answers.) Tracks ------ Tracks are 90-minute informal agenda blocks on topics which are of interest to a portion of the NANOG community. The 90-minute block can be subdivided into any number of combinations to suit the theme. A moderator generally coordinates content within the 90-minute block of time. A typical track session includes some presentations, but usually is focused on community discussion and interaction. Frequent track topics include: - Peering - ISP Security - Tools A track session is 90 minutes. Typically two tracks or three tracks will be run concurrently. Panels ------ Panel selection will be based on the importance, originality, focus and timeliness of the topic; expertise of proposed panelists; as well as the potential for informative and controversial discussion. The panel leader should provide an abstract describing the panel theme, list of panelists, and an outline of how the panel will be organized. After acceptance, the panel leader will be given the option to invite panel authors to submit their presentations to the NANOG Program Committee for review. Until then authors should not submit their individual presentations for the panel. A panel may be up to 90 minutes long. Lightning Talks --------------- A lightning talk is a very short presentation or speech by any attendee on any topic relevant to the NANOG audience. These are limited to ten minutes; this will be strictly enforced. If you have a topic that's timely, interesting, or even a crackpot idea you want to share, we encourage you to consider presenting it. Signups for lightning talks will be accepted during the NANOG meeting. Research Forum -------------- Researchers are invited to present short (10-minute) summaries of their work for operator feedback. Topics include routing, network performance, statistical measurement and analysis, and protocol development and implementation. Studies presented may be works in progress. Researchers from academia, government, and industry are encouraged to present. Tutorials --------- Proposals are also invited for tutorial sessions from the introductory through advanced level on all related topics, including: - Disaster Recovery Planning - Troubleshooting BGP - Best Practices for Determining Traffic Matrices - Options for Blackhole and Discard Routing - BGP/MPLS Layer 3 VPNs - Peering business and engineering basics BOFs ---- BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the NANOG community. BOFs may be held in the hallways, break-out areas or in an unscheduled tutorial room by request submitted to nanogpc at nanog.org at least 30 minutes in advance of desired use with estimated duration notes. A typical BOF session may include some structure or presentations, but usually is focused on community discussion and interaction. Frequent BOF topics include: - R&D collaboration - Hot-topics in the media - Peering - ISP Security - Tools The less structured nature of BOF sessions allows for the greatest flexibility from a timing perspective. Registration Fee Waivers ========================= The meeting registration fee will be waived as follows: - General session talk: one speaker - General session panel: one moderator and all panelists - Research forum talk: one speaker - Track: one moderator - Tutorial: one instructor How to Present ============== The deadline for accepting abstracts and slides is 06 March 2009. While the majority of speaking slots may be filled by that date, a limited number of slots may be available after that date for topics that are exceptionally timely, important, or critical to the operations of the Internet. The primary speaker, moderator, or author should submit presentation information and an abstract on-line at: http://pc.nanog.org Once you have done this, you will receive instructions for submitting your draft slides. See Presentation Guidelines for complete submission guidelines. All submissions must include: - Author's name(s) - Preferred contact email address - Submission category (General Session, Panel, Tutorial, Research Forum, or BOF) - Presentation title - Abstract - Slides (attachment or URL), in PDF (preferred) or Powerpoint format (Slides are optional for BOFs.) You may instead submit the presentation information and draft slides in email to nanog-support at nanog.org. We look forward to reviewing your submission. Todd Underwood, Chair NANOG Program Committee _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From Jay.Murphy at state.nm.us Tue Feb 24 14:27:10 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Tue, 24 Feb 2009 13:27:10 -0700 Subject: Routing issue to Lunarpages/California Regional Internet In-Reply-To: <200902241830.n1OIU7xL032950@outbound.mail.nauticom.net> References: <200902241830.n1OIU7xL032950@outbound.mail.nauticom.net> Message-ID: For Lunar Pages: 1-877-586-2772 or, 1-714-521-8150 (US/Canada) For CA Regional Intranet: 1-888-221-5902 x2 Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Clinton Popovich [mailto:crpopovi at nauticom.net] Sent: Tuesday, February 24, 2009 11:30 AM To: nanog at nanog.org Subject: Routing issue to Lunarpages/California Regional Internet Does anyone have a contact for either of these two companies, we are seeing some routing issues somewhere on their network and would like to contact their network engineers. I have tired all contacts listed on their whois as well as their general support phone number to no avail. 67.210.117.26 = Lunar Pages 74.50.25.3 = Lunar Pages 74.50.26.3 = Lunar Pages 67.210.126.125 = Lunar Pages 216.75.16.199 = California Regional Intranet, Inc. 216.75.16.207 = California Regional Intranet, Inc. 66.240.211.13 = California Regional Intranet, Inc. Lunar Pages RTechHandle: LNTS1-ARIN RTechName: Lunarpages NOC Technical Support RTechPhone: +1-877-586-2772 RTechEmail: hostmaster at lunarpages.com California Regional Intranet, Inc. RTechHandle: IC63-ARIN RTechName: System Administration RTechPhone: +1-858-974-5080 RTechEmail: sysadmin at cari.net Clinton Popovich Systems Engineer Consolidated Communications Gibsonia Pa, 15044 Clint.popovich at consolidated.com ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From deleskie at gmail.com Tue Feb 24 13:51:31 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Tue, 24 Feb 2009 19:51:31 +0000 Subject: switch speed question Message-ID: <155431227-1235509533-cardhu_decombobulator_blackberry.rim.net-226608974-@bxe1201.bisx.prod.on.blackberry> Switches like this and the force10 2410 and the like are cut through so do sub micro second versus a 'regular' store and forward switch ------Original Message------ From: Holmes,David A To: Deric Kwok To: nanog at nanog.org Subject: RE: switch speed question Sent: Feb 24, 2009 1:03 PM Arista claims to have the fastest 1/10 Gig 24 and 48 port 1RU switch, with a backplane capacity guaranteeing 10 Gig full duplex line rate per port. Cisco's CEF is local only and functions to download the arp cache and routing table into ASICs for hardware switching; but look at Cisco's NSF/SSO for cases where adjacent devices are all defined in the same packet forwarding state machine. -----Original Message----- From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] Sent: Monday, February 23, 2009 5:08 PM To: nanog at nanog.org Subject: switch speed question Hi Can you share your experience what is fastest Gig switch? I see there is CEF feature in cisco. ls it big different when i enable it in switch vs other switch? ls there any problem? Thank you Sent from my BlackBerry device on the Rogers Wireless Network From chris at netops.t3com.net Tue Feb 24 15:41:42 2009 From: chris at netops.t3com.net (Chris Wallace) Date: Tue, 24 Feb 2009 16:41:42 -0500 Subject: comcast price check In-Reply-To: References: Message-ID: <3A54EAB8-1E2C-42DE-8609-B3D9B47D6DC5@netops.t3com.net> How much "scheduled" downtime was there? ---Chris On Feb 23, 2009, at 11:46 AM, Justin Wilson - MTIN wrote: > In a "Former Life" we used Comcast for transport for a school > corporation. > In the 3 years we used them we have 10 minutes of unscheduled > downtime. > > > Justin > > > From micheal at spmedicalgroup.com Tue Feb 24 20:27:42 2009 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Tue, 24 Feb 2009 20:27:42 -0600 Subject: Yahoo and their mail filters.. Message-ID: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> This may be old news, but I've not been in the list for quite some time. At any rate, is anyone else having issues with Yahoo blocking / deferring legitimate emails? My situation is that I host our corporate mx'ers on my network, one of the companies that we recently purchased has Yahoo hosting their domains mail. Mail traffic to them is getting temporarily deferred with the "421 4.7.0 [TS01] Messages from xxx.xxx.xxx.xxx temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html" The admin of the facility has contacted Yahoo about this but their response was for "more information" when they were told that traffic from my mx to their domain was to being deferred. I may end up just having them migrate to my systems just to maintain company communications if we can't clear this up in a timely manner. -- Micheal Patterson From jabley at hopcount.ca Tue Feb 24 20:41:24 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 24 Feb 2009 21:41:24 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> Message-ID: <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> On 24 Feb 2009, at 21:27, Micheal Patterson wrote: > This may be old news, but I've not been in the list for quite some > time. At any rate, is anyone else having issues with Yahoo > blocking / deferring legitimate emails? Yes. Everybody else. Joe From carlos at race.com Tue Feb 24 20:50:20 2009 From: carlos at race.com (Carlos Alcantar) Date: Tue, 24 Feb 2009 18:50:20 -0800 Subject: Yahoo and their mail filters.. Message-ID: <859604546CD1FF488BDB6EA94C896AFB592F60@racexchange.race.local> i ran into the same issue pulled my hair out for a little bit. Make sure you have domain keys / dkim and spf implemented on your mail servers and domains. Once I did that all was smooth sailing. Carlos Alcantar Race Technologies, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.246.8900 F: 650.246.8901 E: carlos ['at'] race.com -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Tuesday, February 24, 2009 6:41 PM To: Micheal Patterson Cc: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. On 24 Feb 2009, at 21:27, Micheal Patterson wrote: > This may be old news, but I've not been in the list for quite some > time. At any rate, is anyone else having issues with Yahoo > blocking / deferring legitimate emails? Yes. Everybody else. Joe From erik_list at caneris.com Tue Feb 24 21:11:24 2009 From: erik_list at caneris.com (Erik (Caneris)) Date: Tue, 24 Feb 2009 22:11:24 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster>, <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> Message-ID: Ditto. They appear to use some strange form of greylisting combined with blocking. What seems to help is SPF and PTRs that match the EHLO your MTAs will send. We didn't implement Domain Keys / DKIM. On a related note, don't get me started on Hotmail. They used to (still do?) silently swallow mail into a black hole after accepting it. No NDR, no spam folder, just good ol' mail shredding without anyone knowing. Again, SPF and PTRs seem to help. Oh yeah, make sure you're not sending spam to them. That might help too. ;) Erik ________________________________________ From: Joe Abley [jabley at hopcount.ca] Sent: Tuesday, February 24, 2009 9:41 PM To: Micheal Patterson Cc: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. On 24 Feb 2009, at 21:27, Micheal Patterson wrote: > This may be old news, but I've not been in the list for quite some > time. At any rate, is anyone else having issues with Yahoo > blocking / deferring legitimate emails? Yes. Everybody else. Joe From stefan at csudsu.com Tue Feb 24 21:23:21 2009 From: stefan at csudsu.com (Stefan Molnar) Date: Wed, 25 Feb 2009 03:23:21 +0000 Subject: Yahoo and their mail filters.. Message-ID: <1579708549-1235532184-cardhu_decombobulator_blackberry.rim.net-1858901793-@bxe1237.bisx.prod.on.blackberry> They are accepting them by the 250 code, but never endup on the user mailbox. This was just within the last week. Fun Fun ------Original Message------ From: Micheal Patterson To: nanog at nanog.org Subject: Yahoo and their mail filters.. Sent: Feb 24, 2009 6:27 PM This may be old news, but I've not been in the list for quite some time. At any rate, is anyone else having issues with Yahoo blocking / deferring legitimate emails? My situation is that I host our corporate mx'ers on my network, one of the companies that we recently purchased has Yahoo hosting their domains mail. Mail traffic to them is getting temporarily deferred with the "421 4.7.0 [TS01] Messages from xxx.xxx.xxx.xxx temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html" The admin of the facility has contacted Yahoo about this but their response was for "more information" when they were told that traffic from my mx to their domain was to being deferred. I may end up just having them migrate to my systems just to maintain company communications if we can't clear this up in a timely manner. -- Micheal Patterson From micheal at spmedicalgroup.com Tue Feb 24 21:53:11 2009 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Tue, 24 Feb 2009 21:53:11 -0600 Subject: Yahoo and their mail filters.. References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster>, <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> Message-ID: ----- Original Message ----- From: "Erik (Caneris)" To: "Joe Abley" ; "Micheal Patterson" Cc: Sent: Tuesday, February 24, 2009 9:11 PM Subject: RE: Yahoo and their mail filters.. Ditto. They appear to use some strange form of greylisting combined with blocking. What seems to help is SPF and PTRs that match the EHLO your MTAs will send. We didn't implement Domain Keys / DKIM. On a related note, don't get me started on Hotmail. They used to (still do?) silently swallow mail into a black hole after accepting it. No NDR, no spam folder, just good ol' mail shredding without anyone knowing. Again, SPF and PTRs seem to help. Oh yeah, make sure you're not sending spam to them. That might help too. ;) Erik SPF records aren't being recognized, I've been running them for some time now so it would seem that they're not honoring them. -- Micheal Patterson From ops.lists at gmail.com Tue Feb 24 21:59:00 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Feb 2009 09:29:00 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> Message-ID: On Wed, Feb 25, 2009 at 9:23 AM, Micheal Patterson wrote: > > SPF records aren't being recognized, I've been running them for some time > now so it would seem that they're not honoring them. > Christ .. Yahoo did say "complaints". And it can take a very low level of complaints before a block goes into place - especially for low volume (corporate etc) mailservers. Feedback loops are one cure, and another cure is keeping complaint volumes down. * Do you have an unfiltered NAT gateway pointed to the same IP as your corporate MTA? * Do you have any large spam sources in close proximity to you? Like you are colo'd on a /28 and someone else has a /27 or /26 in the same /24 that's emitting tons of spam (assuming colo). Or you have your mailserver hosted on a dsl pool (even a business class dsl pool) in which case your server is an island of valid mail in a large swamp of virus traffic * Do you have a marketing department that might be slightly overactive? etc etc. srs From stefan at csudsu.com Tue Feb 24 22:26:35 2009 From: stefan at csudsu.com (Stefan Molnar) Date: Wed, 25 Feb 2009 04:26:35 +0000 Subject: Yahoo and their mail filters.. Message-ID: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> For our userbase with yahoo/hotmail/aol accouts they hit the spam button more often than delete. Then complain they do not get emails anymore from us, then want discounts on a bill of sale they missed. It is a never ending story. ------Original Message------ From: Suresh Ramasubramanian To: Micheal Patterson Cc: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. Sent: Feb 24, 2009 7:59 PM On Wed, Feb 25, 2009 at 9:23 AM, Micheal Patterson wrote: > > SPF records aren't being recognized, I've been running them for some time > now so it would seem that they're not honoring them. > Christ .. Yahoo did say "complaints". And it can take a very low level of complaints before a block goes into place - especially for low volume (corporate etc) mailservers. Feedback loops are one cure, and another cure is keeping complaint volumes down. * Do you have an unfiltered NAT gateway pointed to the same IP as your corporate MTA? * Do you have any large spam sources in close proximity to you? Like you are colo'd on a /28 and someone else has a /27 or /26 in the same /24 that's emitting tons of spam (assuming colo). Or you have your mailserver hosted on a dsl pool (even a business class dsl pool) in which case your server is an island of valid mail in a large swamp of virus traffic * Do you have a marketing department that might be slightly overactive? etc etc. srs From ops.lists at gmail.com Tue Feb 24 22:31:52 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Feb 2009 10:01:52 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> Message-ID: With a large enough userbase, misdirected spam complaints become far less of a factor. Lets put it this way .. one or two users can forget and report the same email as spam. If a whole bunch of users do that, not just a few, then either two things. 1. You have a problem or 2. There's a mass outbreak of alzheimers and all our users forgot Again - that's with a large enough userbase and with marketing content sent in bulk. Deliverability problems for lower volume is tougher to troubleshoot and it could be because of various other reasons than just complaints. --srs (mailops IS operational and belongs on nanog) On Wed, Feb 25, 2009 at 9:56 AM, Stefan Molnar wrote: > For our userbase with yahoo/hotmail/aol accouts they hit the spam button more often than delete. ?Then complain they do not get emails anymore from us, then want discounts on a bill of sale they missed. It is a never ending story. > > > ------Original Message------ > From: Suresh Ramasubramanian > To: Micheal Patterson > Cc: nanog at nanog.org > Subject: Re: Yahoo and their mail filters.. > Sent: Feb 24, 2009 7:59 PM > > On Wed, Feb 25, 2009 at 9:23 AM, Micheal Patterson > wrote: >> >> SPF records aren't being recognized, I've been running them for some time >> now so it would seem that they're not honoring them. >> > > Christ .. Yahoo did say "complaints". ?And it can take a very low > level of complaints before a block goes into place - especially for > low volume (corporate etc) mailservers. > > Feedback loops are one cure, and another cure is keeping complaint volumes down. > > * Do you have an unfiltered NAT gateway pointed to the same IP as your > corporate MTA? > > * Do you have any large spam sources in close proximity to you? ?Like > you are colo'd on a /28 and someone else has a /27 or /26 in the same > /24 that's emitting tons of spam (assuming colo). ?Or you have your > mailserver hosted on a dsl pool (even a business class dsl pool) in > which case your server is an island of valid mail in a large swamp of > virus traffic > > * Do you have a marketing department that might be slightly overactive? > > etc etc. > > srs > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From tom at snnap.net Wed Feb 25 03:58:20 2009 From: tom at snnap.net (Tom Storey) Date: Wed, 25 Feb 2009 20:28:20 +1030 (CST) Subject: switch speed question Message-ID: <55572.172.25.144.4.1235555900.squirrel@imap.snnap.net> > Not every bit in results in just one bit out. Broadcast, multicast, > flooding for unknown MACs (or switching failures), ... They were talking about a simple scenario where a bit that enters a port will leave a port. With 24 gigabit ports, for all intents and purposes, you will only ever have 24 gigabits at the most traversing the backplane. From ops.lists at gmail.com Wed Feb 25 05:41:44 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Feb 2009 17:11:44 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: <49A52C3B.10704@blacknight.com> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <49A52C3B.10704@blacknight.com> Message-ID: On Wed, Feb 25, 2009 at 5:02 PM, Niall Donegan wrote: > > Another interesting side effect of that is email forwarder accounts. > Take a user who gets a domain on our shared hosting setup and forwards > the email for certain users to a Yahoo account. If those mails are > marked as spam, it seems to be our server that gets blacklisted rather > than the originating server. > No surprise. Guess whose IP is the one handing off to yahoo? If you have forwarding users - * Spam filter them to reject spam rather than simply tag and forward it. * Isolate your forwarding traffic through a single IP, Let ISPs know. > Feedback loops often aren't that useful either. We're on the AOL Scomp > feedback loop, and we've often got fairly personal email sent to our > abuse desk because the users simply press spam rather than delete. You have a far smaller userbase, and a userbase you know. For us, with random nigerians and other spammers signing up / trying to sign up all the time, FBLs are invaluable as a realtime notification of spam issues. And as I said random misdirected spam reports wont trigger a block as much as your leaking forwarded spam. Or your getting a hacked cgi/php or a spammer installed direct to mx spamware. [so if you are cpanel - smtp tweak/csf firewall and mod_security for apache should be default on your install if you havent already done so] -srs From thegameiam at yahoo.com Wed Feb 25 07:48:04 2009 From: thegameiam at yahoo.com (David Barak) Date: Wed, 25 Feb 2009 05:48:04 -0800 (PST) Subject: switch speed question In-Reply-To: <55572.172.25.144.4.1235555900.squirrel@imap.snnap.net> Message-ID: <413733.8751.qm@web31811.mail.mud.yahoo.com> Doesn't that assume that the communicarion is unidirectional? If two hosts are exchanging 1Gbps flows, the traffic across the bus will be 2Gbps, right? And of course, this doesn't include any bus-intensive operations like multicast or things which require cpu processing - those can consume a lot more resources than the input rate of the port. -David Barak Tom Storey wrote: >> Not every bit in results in just one bit out. Broadcast, multicast, >> flooding for unknown MACs (or switching failures), ... > They were talking about a simple scenario where a bit that enters a port > will leave a port. With 24 gigabit ports, for all intents and purposes, > you will only ever have 24 gigabits at the most traversing the backplane. From tom at snnap.net Wed Feb 25 08:13:01 2009 From: tom at snnap.net (Tom Storey) Date: Thu, 26 Feb 2009 00:43:01 +1030 Subject: switch speed question In-Reply-To: <413733.8751.qm@web31811.mail.mud.yahoo.com> References: <413733.8751.qm@web31811.mail.mud.yahoo.com> Message-ID: <181BD096-634D-47F0-82B5-4C07E692516D@snnap.net> Were not considering anything other than basic switching in this scenario, as is my understanding. 2 hosts will create 2gbps of traffic as each host is inputting 1gbps into the switch (just multiply it by 12 to give you 24 ports). 3 hosts will create 3gbps of traffic as each inputs 1gbps into the switch (e.g. each host could be sending 500mbps to each of the other hosts). And thus and so forth. :-) You can only input a maximum of 24gbps into the switch, which means that only 24gbps will cross the backplane. Yes there is 48gbps if you combine tx and rx of each port, but traffic only has to cross the backplane once, from rx on one port to tx on another. Sorry if I have hijacked this thread from the OP. :-) Tom On 26/02/2009, at 12:18 AM, David Barak wrote: > > Doesn't that assume that the communicarion is unidirectional? > > If two hosts are exchanging 1Gbps flows, the traffic across the bus > will be 2Gbps, right? > > And of course, this doesn't include any bus-intensive operations > like multicast > or things which require cpu processing - those can consume a lot > more resources than the input rate of the port. > > -David Barak > > Tom Storey wrote: >>> Not every bit in results in just one bit out. Broadcast, multicast, >>> flooding for unknown MACs (or switching failures), ... >> They were talking about a simple scenario where a bit that enters a >> port >> will leave a port. With 24 gigabit ports, for all intents and >> purposes, >> you will only ever have 24 gigabits at the most traversing the >> backplane. > > > > From nanog at daork.net Wed Feb 25 08:15:27 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 26 Feb 2009 03:15:27 +1300 Subject: switch speed question In-Reply-To: <413733.8751.qm@web31811.mail.mud.yahoo.com> References: <413733.8751.qm@web31811.mail.mud.yahoo.com> Message-ID: <5F649622-1565-4D02-AC0F-472CA42CEB9E@daork.net> On 26/02/2009, at 2:48 AM, David Barak wrote: > Doesn't that assume that the communicarion is unidirectional? ... No. > If two hosts are exchanging 1Gbps flows, the traffic across the bus > will be 2Gbps, right? Yes. 1Gbps backplane impact per host. You have two hosts, right? One host per port? That's 1Gbps per port. So, 24 ports = 24Gbps, right? Let's try look at it another way: - A 24 port gig switch can receive at most 24Gbps. - That same switch can transmit at most 24Gbps. You don't get to add transmit and receive together to get 48Gbps. Packets don't go across the backplane once to receive, and then once more to transmit. They go across once, from the receiving port to the transmitting port. (sure, sometimes perhaps packets do go across twice, but not normally) > And of course, this doesn't include any bus-intensive operations > like multicast > or things which require cpu processing - those can consume a lot > more resources than the input rate of the port. Of course multicast/broadcast consumes more resources than the input rate. That's the point. If you receive multicast or broadcast at 1Gbps, and the multicast needs to go out all the ports, you need to transmit at 24Gbps. That's 24 x the transmit resources (and probably backplane resources, depending on architecture etc. etc.) than a single 1Gbps unicast stream. Of course, with unicast it is only getting to one host. Let's assume we have data at 1Gbps that we need to get to 24 hosts. - If we unicast, we need 24 input ports, and 24 output ports, assuming we only have gig ports (or say 3x10GE, or whatever). - If we multicast, we need 1 input port, and 24 output ports. When you compare the end result, multicast uses significantly less resources, right? In fact, perhaps some bus architectures know about how multicast works, and it consumes *less* resources than doing the same thing with many unicast streams. If the bus does not know about multicast, then the bus would treat it as 24 unicast streams, surely. -- Nathan Ward From rcorbin at traffiq.com Wed Feb 25 08:26:33 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Wed, 25 Feb 2009 08:26:33 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: Message-ID: Funny we were just having similar conversation on mailop.org :) . Suresh is right about the feedback loops (you also should subscribe to comcasts/hotmails/trend micro's (mail-abuse.com)). If you don't have an external gateway that makes doing reports easy then they are a good way to find out when spam problems arise, such as the pesky Nigerian spammers who constantly find new ways to thwart all anti-fraud checks prior to creating the accounts. One thing that I did, when being an email admin for a very large shared hosting company, was when I ran reports of emails going to @yahoo.com I took the top 10 or so recipients and figured out who had the forwarders setup to send to them. I talked to the customer and even gave them alternative solutions (such as giving them 6months free for Postini inbound anti-spam service for that forward account). The worst ones were those who had catchalls setup to forward to their spam at yahoo.com account, those simply got notified that it was removed. -r -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Wednesday, February 25, 2009 6:42 AM To: Niall Donegan Cc: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. On Wed, Feb 25, 2009 at 5:02 PM, Niall Donegan wrote: > > Another interesting side effect of that is email forwarder accounts. > Take a user who gets a domain on our shared hosting setup and forwards > the email for certain users to a Yahoo account. If those mails are > marked as spam, it seems to be our server that gets blacklisted rather > than the originating server. > No surprise. Guess whose IP is the one handing off to yahoo? If you have forwarding users - * Spam filter them to reject spam rather than simply tag and forward it. * Isolate your forwarding traffic through a single IP, Let ISPs know. > Feedback loops often aren't that useful either. We're on the AOL Scomp > feedback loop, and we've often got fairly personal email sent to our > abuse desk because the users simply press spam rather than delete. You have a far smaller userbase, and a userbase you know. For us, with random nigerians and other spammers signing up / trying to sign up all the time, FBLs are invaluable as a realtime notification of spam issues. And as I said random misdirected spam reports wont trigger a block as much as your leaking forwarded spam. Or your getting a hacked cgi/php or a spammer installed direct to mx spamware. [so if you are cpanel - smtp tweak/csf firewall and mod_security for apache should be default on your install if you havent already done so] -srs From rcorbin at traffiq.com Wed Feb 25 08:36:12 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Wed, 25 Feb 2009 08:36:12 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: Message-ID: On hotmail's defense at least their support contacts will respond to your emails. It may take a few rounds of proving that they are 'blackholing' your email and them saying 'no were not'..but after a few times of that you know exactly what to say when submitting a ticket to them (ie I sent this email to your testing account at xx:xx pm, I cc'ed my address xxx at hotmail.com and it wasn't received and here are the logs showing your servers accepted the email.). -r -----Original Message----- From: Erik (Caneris) [mailto:erik_list at caneris.com] Sent: Tuesday, February 24, 2009 10:11 PM To: Joe Abley; Micheal Patterson Cc: nanog at nanog.org Subject: RE: Yahoo and their mail filters.. Ditto. They appear to use some strange form of greylisting combined with blocking. What seems to help is SPF and PTRs that match the EHLO your MTAs will send. We didn't implement Domain Keys / DKIM. On a related note, don't get me started on Hotmail. They used to (still do?) silently swallow mail into a black hole after accepting it. No NDR, no spam folder, just good ol' mail shredding without anyone knowing. Again, SPF and PTRs seem to help. Oh yeah, make sure you're not sending spam to them. That might help too. ;) Erik ________________________________________ From: Joe Abley [jabley at hopcount.ca] Sent: Tuesday, February 24, 2009 9:41 PM To: Micheal Patterson Cc: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. On 24 Feb 2009, at 21:27, Micheal Patterson wrote: > This may be old news, but I've not been in the list for quite some > time. At any rate, is anyone else having issues with Yahoo > blocking / deferring legitimate emails? Yes. Everybody else. Joe From eesslinger at fpu-tn.com Wed Feb 25 08:47:36 2009 From: eesslinger at fpu-tn.com (Eric Esslinger) Date: Wed, 25 Feb 2009 08:47:36 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: References: Message-ID: <49A55A08.5080400@fpu-tn.com> We pretty constantly are deferred on yahoo, and at one point had all outbound mail for yahoo logged at the sender/recipient/subject/size level to get an idea what was up. In an experiment, I found that after being 'clean' (not being deferred) for close to a week, simply sending myself 1 single email, then hitting spam in the yahoo box was enough to get us being blocked for another 24 hours. I would sign up for a FBL if they had one; I find the others I have very valuable (though about 90% of what I get back is 'spam rather than delete' ). Ray Corbin wrote: > Funny we were just having similar conversation on mailop.org :) . Suresh is right about the feedback loops (you also should subscribe to comcasts/hotmails/trend micro's (mail-abuse.com)). If you don't have an external gateway that makes doing reports easy then they are a good way to find out when spam problems arise, such as the pesky Nigerian spammers who constantly find new ways to thwart all anti-fraud checks prior to creating the accounts. One thing that I did, when being an email admin for a very large shared hosting company, was when I ran reports of emails going to @yahoo.com I took the top 10 or so recipients and figured out who had the forwarders setup to send to them. I talked to the customer and even gave them alternative solutions (such as giving them 6months free for Postini inbound anti-spam service for that forward account). The worst ones were those who had catchalls setup to forward to their spam at yahoo.com account, those simply got notified that it was removed. > > -r > > > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] > Sent: Wednesday, February 25, 2009 6:42 AM > To: Niall Donegan > Cc: nanog at nanog.org > Subject: Re: Yahoo and their mail filters.. > > On Wed, Feb 25, 2009 at 5:02 PM, Niall Donegan wrote: > >> Another interesting side effect of that is email forwarder accounts. >> Take a user who gets a domain on our shared hosting setup and forwards >> the email for certain users to a Yahoo account. If those mails are >> marked as spam, it seems to be our server that gets blacklisted rather >> than the originating server. >> >> > > No surprise. Guess whose IP is the one handing off to yahoo? > > If you have forwarding users - > > * Spam filter them to reject spam rather than simply tag and forward it. > * Isolate your forwarding traffic through a single IP, Let ISPs know. > > >> Feedback loops often aren't that useful either. We're on the AOL Scomp >> feedback loop, and we've often got fairly personal email sent to our >> abuse desk because the users simply press spam rather than delete. >> > > You have a far smaller userbase, and a userbase you know. For us, with > random nigerians and other spammers signing up / trying to sign up all > the time, FBLs are invaluable as a realtime notification of spam > issues. > > And as I said random misdirected spam reports wont trigger a block as > much as your leaking forwarded spam. Or your getting a hacked cgi/php > or a spammer installed direct to mx spamware. [so if you are cpanel - > smtp tweak/csf firewall and mod_security for apache should be default > on your install if you havent already done so] > > -srs > > > -- Eric Esslinger Information Services Manager Fayetteville Public Utilities Fayetteville, TN 37334 Phone: 931-433-1522x165 Fax: 931-433-0646 eesslinger at fpu-tn.com From ppauly at gmail.com Wed Feb 25 08:57:35 2009 From: ppauly at gmail.com (Peter Pauly) Date: Wed, 25 Feb 2009 09:57:35 -0500 Subject: slightly OT: wall mount UPS for demarc Message-ID: I'm looking to buy several small wall mounted UPS's to power a telco's metro ethernet switches. (Yes, they should have provided some kind of protection, but won't). The closest suitable UPS I've found is this: http://www.tripplite.com/EN/products/model.cfm?txtSeriesID=419&EID=361&txtModelID=3640 Can anyone suggest a better alternative? I want something sturdy, preferably metal, that can screw to a wall and be worry free for years at a time. From jim.h.willis at gmail.com Wed Feb 25 09:06:05 2009 From: jim.h.willis at gmail.com (Jim Willis) Date: Thu, 26 Feb 2009 08:06:05 +1700 Subject: Legislation and its effects in our world Message-ID: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> After having a brief conversation with a friend of mine over the weekend about this new proposed legislation I was horrified to find that I could not dig anything up on it in NANOG. Surely this sort of short minded legislation should have been a bit more thought through in its effects on those that would have to implement these changes. My major concern is not just for myself but for a much broader picture. "Republican politicians on Thursday called for a sweeping new federal law that would require all Internet providers and operators of millions of Wi-Fi access points, even hotels, local coffee shops, and home users, to keep records about users for two years to aid police investigations." http://www.cnn.com/2009/TECH/02/20/internet.records.bill/index.html I understand and agree that minors should be protected and I think child pornography is awful, however I think how the government is going about catching these criminals with this new legislation will not really be any more efficient than there current methods. Having a log of all IP's that come across my or anyone in America's "home" Wi-Fi for two years is not going to help "police investigations" but will cause me to have to go buy a more expensive router. So I'm just wondering, how would this legislation effect some of you on the NANOG list? -Jim From Rod.Beck at hiberniaatlantic.com Wed Feb 25 09:09:38 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 25 Feb 2009 15:09:38 -0000 Subject: [SPAM-HEADER] - Legislation and its effects in our world - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB9F6C1D@bert.HiberniaAtlantic.local> Another issue is civil rights. Do we want to create a surveillance society? It has already happened to a large extent in the UK and the US, but this is significant step forward ... I'll leave it at that since I am writing on corporate email and I do not represent my company on this issue. Regards, Roderick. After having a brief conversation with a friend of mine over the weekend about this new proposed legislation I was horrified to find that I could not dig anything up on it in NANOG. Surely this sort of short minded legislation should have been a bit more thought through in its effects on those that would have to implement these changes. My major concern is not just for myself but for a much broader picture. "Republican politicians on Thursday called for a sweeping new federal law that would require all Internet providers and operators of millions of Wi-Fi access points, even hotels, local coffee shops, and home users, to keep records about users for two years to aid police investigations." http://www.cnn.com/2009/TECH/02/20/internet.records.bill/index.html I understand and agree that minors should be protected and I think child pornography is awful, however I think how the government is going about catching these criminals with this new legislation will not really be any more efficient than there current methods. Having a log of all IP's that come across my or anyone in America's "home" Wi-Fi for two years is not going to help "police investigations" but will cause me to have to go buy a more expensive router. So I'm just wondering, how would this legislation effect some of you on the NANOG list? -Jim From davei at otd.com Wed Feb 25 09:16:23 2009 From: davei at otd.com (Dave Israel) Date: Wed, 25 Feb 2009 10:16:23 -0500 Subject: switch speed question In-Reply-To: <5F649622-1565-4D02-AC0F-472CA42CEB9E@daork.net> References: <413733.8751.qm@web31811.mail.mud.yahoo.com> <5F649622-1565-4D02-AC0F-472CA42CEB9E@daork.net> Message-ID: <49A560C7.8020800@otd.com> Nathan Ward wrote: > On 26/02/2009, at 2:48 AM, David Barak wrote: >> If two hosts are exchanging 1Gbps flows, the traffic across the bus >> will be 2Gbps, right? > > You don't get to add transmit and receive together to get 48Gbps. > Packets don't go across the backplane once to receive, and then once > more to transmit. They go across once, from the receiving port to the > transmitting port. (sure, sometimes perhaps packets do go across > twice, but not normally) Assuming a crossbar switch, sure. If your ports individually look up the outgoing port for an incoming packet, request backplane to that port, and transmit, then you only need 24Gbps. If your ports need to connect to an intelligent entity on the backplane to do your routing/switching/IGMP snooping/QoS enforcement/etc, then you are indeed going to cross the backplane twice, and need both transmit and receive bandwidth. Since many of us are routing goons with store-and-forward roots, we tend to think along those lines. And it is still wise, even in this day and age, to make sure that backplane bandwidth doesn't include a central switching point, or, if it doesn't, the marketing folks haven't doubled the backplane numbers because they took it out. -Dave From stearns at dhyw.com Wed Feb 25 09:30:15 2009 From: stearns at dhyw.com (David Stearns) Date: Wed, 25 Feb 2009 08:30:15 -0700 Subject: Legislation and its effects in our world In-Reply-To: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> Message-ID: <3d6c57170902250730w10a3de7dkb42bf1fe0b208a97@mail.gmail.com> Hi Jim, Avoiding the politics of this issue, I suspect that many more home users will be affected than corporate or backbone admins. I already log all access to my wireless, though currently I don't keep outgoing access logs for that long. I suspect that if this were to become law, the logging mechanisms in the provided home wireless routers would need a revamp. Or at least their storage method would. -DS On Wed, Feb 25, 2009 at 8:06 AM, Jim Willis wrote: > After having a brief conversation with a friend of mine over the weekend > about this new proposed legislation I was horrified to find that I could > not > dig anything up on it in NANOG. Surely this sort of short minded > legislation > should have been a bit more thought through in its effects on those that > would have to implement these changes. My major concern is not just for > myself but for a much broader picture. > > "Republican politicians on Thursday called for a sweeping new federal law > that would require all Internet providers and operators of millions of > Wi-Fi > access points, even hotels, local coffee shops, and home users, to keep > records about users for two years to aid police investigations." > > http://www.cnn.com/2009/TECH/02/20/internet.records.bill/index.html > > > I understand and agree that minors should be protected and I think child > pornography is awful, however I think how the government is going about > catching these criminals with this new legislation will not really be any > more efficient than there current methods. Having a log of all IP's that > come across my or anyone in America's "home" Wi-Fi for two years is not > going to help "police investigations" but will cause me to have to go buy a > more expensive router. > > So I'm just wondering, how would this legislation effect some of you on the > NANOG list? > > -Jim > From fred at cisco.com Wed Feb 25 09:58:33 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 25 Feb 2009 07:58:33 -0800 Subject: Legislation and its effects in our world In-Reply-To: <3d6c57170902250730w10a3de7dkb42bf1fe0b208a97@mail.gmail.com> References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> <3d6c57170902250730w10a3de7dkb42bf1fe0b208a97@mail.gmail.com> Message-ID: <20B3F12B-8956-45EF-951D-BF788EF77FEA@cisco.com> If it's at all like the EU Date Retention provisions, it would be in the ISP, not the home router. The Danish want the moral equivalent of a netflow trace for each user (log of the kind of information netflow records for a session for each TCP/UDP/SCTP session the user initiates or terminates, produced on presentation of a warrant or subpoena), but the EU provisions are more application layer - when did the user "sign on" to the wireless network, and when did "s/he sign off", to whom did they send emails via the ISP's servers, and so on? Without commenting on police states and such, instantiating legislation is required in each country signatory to the Cybercrime Treaty. Both major parties have been on deck during that discussion... On Feb 25, 2009, at 7:30 AM, David Stearns wrote: > Hi Jim, > Avoiding the politics of this issue, I suspect that many more home > users > will be affected than corporate or backbone admins. I already log all > access to my wireless, though currently I don't keep outgoing access > logs > for that long. I suspect that if this were to become law, the logging > mechanisms in the provided home wireless routers would need a > revamp. Or at > least their storage method would. > -DS > > On Wed, Feb 25, 2009 at 8:06 AM, Jim Willis > wrote: > >> After having a brief conversation with a friend of mine over the >> weekend >> about this new proposed legislation I was horrified to find that I >> could >> not >> dig anything up on it in NANOG. Surely this sort of short minded >> legislation >> should have been a bit more thought through in its effects on those >> that >> would have to implement these changes. My major concern is not just >> for >> myself but for a much broader picture. >> >> "Republican politicians on Thursday called for a sweeping new >> federal law >> that would require all Internet providers and operators of millions >> of >> Wi-Fi >> access points, even hotels, local coffee shops, and home users, to >> keep >> records about users for two years to aid police investigations." >> >> http://www.cnn.com/2009/TECH/02/20/internet.records.bill/index.html >> >> >> I understand and agree that minors should be protected and I think >> child >> pornography is awful, however I think how the government is going >> about >> catching these criminals with this new legislation will not really >> be any >> more efficient than there current methods. Having a log of all IP's >> that >> come across my or anyone in America's "home" Wi-Fi for two years is >> not >> going to help "police investigations" but will cause me to have to >> go buy a >> more expensive router. >> >> So I'm just wondering, how would this legislation effect some of >> you on the >> NANOG list? >> >> -Jim >> From mylists at battleop.com Wed Feb 25 10:05:46 2009 From: mylists at battleop.com (Richey) Date: Wed, 25 Feb 2009 11:05:46 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: References: Message-ID: <05e701c99762$eb810460$c2830d20$@com> > Feedback loops often aren't that useful either. We're on the AOL Scomp > feedback loop, and we've often got fairly personal email sent to our > abuse desk because the users simply press spam rather than delete. AOL's Scomp is spam it's self. If I read though 100 messages maybe one message is really spam. The other 99 are jokes, regular emails, maybe a news letter from their church, etc. Most people are lazy and would rather click on the Spam button instead of unsubscribing for a list they subscribed to in the first place. Richey -----Original Message----- From: Ray Corbin [mailto:rcorbin at traffiq.com] Sent: Wednesday, February 25, 2009 9:27 AM To: Suresh Ramasubramanian; Niall Donegan Cc: nanog at nanog.org Subject: RE: Yahoo and their mail filters.. Funny we were just having similar conversation on mailop.org :) . Suresh is right about the feedback loops (you also should subscribe to comcasts/hotmails/trend micro's (mail-abuse.com)). If you don't have an external gateway that makes doing reports easy then they are a good way to find out when spam problems arise, such as the pesky Nigerian spammers who constantly find new ways to thwart all anti-fraud checks prior to creating the accounts. One thing that I did, when being an email admin for a very large shared hosting company, was when I ran reports of emails going to @yahoo.com I took the top 10 or so recipients and figured out who had the forwarders setup to send to them. I talked to the customer and even gave them alternative solutions (such as giving them 6months free for Postini inbound anti-spam service for that forward account). The worst ones were those who had catchalls setup to forward to their spam at yahoo.com account, those simply got notified that it was removed. -r -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Wednesday, February 25, 2009 6:42 AM To: Niall Donegan Cc: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. On Wed, Feb 25, 2009 at 5:02 PM, Niall Donegan wrote: > > Another interesting side effect of that is email forwarder accounts. > Take a user who gets a domain on our shared hosting setup and forwards > the email for certain users to a Yahoo account. If those mails are > marked as spam, it seems to be our server that gets blacklisted rather > than the originating server. > No surprise. Guess whose IP is the one handing off to yahoo? If you have forwarding users - * Spam filter them to reject spam rather than simply tag and forward it. * Isolate your forwarding traffic through a single IP, Let ISPs know. > Feedback loops often aren't that useful either. We're on the AOL Scomp > feedback loop, and we've often got fairly personal email sent to our > abuse desk because the users simply press spam rather than delete. You have a far smaller userbase, and a userbase you know. For us, with random nigerians and other spammers signing up / trying to sign up all the time, FBLs are invaluable as a realtime notification of spam issues. And as I said random misdirected spam reports wont trigger a block as much as your leaking forwarded spam. Or your getting a hacked cgi/php or a spammer installed direct to mx spamware. [so if you are cpanel - smtp tweak/csf firewall and mod_security for apache should be default on your install if you havent already done so] -srs From jamesb2147 at gmail.com Wed Feb 25 10:12:41 2009 From: jamesb2147 at gmail.com (Sean Hunter) Date: Wed, 25 Feb 2009 10:12:41 -0600 Subject: Legislation and its effects in our world In-Reply-To: <20B3F12B-8956-45EF-951D-BF788EF77FEA@cisco.com> References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> <3d6c57170902250730w10a3de7dkb42bf1fe0b208a97@mail.gmail.com> <20B3F12B-8956-45EF-951D-BF788EF77FEA@cisco.com> Message-ID: <210d4f910902250812r1d5a7b32x2be25c1da4877f63@mail.gmail.com> Sorry to intrude, but it is based on the reading of the law and at least according to ars technica's article ( http://arstechnica.com/tech-policy/news/2009/02/are-you-an-electronic-communication-service-provider.ars) that excludes home routers. That's not to say it couldn't be reinterpreted in the future. Also worth noting is that this is a Republican proposition and both sides still seem a bit bitter about the stimulus. ~Sean On Wed, Feb 25, 2009 at 9:58 AM, Fred Baker wrote: > If it's at all like the EU Date Retention provisions, it would be in the > ISP, not the home router. The Danish want the moral equivalent of a netflow > trace for each user (log of the kind of information netflow records for a > session for each TCP/UDP/SCTP session the user initiates or terminates, > produced on presentation of a warrant or subpoena), but the EU provisions > are more application layer - when did the user "sign on" to the wireless > network, and when did "s/he sign off", to whom did they send emails via the > ISP's servers, and so on? > > Without commenting on police states and such, instantiating legislation is > required in each country signatory to the Cybercrime Treaty. Both major > parties have been on deck during that discussion... > > > On Feb 25, 2009, at 7:30 AM, David Stearns wrote: > > Hi Jim, >> Avoiding the politics of this issue, I suspect that many more home users >> will be affected than corporate or backbone admins. I already log all >> access to my wireless, though currently I don't keep outgoing access logs >> for that long. I suspect that if this were to become law, the logging >> mechanisms in the provided home wireless routers would need a revamp. Or >> at >> least their storage method would. >> -DS >> >> On Wed, Feb 25, 2009 at 8:06 AM, Jim Willis >> wrote: >> >> After having a brief conversation with a friend of mine over the weekend >>> about this new proposed legislation I was horrified to find that I could >>> not >>> dig anything up on it in NANOG. Surely this sort of short minded >>> legislation >>> should have been a bit more thought through in its effects on those that >>> would have to implement these changes. My major concern is not just for >>> myself but for a much broader picture. >>> >>> "Republican politicians on Thursday called for a sweeping new federal law >>> that would require all Internet providers and operators of millions of >>> Wi-Fi >>> access points, even hotels, local coffee shops, and home users, to keep >>> records about users for two years to aid police investigations." >>> >>> http://www.cnn.com/2009/TECH/02/20/internet.records.bill/index.html >>> >>> >>> I understand and agree that minors should be protected and I think child >>> pornography is awful, however I think how the government is going about >>> catching these criminals with this new legislation will not really be any >>> more efficient than there current methods. Having a log of all IP's that >>> come across my or anyone in America's "home" Wi-Fi for two years is not >>> going to help "police investigations" but will cause me to have to go buy >>> a >>> more expensive router. >>> >>> So I'm just wondering, how would this legislation effect some of you on >>> the >>> NANOG list? >>> >>> -Jim >>> >>> > > From rcorbin at traffiq.com Wed Feb 25 10:14:31 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Wed, 25 Feb 2009 10:14:31 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: <05e701c99762$eb810460$c2830d20$@com> Message-ID: It depends on your environment. I've seen where it is helpful and where it is overwhelming. If you are a smaller company and want to know why you keep getting blocked then those should help. If you are a larger company and get a several hundred a day, but you send 100k emails to AOL then it is not as big of a deal. If you are a shared hosting provider and you get a lot of them you should look into what is being sent to AOL, such as forwarded spam from customers 'auto forwards' (isolate the auto forwards to a separate IP address and simply don't sign up for the FBL for it).... If you have a good setup where only customer-originated email is being sent through the IP's you have a FBL on, then it is useful and you shouldn't get as many complaints. -r -----Original Message----- From: Richey [mailto:mylists at battleop.com] Sent: Wednesday, February 25, 2009 11:06 AM To: nanog at nanog.org Subject: RE: Yahoo and their mail filters.. > Feedback loops often aren't that useful either. We're on the AOL Scomp > feedback loop, and we've often got fairly personal email sent to our > abuse desk because the users simply press spam rather than delete. AOL's Scomp is spam it's self. If I read though 100 messages maybe one message is really spam. The other 99 are jokes, regular emails, maybe a news letter from their church, etc. Most people are lazy and would rather click on the Spam button instead of unsubscribing for a list they subscribed to in the first place. Richey -----Original Message----- From: Ray Corbin [mailto:rcorbin at traffiq.com] Sent: Wednesday, February 25, 2009 9:27 AM To: Suresh Ramasubramanian; Niall Donegan Cc: nanog at nanog.org Subject: RE: Yahoo and their mail filters.. Funny we were just having similar conversation on mailop.org :) . Suresh is right about the feedback loops (you also should subscribe to comcasts/hotmails/trend micro's (mail-abuse.com)). If you don't have an external gateway that makes doing reports easy then they are a good way to find out when spam problems arise, such as the pesky Nigerian spammers who constantly find new ways to thwart all anti-fraud checks prior to creating the accounts. One thing that I did, when being an email admin for a very large shared hosting company, was when I ran reports of emails going to @yahoo.com I took the top 10 or so recipients and figured out who had the forwarders setup to send to them. I talked to the customer and even gave them alternative solutions (such as giving them 6months free for Postini inbound anti-spam service for that forward account). The worst ones were those who had catchalls setup to forward to their spam at yahoo.com account, those simply got notified that it was removed. -r -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Wednesday, February 25, 2009 6:42 AM To: Niall Donegan Cc: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. On Wed, Feb 25, 2009 at 5:02 PM, Niall Donegan wrote: > > Another interesting side effect of that is email forwarder accounts. > Take a user who gets a domain on our shared hosting setup and forwards > the email for certain users to a Yahoo account. If those mails are > marked as spam, it seems to be our server that gets blacklisted rather > than the originating server. > No surprise. Guess whose IP is the one handing off to yahoo? If you have forwarding users - * Spam filter them to reject spam rather than simply tag and forward it. * Isolate your forwarding traffic through a single IP, Let ISPs know. > Feedback loops often aren't that useful either. We're on the AOL Scomp > feedback loop, and we've often got fairly personal email sent to our > abuse desk because the users simply press spam rather than delete. You have a far smaller userbase, and a userbase you know. For us, with random nigerians and other spammers signing up / trying to sign up all the time, FBLs are invaluable as a realtime notification of spam issues. And as I said random misdirected spam reports wont trigger a block as much as your leaking forwarded spam. Or your getting a hacked cgi/php or a spammer installed direct to mx spamware. [so if you are cpanel - smtp tweak/csf firewall and mod_security for apache should be default on your install if you havent already done so] -srs From ernesto at cs.fiu.edu Wed Feb 25 10:26:37 2009 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Wed, 25 Feb 2009 11:26:37 -0500 Subject: Legislation and its effects in our world In-Reply-To: <210d4f910902250812r1d5a7b32x2be25c1da4877f63@mail.gmail.com> References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> <3d6c57170902250730w10a3de7dkb42bf1fe0b208a97@mail.gmail.com> <20B3F12B-8956-45EF-951D-BF788EF77FEA@cisco.com> <210d4f910902250812r1d5a7b32x2be25c1da4877f63@mail.gmail.com> Message-ID: <6FD4A82E-7BB8-4390-9B1F-C89F1FE48E29@cs.fiu.edu> I agree - Although this isn't legal advice and I'm not a lawyer: It amends 18 U.S.C. ?2703 which is entitled "Required Disclosure of Customer Communications or Records" which refers to providers, not home users... Better question: 1) Is there a reasonable expectation of privacy in the communications between end users and their providers so as to give rise to a 4th amendment issue? (Might have already been asked and answered...) On Feb 25, 2009, at 11:12 AM, Sean Hunter wrote: > Sorry to intrude, but it is based on the reading of the law and at > least > according to ars technica's article ( > http://arstechnica.com/tech-policy/news/2009/02/are-you-an-electronic-communication-service-provider.ars) > that excludes home routers. That's not to say it couldn't be > reinterpreted > in the future. > Also worth noting is that this is a Republican proposition and both > sides > still seem a bit bitter about the stimulus. > > ~Sean > > On Wed, Feb 25, 2009 at 9:58 AM, Fred Baker wrote: > >> If it's at all like the EU Date Retention provisions, it would be >> in the >> ISP, not the home router. The Danish want the moral equivalent of a >> netflow >> trace for each user (log of the kind of information netflow records >> for a >> session for each TCP/UDP/SCTP session the user initiates or >> terminates, >> produced on presentation of a warrant or subpoena), but the EU >> provisions >> are more application layer - when did the user "sign on" to the >> wireless >> network, and when did "s/he sign off", to whom did they send emails >> via the >> ISP's servers, and so on? >> >> Without commenting on police states and such, instantiating >> legislation is >> required in each country signatory to the Cybercrime Treaty. Both >> major >> parties have been on deck during that discussion... >> >> >> On Feb 25, 2009, at 7:30 AM, David Stearns wrote: >> >> Hi Jim, >>> Avoiding the politics of this issue, I suspect that many more home >>> users >>> will be affected than corporate or backbone admins. I already log >>> all >>> access to my wireless, though currently I don't keep outgoing >>> access logs >>> for that long. I suspect that if this were to become law, the >>> logging >>> mechanisms in the provided home wireless routers would need a >>> revamp. Or >>> at >>> least their storage method would. >>> -DS >>> >>> On Wed, Feb 25, 2009 at 8:06 AM, Jim Willis >>> wrote: >>> >>> After having a brief conversation with a friend of mine over the >>> weekend >>>> about this new proposed legislation I was horrified to find that >>>> I could >>>> not >>>> dig anything up on it in NANOG. Surely this sort of short minded >>>> legislation >>>> should have been a bit more thought through in its effects on >>>> those that >>>> would have to implement these changes. My major concern is not >>>> just for >>>> myself but for a much broader picture. >>>> >>>> "Republican politicians on Thursday called for a sweeping new >>>> federal law >>>> that would require all Internet providers and operators of >>>> millions of >>>> Wi-Fi >>>> access points, even hotels, local coffee shops, and home users, >>>> to keep >>>> records about users for two years to aid police investigations." >>>> >>>> http://www.cnn.com/2009/TECH/02/20/internet.records.bill/index.html >>>> >>>> >>>> I understand and agree that minors should be protected and I >>>> think child >>>> pornography is awful, however I think how the government is going >>>> about >>>> catching these criminals with this new legislation will not >>>> really be any >>>> more efficient than there current methods. Having a log of all >>>> IP's that >>>> come across my or anyone in America's "home" Wi-Fi for two years >>>> is not >>>> going to help "police investigations" but will cause me to have >>>> to go buy >>>> a >>>> more expensive router. >>>> >>>> So I'm just wondering, how would this legislation effect some of >>>> you on >>>> the >>>> NANOG list? >>>> >>>> -Jim >>>> >>>> >> >> From michele at blacknight.ie Wed Feb 25 10:41:37 2009 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Wed, 25 Feb 2009 16:41:37 +0000 Subject: Music Industry vs ISPs Message-ID: <782A5CAA-A0C7-4169-9820-C3367EA7100D@blacknight.ie> As a lot of you probably heard about the agreement involving one of the largest ISPs and the music industry ... In the followup the music industry decided to threaten ALL ISPs in Ireland: http://blog.blacknight.com/irma-threatens-irish-isps.html Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From ryan.slater at tac.com Wed Feb 25 10:41:30 2009 From: ryan.slater at tac.com (ryan.slater at tac.com) Date: Wed, 25 Feb 2009 10:41:30 -0600 Subject: slightly OT: wall mount UPS for demarc In-Reply-To: References: Message-ID: This is what we have used in the past. http://www.apc.com/resource/include/techspec_index.cfm?base_sku=BH500NET Hope that helps. ------------------------------ Date: Wed, 25 Feb 2009 09:57:35 -0500 From: Peter Pauly Subject: slightly OT: wall mount UPS for demarc To: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1 I'm looking to buy several small wall mounted UPS's to power a telco's metro ethernet switches. (Yes, they should have provided some kind of protection, but won't). The closest suitable UPS I've found is this: http://www.tripplite.com/EN/products/model.cfm?txtSeriesID=419&EID=361&t xtModelID=3640 Can anyone suggest a better alternative? I want something sturdy, preferably metal, that can screw to a wall and be worry free for years at a time. From bruns at 2mbit.com Wed Feb 25 10:44:02 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 25 Feb 2009 09:44:02 -0700 Subject: Yahoo and their mail filters.. In-Reply-To: <05e701c99762$eb810460$c2830d20$@com> References: <05e701c99762$eb810460$c2830d20$@com> Message-ID: <49A57552.30506@2mbit.com> On 2/25/09 9:05 AM, Richey wrote: > AOL's Scomp is spam it's self. If I read though 100 messages maybe one > message is really spam. The other 99 are jokes, regular emails, maybe a > news letter from their church, etc. Most people are lazy and would rather > click on the Spam button instead of unsubscribing for a list they subscribed > to in the first place. My favorites for AOL Scomp reports are when people report sub/unsub as spam, then send nasty e-mails 20 minutes later that they either never got confirmation of what they did, or that it never actually removed them. Had one user in particular, who reported mailing list as spam, purged them from said list myself, then 30 mins later signed back up, reported the subscription confirmation as spam, then complained after I removed him again. Not exactly brightest bulb some of them are. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From sauron at the-infinite.org Wed Feb 25 10:47:15 2009 From: sauron at the-infinite.org (Dominic J. Eidson) Date: Wed, 25 Feb 2009 10:47:15 -0600 (CST) Subject: slightly OT: wall mount UPS for demarc In-Reply-To: References: Message-ID: We use a product similar to this: http://www.rackmountsolutions.net/Wallmount_Rack_V_Series.asp - d. On Wed, 25 Feb 2009, ryan.slater at tac.com wrote: > This is what we have used in the past. > > http://www.apc.com/resource/include/techspec_index.cfm?base_sku=BH500NET > > Hope that helps. > > > ------------------------------ > Date: Wed, 25 Feb 2009 09:57:35 -0500 > From: Peter Pauly > Subject: slightly OT: wall mount UPS for demarc > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I'm looking to buy several small wall mounted UPS's to power a telco's > metro ethernet switches. (Yes, they should have provided some kind of > protection, but won't). > > The closest suitable UPS I've found is this: > > http://www.tripplite.com/EN/products/model.cfm?txtSeriesID=419&EID=361&t > xtModelID=3640 > > Can anyone suggest a better alternative? > > I want something sturdy, preferably metal, that can screw to a wall > and be worry free for years at a time. > > > > -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli ---------------------------------------------------------------------------- http://www.dominiceidson.com/ From beckman at angryox.com Wed Feb 25 11:08:11 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed, 25 Feb 2009 12:08:11 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <05e701c99762$eb810460$c2830d20$@com> References: <05e701c99762$eb810460$c2830d20$@com> Message-ID: On Wed, 25 Feb 2009, Richey wrote: > AOL's Scomp is spam it's self. If I read though 100 messages maybe one > message is really spam. The other 99 are jokes, regular emails, maybe a > news letter from their church, etc. Most people are lazy and would rather > click on the Spam button instead of unsubscribing for a list they subscribed > to in the first place. Why the hell can't AOL integrate the standard listserv commands integrated into many subscription emails into a friggin' button in their email client, right next to "Spam" (or even in place of it) that says "Unsubscribe?" I realize it could be used badly if globalized, but if AOL got off their duff and vetted some of the higher volume truly honest subscription emailers and allowed their emails to activate the Spam->Unsub button, it might save everyone some headaches. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From dot at dotat.at Wed Feb 25 11:08:29 2009 From: dot at dotat.at (Tony Finch) Date: Wed, 25 Feb 2009 17:08:29 +0000 Subject: Yahoo and their mail filters.. In-Reply-To: References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> Message-ID: On Wed, 25 Feb 2009, Suresh Ramasubramanian wrote: > > Christ .. Yahoo did say "complaints". And it can take a very low > level of complaints before a block goes into place - especially for > low volume (corporate etc) mailservers. I don't think this is Yahoo reacting to spam complaints because a large number of sites (many universities, for instance) are being affected by this problem at the same time. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From fred at cisco.com Wed Feb 25 11:06:13 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 25 Feb 2009 09:06:13 -0800 Subject: Legislation and its effects in our world In-Reply-To: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> Message-ID: I am not a lawyer; I am a person that can read something that is written in the English language, and considered by some to be a "reasonable man". So please don't consider this to be legal advice. Also, although I am posting from a Cisco account, this note represents my understanding based on a reading of the text of the bill, not an opinion of or advice by Cisco. Further, I do not represent myself as either for or against the legislation or the implied technology. I have opinions on all that, but I'll save them for another email. #include The text of the bill, which is in committee, is at http://www.govtrack.us/congress/billtext.xpd?bill=s111-436 . Read the text of the bill before continuing with my comments on it or on Declan's article. Most of the bill is about defining "child pornography", such as " inserting ?1466A (relating to obscene visual representation of the abuse of children),? before ?section 1708?", or about changing penalties. Data retention is discussed in section 5: > SEC. 5. RETENTION OF RECORDS BY ELECTRONIC COMMUNICATION SERVICE > PROVIDERS. > Section 2703 of title 18, United States Code, is amended by adding > at the end the following: > ?(h) Retention of Certain Records and Information- A provider of an > electronic communication service or remote computing service shall > retain for a period of at least two years all records or other > information pertaining to the identity of a user of a temporarily > assigned network address the service assigns to that user.?. In context, this is about providers of a service. BTW, it doesn't talk about *creating* a record that doesn't exist, it talks about *retaining* records that have already been created, such as billing records or other records that would support billing and maintenance. IANAL, so run this by your lawyers, but a provider of a service is in the FCC definitions someone that sells a service to random purchasers, not someone that provides communications to his own employees, students, or family members. This came up during the discussion by the FCC about lawful intercept and what constituted a network that had to implement it several years ago. This is confirmed, says the "reasonable man", by the definition of the offense in Section 3: > ?(a) Offense- Whoever, being an Internet content hosting provider or > email service provider, knowingly engages in any conduct the > provider knows or has reason to believe facilitates access to, or > the possession of, child pornography (as defined in section 2256) > shall be fined under this title or imprisoned not more than 10 > years, or both. Note the lack of reference to home routers, wireless in any form, or any of the other stuff Declan mentions in his article: > (CNET) -- Republican politicians on Thursday called for a sweeping > new federal law that would require all Internet providers and > operators of millions of Wi-Fi access points, even hotels, local > coffee shops, and home users, to keep records about users for two > years to aid police investigations. I would ask you, how many local coffee shops or hotels that you know of operate their own Internet access? How many instead contract with T- Mobile or some other provider? Since the billing record is done with the provider (you somehow pay a bill to T-Mobile-or-whoever for use of the wifi and you identify yourself to them at the time you access the service), whom would you expect might be required to "retain" those records? I would also be a trifle careful with Declan's repeated references to the party of the person who submitted the bill. The bill is, or at least looks like, enabling legislation required by the Cybercrime Treaty (http://tinyurl.com/6m9ey, Article 20 of which calls for what is now called "Data Retention"), and is pretty much in line with the current EU directive on the topic (http://tinyurl.com/2maatj). Both major parties in the US have been on deck during the negotiation of the CyberCrime Treaty, and whatever your opinion of it might be, this bill is in line with Obama campaign promises and actions as president as I understand them. I personally tend to ignore stuff written by Declan. It requires too much work to drill through the political activism and sensationalism- portrayed-as-journalism to find the germ of truth that inspired the article. On Feb 25, 2009, at 7:06 AM, Jim Willis wrote: > After having a brief conversation with a friend of mine over the > weekend > about this new proposed legislation I was horrified to find that I > could not > dig anything up on it in NANOG. Surely this sort of short minded > legislation > should have been a bit more thought through in its effects on those > that > would have to implement these changes. My major concern is not just > for > myself but for a much broader picture. > > "Republican politicians on Thursday called for a sweeping new > federal law > that would require all Internet providers and operators of millions > of Wi-Fi > access points, even hotels, local coffee shops, and home users, to > keep > records about users for two years to aid police investigations." > > http://www.cnn.com/2009/TECH/02/20/internet.records.bill/index.html > > > I understand and agree that minors should be protected and I think > child > pornography is awful, however I think how the government is going > about > catching these criminals with this new legislation will not really > be any > more efficient than there current methods. Having a log of all IP's > that > come across my or anyone in America's "home" Wi-Fi for two years is > not > going to help "police investigations" but will cause me to have to > go buy a > more expensive router. > > So I'm just wondering, how would this legislation effect some of you > on the > NANOG list? > > -Jim From ops.lists at gmail.com Wed Feb 25 11:14:14 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Feb 2009 22:44:14 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: References: <05e701c99762$eb810460$c2830d20$@com> Message-ID: On Wed, Feb 25, 2009 at 10:38 PM, Peter Beckman wrote: > ?Why the hell can't AOL integrate the standard listserv commands integrated > ?into many subscription emails into a friggin' button in their email > ?client, right next to "Spam" (or even in place of it) that says > ?"Unsubscribe?" Because a lot of spammers would prefer that people simply unsub from their lists rather than they get blocked? And because unsub urls could lead to a lot of nastiness if theres a truly malicious spammer? And because .. [lots of other reasons] There are a few (sender driven) initiatives to move towards a trusted unsubscribe, but .. --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From sethm at rollernet.us Wed Feb 25 11:18:23 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 25 Feb 2009 09:18:23 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: References: <05e701c99762$eb810460$c2830d20$@com> Message-ID: <49A57D5F.1020807@rollernet.us> Peter Beckman wrote: > On Wed, 25 Feb 2009, Richey wrote: > >> AOL's Scomp is spam it's self. If I read though 100 messages maybe one >> message is really spam. The other 99 are jokes, regular emails, maybe a >> news letter from their church, etc. Most people are lazy and would >> rather >> click on the Spam button instead of unsubscribing for a list they >> subscribed >> to in the first place. > > Why the hell can't AOL integrate the standard listserv commands integrated > into many subscription emails into a friggin' button in their email > client, right next to "Spam" (or even in place of it) that says > "Unsubscribe?" > > I realize it could be used badly if globalized, but if AOL got off their > duff and vetted some of the higher volume truly honest subscription > emailers and allowed their emails to activate the Spam->Unsub button, it > might save everyone some headaches. > In a perfect world, the spam button would only affect delivery to that user, not everyone. Especially when they go all rabid click crazy on the spam button for personal correspondence from their mom. ~Seth From ernesto at cs.fiu.edu Wed Feb 25 11:24:14 2009 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Wed, 25 Feb 2009 12:24:14 -0500 Subject: Legislation and its effects in our world In-Reply-To: References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> Message-ID: <6341779B-0FF0-42F1-9B41-862889ABC6C8@cs.fiu.edu> ha, funny you should say that; do a quick search for "plain language of the statute" and let me know how many dissenting views in court opinions you find. Big fallacy to say that even though it's 'plain English' it means *one* thing... This is a big tangled web of statutory and common law; plain English will get you as far as a nickel in a dime store... On Feb 25, 2009, at 12:06 PM, Fred Baker wrote: > I am a person that can read something that is written in the English > language Ernie From mike-nanog at tiedyenetworks.com Wed Feb 25 11:25:38 2009 From: mike-nanog at tiedyenetworks.com (mike) Date: Wed, 25 Feb 2009 09:25:38 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: <49A57D5F.1020807@rollernet.us> References: <05e701c99762$eb810460$c2830d20$@com> <49A57D5F.1020807@rollernet.us> Message-ID: <49A57F12.8000303@tiedyenetworks.com> Seth Mattinen wrote: > > In a perfect world, the spam button would only affect delivery to that > user, not everyone. Especially when they go all rabid click crazy on the > spam button for personal correspondence from their mom. > > > I accuse postini of having exactly this vulnerabillity - that one user classing mail as spam automatically means it marks all other mail from that user to everyone else. There really outta be some transparency here so that everyone understands the how and the why of 'spam' classification. Mike- From dot at dotat.at Wed Feb 25 11:31:34 2009 From: dot at dotat.at (Tony Finch) Date: Wed, 25 Feb 2009 17:31:34 +0000 Subject: Yahoo and their mail filters.. In-Reply-To: <49A57F12.8000303@tiedyenetworks.com> References: <05e701c99762$eb810460$c2830d20$@com> <49A57D5F.1020807@rollernet.us> <49A57F12.8000303@tiedyenetworks.com> Message-ID: On Wed, 25 Feb 2009, mike wrote: > > I accuse postini of having exactly this vulnerabillity - that one user > classing mail as spam automatically means it marks all other mail from that > user to everyone else. There really outta be some transparency here so that > everyone understands the how and the why of 'spam' classification. I like to imagine the consequences of forwarding spam complaints to my users when I can be sure who sent the original message. That ought to reduce the number of people who mark messages from friends / family / colleagues as spam... Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From rcorbin at traffiq.com Wed Feb 25 11:49:21 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Wed, 25 Feb 2009 11:49:21 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: <49A57F12.8000303@tiedyenetworks.com> Message-ID: Maybe its me...but I don't recall seeing a 'this is spam button' for Postini. I know there is an email you can report spam to, but I doubt there is an automated process for it. I have had great success with Postini thus far and have used them for a few years. -r -----Original Message----- From: mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Wednesday, February 25, 2009 12:26 PM To: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. Seth Mattinen wrote: > > In a perfect world, the spam button would only affect delivery to that > user, not everyone. Especially when they go all rabid click crazy on the > spam button for personal correspondence from their mom. > > > I accuse postini of having exactly this vulnerabillity - that one user classing mail as spam automatically means it marks all other mail from that user to everyone else. There really outta be some transparency here so that everyone understands the how and the why of 'spam' classification. Mike- From jeffshultz at wvi.com Wed Feb 25 11:58:20 2009 From: jeffshultz at wvi.com (Jeff Shultz) Date: Wed, 25 Feb 2009 09:58:20 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> Message-ID: <49A586BC.10900@wvi.com> Micheal Patterson wrote: > This may be old news, but I've not been in the list for quite some time. > At any rate, is anyone else having issues with Yahoo blocking / > deferring legitimate emails? > > My situation is that I host our corporate mx'ers on my network, one of > the companies that we recently purchased has Yahoo hosting their domains > mail. Mail traffic to them is getting temporarily deferred with the "421 > 4.7.0 [TS01] Messages from xxx.xxx.xxx.xxx temporarily deferred due to > user complaints - 4.16.55.1; > see http://postmaster.yahoo.com/421-ts01.html" > > The admin of the facility has contacted Yahoo about this but their > response was for "more information" when they were told that traffic > from my mx to their domain was to being deferred. I may end up just > having them migrate to my systems just to maintain company > communications if we can't clear this up in a timely manner. > > -- > Micheal Patterson Yep, it's been happening to us - various explanations - and I've got at least one annoyed customer because of it. -- Jeff Shultz From bzs at world.std.com Wed Feb 25 11:58:39 2009 From: bzs at world.std.com (Barry Shein) Date: Wed, 25 Feb 2009 12:58:39 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> Message-ID: <18853.34511.349131.897690@world.std.com> On February 25, 2009 at 04:26 stefan at csudsu.com (Stefan Molnar) wrote: > For our userbase with yahoo/hotmail/aol accouts they hit the spam button more often than delete. Then complain they do not get emails anymore from us, then want discounts on a bill of sale they missed. It is a never ending story. > I realize this is easier in theory than practice but I wonder how much better the whole AOL (et al) spam button would get if they ignored the spam button unless two (to pick a number) different customers clicked the same sender (I know, forged sender etc but something like that) as spam in a reasonably short amount of time like an hour or a day at most. I know of the 99.99% false positives I get I am pretty sure if the threshold were two related complaints it'd get rid of, well, probably 99.99% of them (percentages not scientifically accurate!) Ok, that's not an algorithm but I hope you see my point. My point is that what makes spam "spam" is not that some one clicks a spam button, it's that more than one person, and just two might be a sufficient threshold in practice, believes it's spam. At least from the POV of a network operator trying to id spam sources from spam button clicks. If they ever get it down to fretting about spams really sent to only one AOL (et al) customer then one could revisit this idea. P.S. I thought about this a little and decided it's more in the realm of network operations than spam per se, the same idea could be applied to any number of customer-reported problems which ripple outwards. It reminds me of years ago when I worked with the Boston Fire Dept and as you ran for the trucks the sure sign there really was a fire was fire alarm shouting over the house loudspeaker "CALLS COMING IN!" which meant hq was getting more than one unrelated report (fire box, phone) in the same general location. Then your heartbeat increased. That is, one call, who knows, two or more unrelated? Must be something. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From chasjs at warp8.com Wed Feb 25 12:18:09 2009 From: chasjs at warp8.com (Chuck Schick) Date: Wed, 25 Feb 2009 11:18:09 -0700 Subject: Yahoo and their mail filters.. In-Reply-To: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> Message-ID: <200902251115977.SM05152@laptop03> We found this issue to be associated usually with users forwarding email to a Yahoo account. If spam slips by our spam filters and gets forwarded where the enduser reports it as spam not realizing the impact on their actions. In the last couple of years we have been not allowing people to forward their accounts to yahoo, aol, hotmail, etc. Too much of a headache. Chuck -----Original Message----- From: Micheal Patterson [mailto:micheal at spmedicalgroup.com] Sent: Tuesday, February 24, 2009 7:28 PM To: nanog at nanog.org Subject: Yahoo and their mail filters.. This may be old news, but I've not been in the list for quite some time. At any rate, is anyone else having issues with Yahoo blocking / deferring legitimate emails? My situation is that I host our corporate mx'ers on my network, one of the companies that we recently purchased has Yahoo hosting their domains mail. Mail traffic to them is getting temporarily deferred with the "421 4.7.0 [TS01] Messages from xxx.xxx.xxx.xxx temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html" The admin of the facility has contacted Yahoo about this but their response was for "more information" when they were told that traffic from my mx to their domain was to being deferred. I may end up just having them migrate to my systems just to maintain company communications if we can't clear this up in a timely manner. -- Micheal Patterson From nancyp at yorku.ca Wed Feb 25 12:16:13 2009 From: nancyp at yorku.ca (nancyp at yorku.ca) Date: Wed, 25 Feb 2009 13:16:13 -0500 Subject: Peering Wars of 1998 Message-ID: <1235585773.49a58aedc1cce@mymail.yorku.ca> Hi, I'm rsrching the Peering Wars of 1998...anyone able to provide info wd be greatly appreciated. Nancy Paterson YorkU From jay at west.net Wed Feb 25 12:19:07 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 25 Feb 2009 10:19:07 -0800 Subject: slightly OT: wall mount UPS for demarc In-Reply-To: References: Message-ID: <49A58B9B.9010702@west.net> Peter Pauly wrote: > I'm looking to buy several small wall mounted UPS's to power a telco's > metro ethernet switches. (Yes, they should have provided some kind of > protection, but won't). > > The closest suitable UPS I've found is this: > > http://www.tripplite.com/EN/products/model.cfm?txtSeriesID=419&EID=361&txtModelID=3640 > > Can anyone suggest a better alternative? > > I want something sturdy, preferably metal, that can screw to a wall > and be worry free for years at a time. Any UPS will have batteries, probably sealed lead-acid for a small UPS. That is likely to negate "worry free for years at a time", especially if wall-mounted in an unconditioned demarc/MPOE closet as opposed to a temperature-controlled data center. At a minimum, plan on an annual visit to do routine maintenance and load test the batteries. You'll be lucky to get more than three years of service out of them. A typical Chatsworth, etc. 19-inch rack shelf available in various depths can be flipped around and screwed to a wall to support many of the stand-alone UPSes. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From micheal at spmedicalgroup.com Wed Feb 25 12:31:16 2009 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Wed, 25 Feb 2009 12:31:16 -0600 Subject: Yahoo and their mail filters.. References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> Message-ID: ----- Original Message ----- From: "Barry Shein" To: Cc: "Suresh Ramasubramanian" ; "Micheal Patterson" ; Sent: Wednesday, February 25, 2009 11:58 AM Subject: Re: Yahoo and their mail filters.. > > On February 25, 2009 at 04:26 stefan at csudsu.com (Stefan Molnar) wrote: > > For our userbase with yahoo/hotmail/aol accouts they hit the spam > > button more often than delete. Then complain they do not get emails > > anymore from us, then want discounts on a bill of sale they missed. > > It is a never ending story. > > > > I realize this is easier in theory than practice but I wonder how much > better the whole AOL (et al) spam button would get if they ignored the > spam button unless two (to pick a number) different customers clicked > the same sender (I know, forged sender etc but something like that) as > spam in a reasonably short amount of time like an hour or a day at > most. > > I know of the 99.99% false positives I get I am pretty sure if the > threshold were two related complaints it'd get rid of, well, probably > 99.99% of them (percentages not scientifically accurate!) > > Ok, that's not an algorithm but I hope you see my point. > > My point is that what makes spam "spam" is not that some one clicks a > spam button, it's that more than one person, and just two might be a > sufficient threshold in practice, believes it's spam. At least from > the POV of a network operator trying to id spam sources from spam > button clicks. > > If they ever get it down to fretting about spams really sent to only > one AOL (et al) customer then one could revisit this idea. > Barry, there's also the honest accidental emailings that are being clicked as spam as well. In the days of old, spam was unsolicited bulk email. The problem that I see currently is what is Sally in Florida is sending mail to joe at thisdomain.com, hosted by yahoo, when they should have sent it to jjoe at thisdomain.com or joel at thisdomain.com and the recipient clicks it as spam. Bam, Sally's now a spammer in the eyes of yahoo. This is not much different in practice than what Spews used to do. Blow out an entire /16 to stop what they "percieved" as spam from someone deep in the trenches, without very little recourse to remove yourself from the axe path unless you switched providers. -- Micheal Patterson From mike-nanog at tiedyenetworks.com Wed Feb 25 12:42:02 2009 From: mike-nanog at tiedyenetworks.com (mike) Date: Wed, 25 Feb 2009 10:42:02 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: <18853.34511.349131.897690@world.std.com> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> Message-ID: <49A590FA.5060700@tiedyenetworks.com> Barry Shein wrote: > I realize this is easier in theory than practice but I wonder how much > better the whole AOL (et al) spam button would get if they ignored the > spam button unless two (to pick a number) different customers clicked > the same sender (I know, forged sender etc but something like that) as > spam in a reasonably short amount of time like an hour or a day at > most. > Well there's a problem with that too. Lets say that you happen to need to deal with various office workers, who just happen to be the kind of folks who hold the public they serve in low regard and high contempt. Lets further say that these office workers feel no obligation to obey the law or demonstrate any consideration whatsoever for you or the trouble their callous inconsideration actions have caused you, requiring that you repeatedly and persistiently make contact and state your case. Lets further say that these same office workers - who are incompetent functionaries bewildered by that pointy thing on the screen and have zero forethought about the consequences of their actions - decide it's easier to deal with you by clicking 'spam' repeatedly instead of engaging in that conversation and working twords a resolution of the problem you need to report. We forget here on nanog that our list participants are (usually) high functioning people with substantial computer, technical, communications experience and who approach their personal communications a lot differently than the average 'end user', who has difficulty even finding the 'on' button let alone using it to any great effect. I run into the above described office worker stereotype on a frequent basis (the bearer of bad news, or having to represent someone or some cause) and the default action - spam - is almost universal amoungst these types. Just because THEY say it's spam, doesn't mean a whole lot of anything other than maybe you interrupted their coffee break or it would be too much work and maybe someone else will get the message so they don't have to do anything. The idea of using a group of users to effectively 'vote' only works when the group in question is comprised of reasonable people, and unfortunately, freemail users and office workers 'protected by postini' are the least likely candidates to make reasonable choices with votes for spam..... $0.02 Mike- From jcdill.lists at gmail.com Wed Feb 25 12:44:13 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 25 Feb 2009 10:44:13 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> Message-ID: <49A5917D.8080301@gmail.com> Tony Finch wrote: > On Wed, 25 Feb 2009, Suresh Ramasubramanian wrote: > >> Christ .. Yahoo did say "complaints". And it can take a very low >> level of complaints before a block goes into place - especially for >> low volume (corporate etc) mailservers. >> > > I don't think this is Yahoo reacting to spam complaints because a large > number of sites (many universities, for instance) are being affected by > this problem at the same time. Universities are often major sources of spam. Spam is sent directly from virus-infected student computers, and spam is also sent to students at their university email address and then .forwarded on to the student's outside (or post-university) email account - when the student receives forwarded spam at their Yahoo account and clicks "this is spam" the university is considered the "source" of the spam. jc From micheal at spmedicalgroup.com Wed Feb 25 13:03:42 2009 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Wed, 25 Feb 2009 13:03:42 -0600 Subject: Yahoo and their mail filters.. References: <200902251115977.SM05152@laptop03> Message-ID: ----- Original Message ----- From: "Chuck Schick" To: Sent: Wednesday, February 25, 2009 12:18 PM Subject: RE: Yahoo and their mail filters.. > We found this issue to be associated usually with users forwarding > email to > a Yahoo account. If spam slips by our spam filters and gets forwarded > where > the enduser reports it as spam not realizing the impact on their > actions. > > In the last couple of years we have been not allowing people to > forward > their accounts to yahoo, aol, hotmail, etc. Too much of a headache. > > Chuck > I could see that if my situation was where I was forwarding to a personal yahoo account, but these are business customers that aren't able to whitelist who they recieve email from. I just checked in their domain panel and see no options of setting any whitelisting or spam settings in the yahoo's business email control panel. My current solution is to just move their email away from yahoo competely and just host it here with the rest of my corporate email users. -- Micheal Patterson From Valdis.Kletnieks at vt.edu Wed Feb 25 13:17:14 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 25 Feb 2009 14:17:14 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: Your message of "Wed, 25 Feb 2009 10:44:13 PST." <49A5917D.8080301@gmail.com> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> <49A5917D.8080301@gmail.com> Message-ID: <140953.1235589434@turing-police.cc.vt.edu> On Wed, 25 Feb 2009 10:44:13 PST, JC Dill said: > Universities are often major sources of spam. Spam is sent directly > from virus-infected student computers, Got any numbers to back up the claim that virus-infected student computers are anywhere near the problem that virus-infected student's-parents computers are? (I'm not saying universities are perfect - we have to nuke several users a day because their accounts or machines fall under enemy control. But I see a lot of people repeating the meme without any numbers to back it up) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From smb at cs.columbia.edu Wed Feb 25 13:55:59 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 25 Feb 2009 14:55:59 -0500 Subject: Legislation and its effects in our world In-Reply-To: References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> Message-ID: <20090225145559.115ef97b@cs.columbia.edu> On Wed, 25 Feb 2009 09:06:13 -0800 Fred Baker wrote: > Data retention is discussed in section 5: > > > SEC. 5. RETENTION OF RECORDS BY ELECTRONIC COMMUNICATION SERVICE > > PROVIDERS. > > Section 2703 of title 18, United States Code, is amended by adding > > at the end the following: > > ?(h) Retention of Certain Records and Information- A provider of > > an electronic communication service or remote computing service > > shall retain for a period of at least two years all records or > > other information pertaining to the identity of a user of a > > temporarily assigned network address the service assigns to that > > user.?. Doing a thorough analysis of this bill is on my to-do list, possibly for a flight home on Friday. For now, I think the applicability remains ambiguous, because it's amending a law that was written ~25 years ago, when the concept of home computers was fairly new, let alone home providers of services... That said -- the definitions for 18 USC 2703 are in 18 USC 2510 (http://www4.law.cornell.edu/uscode/18/2510.html) and 18 USC 2711 (http://www4.law.cornell.edu/uscode/18/usc_sec_18_00002711----000-.html). The former includes the following: (15) ?electronic communication service? means any service which provides to users thereof the ability to send or receive wire or electronic communications; the latter says (2) the term ?remote computing service? means the provision to the public of computer storage or processing services by means of an electronic communications system; Now -- the remote computing definition includes "to the public", which pretty clearly excludes home users. The definition of "electronic communication service? is not limited to those serving "the public". In other parts of the statute, the phrase "to the public" is sometimes used, sometimes not; see, for example, 18 USC 2511(2)(a)(i) and 18 USC 2702(a)(1). I'm not a lawyer, either, but as I understand things where parts of a statute use a qualifier and parts don't the courts tend to conclude that Congress knew what it was doing when it differentiated the two cases. --Steve Bellovin, http://www.cs.columbia.edu/~smb From beckman at angryox.com Wed Feb 25 14:28:46 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed, 25 Feb 2009 15:28:46 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: References: <05e701c99762$eb810460$c2830d20$@com> Message-ID: On Wed, 25 Feb 2009, Suresh Ramasubramanian wrote: > On Wed, Feb 25, 2009 at 10:38 PM, Peter Beckman wrote: >> ?Why the hell can't AOL integrate the standard listserv commands integrated >> ?into many subscription emails into a friggin' button in their email >> ?client, right next to "Spam" (or even in place of it) that says >> ?"Unsubscribe?" > > Because a lot of spammers would prefer that people simply unsub from > their lists rather than they get blocked? > > And because unsub urls could lead to a lot of nastiness if theres a > truly malicious spammer? > > And because .. [lots of other reasons] > > On Wed, Feb 25, 2009 at 10:38 PM, Peter Beckman ALSO wrote: >> I realize it could be used badly if globalized, but if AOL got off their >> duff and vetted some of the higher volume truly honest subscription >> emailers and allowed their emails to activate the Spam->Unsub button, it >> might save everyone some headaches. As I said (but you clipped), the suggestion could (and would likely) be abused if turned on globally, but if AOL vetted some of the more popular subscription mailings where people were clicking spam rather than unsubscribe for trusted sources, it could work. > There are a few (sender driven) initiatives to move towards a trusted > unsubscribe, but .. I think in order for an Unsubscribe button to be implemented by Gmail, Yahoo, AOL, etc, there would have to be some sort of internally reviewed list of trusted senders for which each company had a mail admin contact for (technical implementation not applicable for this discussion). Working together to communicate openly about subscription email with trusted parties would help (in theory) to reduce the effects of clueless end users who lazily click "Spam" and cause headaches for both senders and receivers of legitimate subscription email. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From ge at linuxbox.org Wed Feb 25 14:35:14 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 25 Feb 2009 14:35:14 -0600 (CST) Subject: [ MDVSA-2009:054 ] nagios (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 25 Feb 2009 01:05:01 +0100 From: security at mandriva.com Reply-To: xsecurity at mandriva.com To: bugtraq at securityfocus.com Subject: [ MDVSA-2009:054 ] nagios -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 _______________________________________________________________________ Mandriva Linux Security Advisory MDVSA-2009:054 http://www.mandriva.com/security/ _______________________________________________________________________ Package : nagios Date : February 24, 2009 Affected: Corporate 4.0 _______________________________________________________________________ Problem Description: A vulnerability has been identified and corrected in nagios: Cross-site scripting (XSS) vulnerability in Nagios allows remote attackers to inject arbitrary web script or HTML via unknown vectors, a different vulnerability than CVE-2007-5624 and CVE-2008-1360 (CVE-2007-5803). The updated packages have been upgraded to the latest version of nagios to prevent this. _______________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5803 _______________________________________________________________________ Updated Packages: Corporate 4.0: 2f4eff0f154fb6b5470d1cb0fad177be corporate/4.0/i586/nagios-3.1.0-0.1.20060mlcs4.i586.rpm 97dd676d23af47a198b4d7d8a4a98772 corporate/4.0/i586/nagios-devel-3.1.0-0.1.20060mlcs4.i586.rpm 19658855978419d653aa3ad103d4a202 corporate/4.0/i586/nagios-theme-default-3.1.0-0.1.20060mlcs4.i586.rpm a6f6d5a202d2261977fc45fb5f0cf239 corporate/4.0/i586/nagios-www-3.1.0-0.1.20060mlcs4.i586.rpm 810578c6a17cd25e2c4b5c08f5363111 corporate/4.0/SRPMS/nagios-3.1.0-0.1.20060mlcs4.src.rpm Corporate 4.0/X86_64: fcca43b9dfedae723b76beee215b4ae4 corporate/4.0/x86_64/nagios-3.1.0-0.1.20060mlcs4.x86_64.rpm f6051010aa536ff0943693e29a86dfea corporate/4.0/x86_64/nagios-devel-3.1.0-0.1.20060mlcs4.x86_64.rpm 485776dee99e096ce00e34a90f9b4af5 corporate/4.0/x86_64/nagios-theme-default-3.1.0-0.1.20060mlcs4.x86_64.rpm 3eecf54904721ef8ce9fb3c75a40be66 corporate/4.0/x86_64/nagios-www-3.1.0-0.1.20060mlcs4.x86_64.rpm 810578c6a17cd25e2c4b5c08f5363111 corporate/4.0/SRPMS/nagios-3.1.0-0.1.20060mlcs4.src.rpm _______________________________________________________________________ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com _______________________________________________________________________ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJpGCOmqjQ0CJFipgRAu5OAJ9wt+wnm65Wvz1Nq7lumj/V6yvHVwCeO+6U efZ1ppeQ7XVjLx+IIeP8XjQ= =Vi1C -----END PGP SIGNATURE----- From jeremy at hq.newdream.net Wed Feb 25 14:43:23 2009 From: jeremy at hq.newdream.net (Jeremy Hanmer) Date: Wed, 25 Feb 2009 12:43:23 -0800 Subject: Anybody from Godaddy abuse? Message-ID: <9C1C392C-4FA2-4062-8A2D-41FF625359CD@hq.newdream.net> Can somebody from Godaddy contact me off-list about a malicious domain errantly listing our network as its DNS servers? Email to abuse at godaddy has gone unanswered and we're getting hit pretty hard. From chort at smtps.net Wed Feb 25 14:47:41 2009 From: chort at smtps.net (Brian Keefer) Date: Wed, 25 Feb 2009 12:47:41 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> Message-ID: <797BD373-3542-4E32-AA24-D22B787F0544@smtps.net> On Feb 24, 2009, at 6:27 PM, Micheal Patterson wrote: > This may be old news, but I've not been in the list for quite some > time. At any rate, is anyone else having issues with Yahoo > blocking / deferring legitimate emails? > > My situation is that I host our corporate mx'ers on my network, one > of the companies that we recently purchased has Yahoo hosting their > domains mail. Mail traffic to them is getting temporarily deferred > with the "421 4.7.0 [TS01] Messages from xxx.xxx.xxx.xxx temporarily > deferred due to user complaints - 4.16.55.1; > see http://postmaster.yahoo.com/421-ts01.html" > > The admin of the facility has contacted Yahoo about this but their > response was for "more information" when they were told that traffic > from my mx to their domain was to being deferred. I may end up just > having them migrate to my systems just to maintain company > communications if we can't clear this up in a timely manner. > > -- > Micheal Patterson A few comments on this thread in general (speaking only for myself, not in any way representing my employer)... Yes, Yahoo! tend to throttle IPs at the drop of a hat, but those blocks are often gone in a few hours as well. Others have pointed out some procedures to follow to minimize the possibility of being blocked. At least they give you a useable SMTP error (usually). Incidentally this is why all my test accounts are on Gmail, because delivery to Yahoo! is often deferred for minutes to hours. Of course, given the recent Gmail outages I might have to diversify even more... As for "blackholes" that messages fall into, what is the alternative? You could say reject it in session with a readable error, but that would give spammers instant confirmation on whether their campaign is working. Also, the majority of anti-spam products I've seen have to spool the message before they scan it, so rejecting in session is simply not an option on a lot of commercial platforms. The other options is to stuff all the spam messages in a folder and expose them to the user, taking up a huge amount of storage space for something the vast majority of users are never going to look at any way. Again, a lot of commercial solutions have a scoring methodology where you can be pretty certain stuff at the top end of the scale is virtually never going to be a false positive. The amount of savings in not having to handle and store that crud massively outweighs one or two users missing a newsletter once in a while. It can make sense to expose the "mid-range spam" to users and let them decide, but why store terabytes of stuff that only a tiny fraction of the users may ever care about? If you're sending important mail that's not reaching the recipient, and you have the server logs to prove you handed it off to the destination MTA, open a ticket with them and they'll have logs to track it down. Regarding taking automatic action based on luser feedback, that is ridiculous in my opinion. From the data I see, the lusers classify mail incorrectly far more than correctly. In fact there's a running joke around here that we should simply flip the false-positive and false-negative feeds and enable auto-train, since the only thing you can reliably count on users to do is get things wrong. Submissions from administrators are _far_ more accurate (although even then, not to the point that it always makes sense to take automatic action). Blocking an entire site just because one John Doe user clicked a button they don't even understand just does not make sense. Last, anywhere that I've seen extensive use of forwards has had a maze of difficult to untangle abuse problems related to forwarded spam. Any site allowing forwarding should apply very robust filtering of outbound mail. -- bk From johnl at iecc.com Wed Feb 25 14:54:42 2009 From: johnl at iecc.com (John Levine) Date: 25 Feb 2009 20:54:42 -0000 Subject: Yahoo and their mail filters.. In-Reply-To: Message-ID: <20090225205442.98208.qmail@simone.iecc.com> > Why the hell can't AOL integrate the standard listserv commands > integrated into many subscription emails into a friggin' button in > their email client, right next to "Spam" (or even in place of it) > that says "Unsubscribe?" AOL sends its spam button feedback in industry standard ARF format. It took me about 20 minutes to write a perl script that picks out the relevant bits from AOL and Hotmail feedback messages and sends unsub commands to my list manager. As to why they don't have a separate Unsub button, users wouldn't use it. AOL are not stupid, they know that people hit the spam button for all sorts of reasons, many of which have only the vaguest connection to spam. If you run a small well-run network, the only stuff you're going to see from the spam button is unsubs and false alarms. That doesn't mean the spam button is broken; it means that you're not the kind of sender they're worried about. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From rcorbin at traffiq.com Wed Feb 25 15:05:30 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Wed, 25 Feb 2009 15:05:30 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: <797BD373-3542-4E32-AA24-D22B787F0544@smtps.net> Message-ID: Outbound filtering is a good idea..however after investing lots of money on hardware appliances (old company $100,000 on equipment to do just this...) you realize you have more issues then solutions. Now you allow forwarded mail, and as you stated most systems accept the messages into the queue process the message and then either bounce/quarentine/allow. You can't bounce the message because it goes back to the sender which is almost always spoofed and thus you create backscatter. You cant quarentine because then you may flag some of your customers legitimate email. Isolating your forwarded mail to a separate ip address is really, I think, the best way to handel forwarded mail. -r -----Original Message----- From: Brian Keefer [mailto:chort at smtps.net] Sent: Wednesday, February 25, 2009 3:48 PM To: Micheal Patterson Cc: nanog at nanog.org Subject: Re: Yahoo and their mail filters.. On Feb 24, 2009, at 6:27 PM, Micheal Patterson wrote: > This may be old news, but I've not been in the list for quite some > time. At any rate, is anyone else having issues with Yahoo blocking / > deferring legitimate emails? > > My situation is that I host our corporate mx'ers on my network, one of > the companies that we recently purchased has Yahoo hosting their > domains mail. Mail traffic to them is getting temporarily deferred > with the "421 4.7.0 [TS01] Messages from xxx.xxx.xxx.xxx temporarily > deferred due to user complaints - 4.16.55.1; see > http://postmaster.yahoo.com/421-ts01.html" > > The admin of the facility has contacted Yahoo about this but their > response was for "more information" when they were told that traffic > from my mx to their domain was to being deferred. I may end up just > having them migrate to my systems just to maintain company > communications if we can't clear this up in a timely manner. > > -- > Micheal Patterson A few comments on this thread in general (speaking only for myself, not in any way representing my employer)... Yes, Yahoo! tend to throttle IPs at the drop of a hat, but those blocks are often gone in a few hours as well. Others have pointed out some procedures to follow to minimize the possibility of being blocked. At least they give you a useable SMTP error (usually). Incidentally this is why all my test accounts are on Gmail, because delivery to Yahoo! is often deferred for minutes to hours. Of course, given the recent Gmail outages I might have to diversify even more... As for "blackholes" that messages fall into, what is the alternative? You could say reject it in session with a readable error, but that would give spammers instant confirmation on whether their campaign is working. Also, the majority of anti-spam products I've seen have to spool the message before they scan it, so rejecting in session is simply not an option on a lot of commercial platforms. The other options is to stuff all the spam messages in a folder and expose them to the user, taking up a huge amount of storage space for something the vast majority of users are never going to look at any way. Again, a lot of commercial solutions have a scoring methodology where you can be pretty certain stuff at the top end of the scale is virtually never going to be a false positive. The amount of savings in not having to handle and store that crud massively outweighs one or two users missing a newsletter once in a while. It can make sense to expose the "mid-range spam" to users and let them decide, but why store terabytes of stuff that only a tiny fraction of the users may ever care about? If you're sending important mail that's not reaching the recipient, and you have the server logs to prove you handed it off to the destination MTA, open a ticket with them and they'll have logs to track it down. Regarding taking automatic action based on luser feedback, that is ridiculous in my opinion. From the data I see, the lusers classify mail incorrectly far more than correctly. In fact there's a running joke around here that we should simply flip the false-positive and false-negative feeds and enable auto-train, since the only thing you can reliably count on users to do is get things wrong. Submissions from administrators are _far_ more accurate (although even then, not to the point that it always makes sense to take automatic action). Blocking an entire site just because one John Doe user clicked a button they don't even understand just does not make sense. Last, anywhere that I've seen extensive use of forwards has had a maze of difficult to untangle abuse problems related to forwarded spam. Any site allowing forwarding should apply very robust filtering of outbound mail. -- bk From beckman at angryox.com Wed Feb 25 15:08:16 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed, 25 Feb 2009 16:08:16 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <20090225205442.98208.qmail@simone.iecc.com> References: <20090225205442.98208.qmail@simone.iecc.com> Message-ID: On Wed, 25 Feb 2009, John Levine wrote: >> Why the hell can't AOL integrate the standard listserv commands >> integrated into many subscription emails into a friggin' button in >> their email client, right next to "Spam" (or even in place of it) >> that says "Unsubscribe?" > > AOL sends its spam button feedback in industry standard ARF format. It > took me about 20 minutes to write a perl script that picks out the > relevant bits from AOL and Hotmail feedback messages and sends unsub > commands to my list manager. > > As to why they don't have a separate Unsub button, users wouldn't use > it. AOL are not stupid, they know that people hit the spam button for > all sorts of reasons, many of which have only the vaguest connection > to spam. If you run a small well-run network, the only stuff you're > going to see from the spam button is unsubs and false alarms. That > doesn't mean the spam button is broken; it means that you're not the > kind of sender they're worried about. Cool! Didn't know that. My props to AOL and Hotmail for making it easier for mail admins to deal with claims of spam. Your point on "Users wouldn't Use it" makes sense, they wouldn't. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From zaid at zaidali.com Wed Feb 25 15:08:30 2009 From: zaid at zaidali.com (Zaid Ali) Date: Wed, 25 Feb 2009 13:08:30 -0800 (PST) Subject: Yahoo and their mail filters.. In-Reply-To: Message-ID: <16345866.471235596107668.JavaMail.zaid@turing-2.local> I think a major reason why recipients click the 'Spam' button is because often times its not obvious how to identify the opt out link in the email. You can perhaps put the opt out link on the top of the email so that the user clicks that instead of the 'Spam' button. There is also the issue of weather the user trusts the opt out link, I have been in discussions where data shows that most users don't generally trust it. On the subject of feedback loop I think that if you sign up to receive FBL emails then you must do something about it. I think its useless to sign up for FBL's and not take any action because ESP's monitor FBL rate so if they feel that you are not taking action then you can expect to see your emails go to a junk folder or be subjected to greylisting. Zaid ----- Original Message ----- From: "Peter Beckman" To: "Suresh Ramasubramanian" Cc: nanog at nanog.org Sent: Wednesday, February 25, 2009 12:28:46 PM GMT -08:00 US/Canada Pacific Subject: Re: Yahoo and their mail filters.. On Wed, 25 Feb 2009, Suresh Ramasubramanian wrote: > On Wed, Feb 25, 2009 at 10:38 PM, Peter Beckman wrote: >> ?Why the hell can't AOL integrate the standard listserv commands integrated >> ?into many subscription emails into a friggin' button in their email >> ?client, right next to "Spam" (or even in place of it) that says >> ?"Unsubscribe?" > > Because a lot of spammers would prefer that people simply unsub from > their lists rather than they get blocked? > > And because unsub urls could lead to a lot of nastiness if theres a > truly malicious spammer? > > And because .. [lots of other reasons] > > On Wed, Feb 25, 2009 at 10:38 PM, Peter Beckman ALSO wrote: >> I realize it could be used badly if globalized, but if AOL got off their >> duff and vetted some of the higher volume truly honest subscription >> emailers and allowed their emails to activate the Spam->Unsub button, it >> might save everyone some headaches. As I said (but you clipped), the suggestion could (and would likely) be abused if turned on globally, but if AOL vetted some of the more popular subscription mailings where people were clicking spam rather than unsubscribe for trusted sources, it could work. > There are a few (sender driven) initiatives to move towards a trusted > unsubscribe, but .. I think in order for an Unsubscribe button to be implemented by Gmail, Yahoo, AOL, etc, there would have to be some sort of internally reviewed list of trusted senders for which each company had a mail admin contact for (technical implementation not applicable for this discussion). Working together to communicate openly about subscription email with trusted parties would help (in theory) to reduce the effects of clueless end users who lazily click "Spam" and cause headaches for both senders and receivers of legitimate subscription email. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From marquis at roble.com Wed Feb 25 15:21:57 2009 From: marquis at roble.com (Roger Marquis) Date: Wed, 25 Feb 2009 13:21:57 -0800 (PST) Subject: Yahoo and their mail filters... In-Reply-To: References: Message-ID: <20090225212157.74F962B208D@mx5.roble.com> Brian Keefer wrote: > Regarding taking automatic action based on luser feedback, that is > ridiculous in my opinion. It is that i.e., non-standard, but no more than many other things at Y! Many of their internal mailing lists, for internal use only, get more spam than actual mail. Just another example of profound extent of deferred maintenance that handicaps so much of what Yahoo does. Their new CEO knows this and is capable of addressing it. Look for changes soon, mostly to mid-level managers hired during the Semel years, managers who failed to keep their technical skills up to date. Roger Marquis From mis at seiden.com Wed Feb 25 11:56:32 2009 From: mis at seiden.com (mark seiden-via mac) Date: Wed, 25 Feb 2009 09:56:32 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> Message-ID: <95C9C2E2-4932-431A-BF06-DCB8267024D6@seiden.com> that could occur when a. student machines are botted (for institutions not blocking outbound port 25) b. student and alumni accounts are compromised by phishers (both of these just for the purposes of sending spam from well connected, reputable institutions.) and then consumers really do complain... i'm told (not just by yahoo insiders) that the forms at postmaster.yahoo.com actually do work, eventually. On Feb 25, 2009, at 9:08 AM, Tony Finch wrote: > On Wed, 25 Feb 2009, Suresh Ramasubramanian wrote: >> >> Christ .. Yahoo did say "complaints". And it can take a very low >> level of complaints before a block goes into place - especially for >> low volume (corporate etc) mailservers. > > I don't think this is Yahoo reacting to spam complaints because a > large > number of sites (many universities, for instance) are being affected > by > this problem at the same time. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY > SHOWERS. > MODERATE OR GOOD. > > From chort at smtps.net Wed Feb 25 15:37:29 2009 From: chort at smtps.net (Brian Keefer) Date: Wed, 25 Feb 2009 13:37:29 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: <16345866.471235596107668.JavaMail.zaid@turing-2.local> References: <16345866.471235596107668.JavaMail.zaid@turing-2.local> Message-ID: <7F2E53DA-2A67-4304-AF8B-992E3100207F@smtps.net> On Feb 25, 2009, at 1:08 PM, Zaid Ali wrote: > There is also the issue of weather the user trusts the opt out link, > I have been in discussions where data shows that most users don't > generally trust it. > > Zaid Nor should they. Anyone who actually researches this stuff knows that the vast majority of "unsub" links simply confirm you as a live target who will click on random links sent to them through e-mail. Incidentally, what option is specified by the CAN-SPAM act? Oh yeah, opt-out. Genius. You will never be able to educate the masses on the difference between a legit unsub link and a malicious one. The safest thing for lusers is to ignore them all. It would be nice if the webmail providers simply mapped the "report spam" function to "add sender to personal blacklist", that way lusers who report their mailing list as spam would simply stop seeing it. Unfortunately that would also result in a lot more storage requirements on the part of said webmail providers, which is probably a major reason why they don't do it. Frankly the best approach is probably to make "report as spam" a NOP. Users get it wrong the vast majority of the time. Automated honeypot analysis with oversight from clueful e-mail operators is the best way to handle uncaught spam. -- bk From carlos at race.com Wed Feb 25 15:38:37 2009 From: carlos at race.com (Carlos Alcantar) Date: Wed, 25 Feb 2009 13:38:37 -0800 Subject: Yahoo and their mail filters.. Message-ID: <859604546CD1FF488BDB6EA94C896AFB592F7F@racexchange.race.local> We ran into this issue where we where tagging emails with ***SPAM*** and forwarding them on which got us blocked everyone once in a while pretty annoying. Carlos -----Original Message----- From: Chuck Schick [mailto:chasjs at warp8.com] Sent: Wednesday, February 25, 2009 10:18 AM To: nanog at nanog.org Subject: RE: Yahoo and their mail filters.. We found this issue to be associated usually with users forwarding email to a Yahoo account. If spam slips by our spam filters and gets forwarded where the enduser reports it as spam not realizing the impact on their actions. In the last couple of years we have been not allowing people to forward their accounts to yahoo, aol, hotmail, etc. Too much of a headache. Chuck From eric at nixwizard.net Wed Feb 25 15:40:03 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Wed, 25 Feb 2009 14:40:03 -0700 Subject: [ MDVSA-2009:054 ] nagios (fwd) In-Reply-To: References: Message-ID: <5792267e0902251340q68a1745cqbc87c2fcf8afa805@mail.gmail.com> On Wed, Feb 25, 2009 at 1:35 PM, Gadi Evron wrote: > > > ---------- Forwarded message ---------- > Date: Wed, 25 Feb 2009 01:05:01 +0100 > From: security at mandriva.com > Reply-To: xsecurity at mandriva.com > To: bugtraq at securityfocus.com > Subject: [ MDVSA-2009:054 ] nagios > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ?_______________________________________________________________________ > > ?Mandriva Linux Security Advisory ? ? ? ? ? ? ? ? ? ? ? ? MDVSA-2009:054 > ?http://www.mandriva.com/security/ > ?_______________________________________________________________________ > > ?Package : nagios > ?Date ? ?: February 24, 2009 > ?Affected: Corporate 4.0 I hate to be pedantic but is this something that should get forwarded to NANOG? I guess the relevance is justified because a lot of network folks run Nagios...? -- Eric http://nixwizard.net From jbates at brightok.net Wed Feb 25 16:00:00 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 25 Feb 2009 16:00:00 -0600 Subject: [ MDVSA-2009:054 ] nagios (fwd) In-Reply-To: <5792267e0902251340q68a1745cqbc87c2fcf8afa805@mail.gmail.com> References: <5792267e0902251340q68a1745cqbc87c2fcf8afa805@mail.gmail.com> Message-ID: <49A5BF60.8070401@brightok.net> Eric Gearhart wrote: > I hate to be pedantic but is this something that should get forwarded > to NANOG? I guess the relevance is justified because a lot of network > folks run Nagios...? No, it's offtopic. I mean, CVE-2007-5803? Really? Even stranger, they mention a CVE which is 2.x based, and then upgrade the 3.1 packages. heh. I'm not sure who's slipping, mandriva or Gadi. Jack From j at arpa.com Wed Feb 25 16:23:02 2009 From: j at arpa.com (jamie rishaw) Date: Wed, 25 Feb 2009 16:23:02 -0600 Subject: [ MDVSA-2009:054 ] nagios (fwd) In-Reply-To: <49A5BF60.8070401@brightok.net> References: <5792267e0902251340q68a1745cqbc87c2fcf8afa805@mail.gmail.com> <49A5BF60.8070401@brightok.net> Message-ID: srsly? I didnt find this OT, considering its scope. Want to dictate policy? Join the MLC. Till then, /dev/null thx On Wed, Feb 25, 2009 at 4:00 PM, Jack Bates wrote: pew pew > Eric Gearhart wrote: > pew pew pew -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From ops.lists at gmail.com Wed Feb 25 19:25:03 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Feb 2009 06:55:03 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: <18853.34511.349131.897690@world.std.com> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> Message-ID: On Wed, Feb 25, 2009 at 11:28 PM, Barry Shein wrote: > I realize this is easier in theory than practice but I wonder how much > better the whole AOL (et al) spam button would get if they ignored the > spam button unless two (to pick a number) different customers clicked > the same sender (I know, forged sender etc but something like that) as > spam in a reasonably short amount of time like an hour or a day at > most. .. and you think AOL doesnt track these? Come on, barry - try to give large mailops shops with massive userbases some credit for clue level. You have all the clue in the world but you dont even begin to guess at the firehose AOL / Yahoo / we etc have to deal with. Or what we routinely do, as a matter of best practice. I wont claim perfection, infallibility etc for any of the big 3 (hotmail / yahoo / aol) or even for us (large enough - 76 million users we filter for, 40 million of which we host). But a user report based spam reporting system works quite well on the aggregate. And yes, legitimate outfits can wind up blocked (universities because of unfiltered machines on campus, and because of nigerians / phishers hacking user accounts, webhosts because of hacked scripts, or because they end up hosting a high volume spammer in part of a /24 with legit customers near him ..) One thing that may need to be improved at one place or the other is false positive handling - make that faster and more efficient, and also publish the "unblock contact path" in block messages you issue, and you would find a lot of the gripes getting resolved. To some extent anyway. Postmaster work is a place for people with decent mailops / routing skills, yes - but far more than that, it is for people with both soft skills for customer service plus a finely tuned b.s detector. It is complex, and far too long for nanog .. took maawg three or four brainstorming sessions over a year to discuss. http://www.maawg.org/about/publishedDocuments/Abuse_Desk_Common_Practices.pdf And then some others relevant to this thread - http://www.maawg.org/about/publishedDocuments/MAAWG_Email_Forwarding_BP.pdf http://www.maawg.org/port25 http://www.maawg.org/about/publishedDocuments/MAAWG_AWPG_Anti_Phishing_Best_Practices.pdf http://www.maawg.org/about/publishedDocuments --srs From paulv at canonical.org Wed Feb 25 20:36:57 2009 From: paulv at canonical.org (Paul Visscher) Date: Wed, 25 Feb 2009 21:36:57 -0500 Subject: ethr.net contact? Message-ID: <20090226023657.GA8110@canonical.org> Can someone from ethr.net please contact me off list? Thanks, --paulv From eric at nixwizard.net Wed Feb 25 20:51:35 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Wed, 25 Feb 2009 19:51:35 -0700 Subject: [ MDVSA-2009:054 ] nagios (fwd) In-Reply-To: References: <5792267e0902251340q68a1745cqbc87c2fcf8afa805@mail.gmail.com> <49A5BF60.8070401@brightok.net> Message-ID: <5792267e0902251851q6fe4c854hb757dcfcf16c5c57@mail.gmail.com> On Wed, Feb 25, 2009 at 3:23 PM, jamie rishaw wrote: > srsly? > > I didnt find this OT, considering its scope. > > Want to dictate policy? Join the MLC. > > Till then, /dev/null > > thx Thanks for the professional response there bud From bzs at world.std.com Wed Feb 25 21:29:23 2009 From: bzs at world.std.com (Barry Shein) Date: Wed, 25 Feb 2009 22:29:23 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> Message-ID: <18854.3219.454176.970127@world.std.com> On February 26, 2009 at 06:55 ops.lists at gmail.com (Suresh Ramasubramanian) wrote: > On Wed, Feb 25, 2009 at 11:28 PM, Barry Shein wrote: > > > I realize this is easier in theory than practice but I wonder how much > > better the whole AOL (et al) spam button would get if they ignored the > > spam button unless two (to pick a number) different customers clicked > > the same sender (I know, forged sender etc but something like that) as > > spam in a reasonably short amount of time like an hour or a day at > > most. > > .. and you think AOL doesnt track these? Come on, barry - try to give > large mailops shops with massive userbases some credit for clue level. I have no idea what they track and it's completely irrelevant. We get a steady stream of "spam" complaints from the AOL feedback loop which is virtually all either (we assume) unsubscriptions from legitimate mailing lists or random misfires, "it was nice seeing you and dad last week" From joe blow, To susie blow, which just probably isn't spam. Now, if you're still following, none (or a microscopic amt) of that would pass the "complaints came from two different sources in a fairly short amount of time" sniff test I proposed. If you track it and don't use it, well, tree falling in the forest and all that. I can see with my own eyes that nothing like this is being done. As far as I can tell from here, and other sites may see it diffferently, the feedback thing is mostly just a "please unsubscribe me from this mailing list I subscribed to and can't remember how to get off" and the occasional "oops, hit the spam button on mom's mail, oh well!" > You have all the clue in the world but you dont even begin to guess > at the firehose AOL / Yahoo / we etc have to deal with. Or what we > routinely do, as a matter of best practice. Nor is it my problem. Why should my staff and I spend valuable time subsidizing your business model? Hire more people if you feel overloaded, but don't pass the workload off on others, particularly others in the biz, we have workloads too. > I wont claim perfection, infallibility etc for any of the big 3 > (hotmail / yahoo / aol) or even for us (large enough - 76 million > users we filter for, 40 million of which we host). But a user report > based spam reporting system works quite well on the aggregate. Perhaps it works for you, but we get a non-stop stream of false positives; unsubscribes (a lot of it), Dad's out of the hospital would love to see you next week, and on and on. I was suggesting a simple improvement which would help: Don't send it as a spam report unless you get two or more complaints about the same msg/source within a short time period. It's good and valuable advice, you can send me a PO... The point is, I'm not complaining, I'm making what I think is a constructive suggestion: Don't send it until you get two or more complaints (as previously outlined.) > And yes, legitimate outfits can wind up blocked (universities because > of unfiltered machines on campus, and because of nigerians / phishers > hacking user accounts, webhosts because of hacked scripts, or because > they end up hosting a high volume spammer in part of a /24 with legit > customers near him ..) I didn't say a word about any of this... > One thing that may need to be improved at one place or the other is > false positive handling - make that faster and more efficient, and > also publish the "unblock contact path" in block messages you issue, > and you would find a lot of the gripes getting resolved. To some > extent anyway. > > Postmaster work is a place for people with decent mailops / routing > skills, yes - but far more than that, it is for people with both soft > skills for customer service plus a finely tuned b.s detector. It is > complex, and far too long for nanog .. took maawg three or four > brainstorming sessions over a year to discuss. Well, this is all nice, I'm sorry you entirely missed my rather simple and straightforward suggestion, but whatever. > http://www.maawg.org/about/publishedDocuments/Abuse_Desk_Common_Practices.pdf > > And then some others relevant to this thread - > > http://www.maawg.org/about/publishedDocuments/MAAWG_Email_Forwarding_BP.pdf > http://www.maawg.org/port25 > http://www.maawg.org/about/publishedDocuments/MAAWG_AWPG_Anti_Phishing_Best_Practices.pdf > http://www.maawg.org/about/publishedDocuments > > --srs -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From ops.lists at gmail.com Wed Feb 25 21:44:56 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Feb 2009 09:14:56 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: <18854.3219.454176.970127@world.std.com> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> <18854.3219.454176.970127@world.std.com> Message-ID: On Thu, Feb 26, 2009 at 8:59 AM, Barry Shein wrote: > We get a steady stream of "spam" complaints from the AOL feedback loop > which is virtually all either (we assume) unsubscriptions from > legitimate mailing lists or random misfires, "it was nice seeing you > and dad last week" From joe blow, To susie blow, which just probably > isn't spam. It depends. What WE get from the AOL fbl is by and large actual spam sent by our users. Yes there's a non trivial amount of misreported legit email but when you get near real time notification of actual spam too, that's incredibly useful. ARF - in which aol (and our) loops are sent is designed to be automatically parsed. So, go right ahead. Run the stuff through (say) SA and see what you come up with, besides running counts / numbers, user X signed up just a coupla days back and see, he's already got a couple of hundred complaints from AOL, Comcast, etc. > Why should my staff and I spend valuable time subsidizing your > business model? Hire more people if you feel overloaded, but don't > pass the workload off on others, particularly others in the biz, we > have workloads too. Well... If you think theres no value in the AOL or other feedback loops and your network is clean enough without that, well then, dont sign up to it and then bitch when all you get for your boutique network with users who are by and large fellow geeks doesnt generate any actual spam at all. On the other hand, for SPs that actually have real userbases to contend with, and on far larger scales than theworld has .. well, they'd certainly find it a lot more useful. > I was suggesting a simple improvement which would help: Don't send it > as a spam report unless you get two or more complaints about the same > msg/source within a short time period. Well .. set limits and you'll have spammers who work around those limits. Its a catch 22. Spammers have an almost infinite capacity to scale horizontally, you'll find. > I didn't say a word about any of this... It was a meta comment to the rest of this rather uninformed thread, but anyway .. > Well, this is all nice, I'm sorry you entirely missed my rather simple > and straightforward suggestion, but whatever. Saw it. Dismissed it as impractical. -srs From pmm at igtc.com Wed Feb 25 21:57:18 2009 From: pmm at igtc.com (Paul M. Moriarty) Date: Wed, 25 Feb 2009 19:57:18 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> Message-ID: On Feb 25, 2009, at 5:25 PM, Suresh Ramasubramanian wrote: > On Wed, Feb 25, 2009 at 11:28 PM, Barry Shein > wrote: > >> I realize this is easier in theory than practice but I wonder how >> much >> better the whole AOL (et al) spam button would get if they ignored >> the >> spam button unless two (to pick a number) different customers clicked >> the same sender (I know, forged sender etc but something like that) >> as >> spam in a reasonably short amount of time like an hour or a day at >> most. > > .. and you think AOL doesnt track these? Come on, barry - try to give > large mailops shops with massive userbases some credit for clue level. > You have all the clue in the world but you dont even begin to guess > at the firehose AOL / Yahoo / we etc have to deal with. Or what we > routinely do, as a matter of best practice. > Whenever I see the words "best practice" I find my self wondering, "Best for who?" From ops.lists at gmail.com Wed Feb 25 21:59:15 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Feb 2009 09:29:15 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> Message-ID: On Thu, Feb 26, 2009 at 9:27 AM, Paul M. Moriarty wrote: > > Whenever I see the words "best practice" I find my self wondering, "Best for > who?" > For us, email hosting / mailbox providers, its kind of a shared best practice evolved in MAAWG meetings and elsewhere. What works for us may or may not work for say a corporate network, or a .. [etc] -- Suresh Ramasubramanian (ops.lists at gmail.com) From bzs at world.std.com Wed Feb 25 22:07:46 2009 From: bzs at world.std.com (Barry Shein) Date: Wed, 25 Feb 2009 23:07:46 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> <18854.3219.454176.970127@world.std.com> Message-ID: <18854.5522.422745.897076@world.std.com> On February 26, 2009 at 09:14 ops.lists at gmail.com (Suresh Ramasubramanian) wrote: > > Well... If you think theres no value in the AOL or other feedback > loops and your network is clean enough without that, well then, dont > sign up to it and then bitch when all you get for your boutique > network with users who are by and large fellow geeks doesnt generate > any actual spam at all. Hey, I didn't bitch, I didn't say it was valueless, I didn't say any of this. Can't you make your point without amplifying and putting words in my mouth? It sounds to me like you just want to vent. I suggested that probably 99% of the false positives I see could be avoided by just waiting until there are two or more complaints from the same source before firing it back as spam. I'm sorry if you don't feel you got your money's worth. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From ops.lists at gmail.com Wed Feb 25 22:34:09 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Feb 2009 10:04:09 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: <18854.5522.422745.897076@world.std.com> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> <18854.3219.454176.970127@world.std.com> <18854.5522.422745.897076@world.std.com> Message-ID: On Thu, Feb 26, 2009 at 9:37 AM, Barry Shein wrote: > I suggested that probably 99% of the false positives I see could be > avoided by just waiting until there are two or more complaints from > the same source before firing it back as spam. And the trouble is - that can and will be gamed by "horizontally scaling" spammers. Misreports of the sort you describe shouldnt trigger blocks anyway. From mpetach at netflight.com Wed Feb 25 22:56:22 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 25 Feb 2009 20:56:22 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: <18854.5522.422745.897076@world.std.com> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> <18854.3219.454176.970127@world.std.com> <18854.5522.422745.897076@world.std.com> Message-ID: <63ac96a50902252056i5138809dm6ccf62f89325ee5@mail.gmail.com> On 2/25/09, Barry Shein wrote: > On February 26, 2009 at 09:14 ops.lists at gmail.com (Suresh Ramasubramanian) wrote: > > Well... If you think theres no value in the AOL or other feedback > > loops and your network is clean enough without that, well then, dont > > sign up to it and then bitch when all you get for your boutique > > network with users who are by and large fellow geeks doesnt generate > > any actual spam at all. > > Hey, I didn't bitch, I didn't say it was valueless, I didn't say any > of this. Can't you make your point without amplifying and putting > words in my mouth? It sounds to me like you just want to vent. > > I suggested that probably 99% of the false positives I see could be > avoided by just waiting until there are two or more complaints from > the same source before firing it back as spam. But aren't the spam messages sufficiently randomized these days to make it impossible to get *two* complaints about the same spam, since the messages are all uniquified with randomized strings in them? Matt From ge at linuxbox.org Thu Feb 26 01:19:47 2009 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 26 Feb 2009 01:19:47 -0600 (CST) Subject: [ MDVSA-2009:054 ] nagios (fwd) In-Reply-To: <5792267e0902251340q68a1745cqbc87c2fcf8afa805@mail.gmail.com> References: <5792267e0902251340q68a1745cqbc87c2fcf8afa805@mail.gmail.com> Message-ID: On Wed, 25 Feb 2009, Eric Gearhart wrote: > > I hate to be pedantic but is this something that should get forwarded > to NANOG? I guess the relevance is justified because a lot of network > folks run Nagios...? As long as network operators related vulns don't start showing up every couple of months or so, I think so. From shivlu.jain at gmail.com Thu Feb 26 03:04:40 2009 From: shivlu.jain at gmail.com (Shivlu Jain) Date: Thu, 26 Feb 2009 14:34:40 +0530 Subject: Problem With E1 Message-ID: Since morning I am facing a issue in which one of E1 is configured under OSPF. OSPF neighborship is up but not able to send and receive the data. The configuration is plain vanila. Why it is happening so; I donot know? -- Thanks & Regards shivlu jain http://shivlu.blogspot.com/ 09312010137 From rsk at gsp.org Thu Feb 26 06:14:48 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 26 Feb 2009 07:14:48 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> Message-ID: <20090226121448.GA23907@gsp.org> This discussion is probably *much* more appropriate on the mailop list. (It's been mentioned there and on other MTA/spam-related lists, as apparently whatever Yahoo's doing is having widespread impact.) ---Rsk From hcb at netcases.net Thu Feb 26 06:36:31 2009 From: hcb at netcases.net (Howard C. Berkowitz) Date: Thu, 26 Feb 2009 07:36:31 -0500 Subject: Problem With E1 In-Reply-To: References: Message-ID: <00b001c9980e$daaceda0$020fa8c0@HDESK1> > -----Original Message----- > From: Shivlu Jain [mailto:shivlu.jain at gmail.com] > Sent: Thursday, February 26, 2009 4:05 AM > To: nanog at nanog.org > Subject: Problem With E1 > > Since morning I am facing a issue in which one of E1 is configured under > OSPF. OSPF neighborship is up but not able to send and receive the data. > The > configuration is plain vanila. Why it is happening so; I donot know? > > -- > Thanks & Regards > shivlu jain > http://shivlu.blogspot.com/ > 09312010137 If this is an operational circuit, this is a good example of why it can extremely useful to document the working configuration of a resource, so you can compare the malfunctioning configuration. The document may well be stored as a file, and the comparison could be made with diff or a similar utility. Don't forget SNMP and NetFlow, both on the router, but also SNMP on the access device, modem, multiplexer, etc. When that circuit first came up, I probably would have captured the information from the router's equivalent of the Cisco commands: * show interface * show ip interface * show ip ospf interface * show ip ospf neigbors Possibly show ip ospf database and show ip ospf database neighbors; perhaps save the routing table when storing those displays. Even more displays could be useful, such as subinterfaces. Electrical tests, such as verifying the signal clocking and amplitude, are usually last resorts -- although do verify that no one has moved the cabling among router/CSU ports, and that everything has power. From Darel.Graham at Globalcrossing.com Thu Feb 26 06:50:39 2009 From: Darel.Graham at Globalcrossing.com (Graham, Darel) Date: Thu, 26 Feb 2009 07:50:39 -0500 Subject: Problem With E1 In-Reply-To: <00b001c9980e$daaceda0$020fa8c0@HDESK1> References: <00b001c9980e$daaceda0$020fa8c0@HDESK1> Message-ID: <278488ECD81E6A42A7289E84524D2A257EE92E42@EVS20.ams.gblxint.com> Using an external CSU? Power cycle it. Using Frame Relay? Have provider check card in Frame switch, if the port reads 65535 the buffers are full. Have the provider reset the card (shared memory cards are bad). Without configuration info or other supporting info it will be difficult to tell what the underlying issues are with OSPF/Ckt. Thanks Howard for the push in the right direction. DR Graham -----Original Message----- From: Howard C. Berkowitz [mailto:hcb at netcases.net] Sent: Thursday, February 26, 2009 7:37 AM To: nanog at nanog.org Subject: RE: Problem With E1 > -----Original Message----- > From: Shivlu Jain [mailto:shivlu.jain at gmail.com] > Sent: Thursday, February 26, 2009 4:05 AM > To: nanog at nanog.org > Subject: Problem With E1 > > Since morning I am facing a issue in which one of E1 is configured under > OSPF. OSPF neighborship is up but not able to send and receive the data. > The > configuration is plain vanila. Why it is happening so; I donot know? > > -- > Thanks & Regards > shivlu jain > http://shivlu.blogspot.com/ > 09312010137 If this is an operational circuit, this is a good example of why it can extremely useful to document the working configuration of a resource, so you can compare the malfunctioning configuration. The document may well be stored as a file, and the comparison could be made with diff or a similar utility. Don't forget SNMP and NetFlow, both on the router, but also SNMP on the access device, modem, multiplexer, etc. When that circuit first came up, I probably would have captured the information from the router's equivalent of the Cisco commands: * show interface * show ip interface * show ip ospf interface * show ip ospf neigbors Possibly show ip ospf database and show ip ospf database neighbors; perhaps save the routing table when storing those displays. Even more displays could be useful, such as subinterfaces. Electrical tests, such as verifying the signal clocking and amplitude, are usually last resorts -- although do verify that no one has moved the cabling among router/CSU ports, and that everything has power. From dot at dotat.at Thu Feb 26 07:28:40 2009 From: dot at dotat.at (Tony Finch) Date: Thu, 26 Feb 2009 13:28:40 +0000 Subject: Yahoo and their mail filters.. In-Reply-To: <20090225205442.98208.qmail@simone.iecc.com> References: <20090225205442.98208.qmail@simone.iecc.com> Message-ID: On Wed, 25 Feb 2009, John Levine wrote: > > AOL sends its spam button feedback in industry standard ARF format. It > took me about 20 minutes to write a perl script that picks out the > relevant bits from AOL and Hotmail feedback messages and sends unsub > commands to my list manager. Yes, but you're using qmail and ezmlm which send separate copies of the message to each recipient, with the recipient's address embedded in the return path. If, like us, you have a setup that's optimised to de-duplicate multi-recipient messages, AOL's redaction makes their ARF messages mosly useless for anything but rough detection (or confirmation) of a compromise. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From johnl at iecc.com Thu Feb 26 07:47:18 2009 From: johnl at iecc.com (John R. Levine) Date: Thu, 26 Feb 2009 13:47:18 +0000 (GMT) Subject: Yahoo and their mail filters.. In-Reply-To: References: <20090225205442.98208.qmail@simone.iecc.com> Message-ID: >> AOL sends its spam button feedback in industry standard ARF format. It >> took me about 20 minutes to write a perl script that picks out the >> relevant bits from AOL and Hotmail feedback messages and sends unsub >> commands to my list manager. > > Yes, but you're using qmail and ezmlm which send separate copies of the > message to each recipient, with the recipient's address embedded in the > return path. Actually I'm using majordomo2, but you're right, it does single deliveries which helps do > If, like us, you have a setup that's optimised to de-duplicate > multi-recipient messages, AOL's redaction makes their ARF messages mosly > useless for anything but rough detection (or confirmation) of a > compromise. Sounds like it might be time to reconsider your mailing list config. A decade ago, bandwidth was really expensive and it made sense to try to load up lots of recipients per delivery. These days it's essentially free, and any saving in bandwidth is swamped by the extra manual effort of having to do bounce management by hand. R's, John From dot at dotat.at Thu Feb 26 07:57:18 2009 From: dot at dotat.at (Tony Finch) Date: Thu, 26 Feb 2009 13:57:18 +0000 Subject: Yahoo and their mail filters.. In-Reply-To: References: <20090225205442.98208.qmail@simone.iecc.com> Message-ID: On Thu, 26 Feb 2009, John R. Levine wrote: > > Sounds like it might be time to reconsider your mailing list config. A decade > ago, bandwidth was really expensive and it made sense to try to load up lots > of recipients per delivery. These days it's essentially free, and any saving > in bandwidth is swamped by the extra manual effort of having to do bounce > management by hand. Mailman's bounce parser is clever enough that there's no manualarity. AOL's ARF redaction also causes problems identifying problem .forwarders. I don't understand what they are trying to defend against. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From johnl at iecc.com Thu Feb 26 08:16:25 2009 From: johnl at iecc.com (John R. Levine) Date: Thu, 26 Feb 2009 14:16:25 +0000 (GMT) Subject: AOL, was Yahoo and their mail filters.. In-Reply-To: References: <20090225205442.98208.qmail@simone.iecc.com> Message-ID: > AOL's ARF redaction also causes problems identifying problem .forwarders. > I don't understand what they are trying to defend against. Oh, I went around with them a few times and finally got a reasonable explanation. They're concerned about disclosing the recipient of a message to someone who didn't send it. That's why they redact the recipient address, but not an ever-so-lightly encoded version of it elsewhere in the headers. If you can decode it, you presumably must have put it there in the first place. They've redacted more heavily than that in the past, but it turns out that was buggy software, not policy. So if it's a problem, just add and X-forwarded-for header with a rot13 version of the address and you can always recover that. I also gather that if you happen to have run your mail through a filter and have an opinion of its spamminess, an X-Spam-Status header is treated as a hint to deliver to the spam folder where it won't counted against you, but it's still there for the user in case you guessed wrong. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From ops.lists at gmail.com Thu Feb 26 08:39:30 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Feb 2009 20:09:30 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: References: <20090225205442.98208.qmail@simone.iecc.com> Message-ID: On Thu, Feb 26, 2009 at 7:27 PM, Tony Finch wrote: > Mailman's bounce parser is clever enough that there's no manualarity. > > AOL's ARF redaction also causes problems identifying problem .forwarders. > I don't understand what they are trying to defend against. If you want to enable verp with mailman and exim .. # Use VERP with mailman VERP_PASSWORD_REMINDERS = 1 VERP_PERSONALIZED_DELIVERIES = 1 VERP_DELIVERY_INTERVAL = 1 VERP_CONFIRMATIONS = 1 That takes care of what you want. -srs From johnl at iecc.com Thu Feb 26 08:57:11 2009 From: johnl at iecc.com (John Levine) Date: 26 Feb 2009 14:57:11 -0000 Subject: Yahoo and their mail filters.. In-Reply-To: <18854.5522.422745.897076@world.std.com> Message-ID: <20090226145711.83653.qmail@simone.iecc.com> >I suggested that probably 99% of the false positives I see could be >avoided by just waiting until there are two or more complaints from >the same source before firing it back as spam. Perhaps, but different people have different heuristics. There's nothing keeping you from writing your own de-duper that only shows you stuff with a count of 2 or more. R's, John From johnl at iecc.com Thu Feb 26 08:59:58 2009 From: johnl at iecc.com (John Levine) Date: 26 Feb 2009 14:59:58 -0000 Subject: Yahoo and their mail filters.. In-Reply-To: <7F2E53DA-2A67-4304-AF8B-992E3100207F@smtps.net> Message-ID: <20090226145958.84458.qmail@simone.iecc.com> >Nor should they. Anyone who actually researches this stuff knows that >the vast majority of "unsub" links simply confirm you as a live target >who will click on random links sent to them through e-mail. That's the conventional wisdom, not confirmed by research. The FTC tried it in 2002 and found that opt-out made the spam load drop slightly, and I don't see any reason to think it would be different today. http://www.wired.com/techbiz/media/news/2002/04/51517 R's, John From chort at smtps.net Thu Feb 26 09:57:25 2009 From: chort at smtps.net (Brian Keefer) Date: Thu, 26 Feb 2009 07:57:25 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: <20090226145958.84458.qmail@simone.iecc.com> References: <20090226145958.84458.qmail@simone.iecc.com> Message-ID: <460BAE16-1E14-4D9C-9A1E-2F426128B235@smtps.net> On Feb 26, 2009, at 6:59 AM, John Levine wrote: >> Nor should they. Anyone who actually researches this stuff knows >> that >> the vast majority of "unsub" links simply confirm you as a live >> target >> who will click on random links sent to them through e-mail. > > That's the conventional wisdom, not confirmed by research. The FTC > tried it in 2002 and found that opt-out made the spam load drop > slightly, and I don't see any reason to think it would be different > today. > > http://www.wired.com/techbiz/media/news/2002/04/51517 > > R's, > John The number of messages in their test is not that large, and it also sounds like a large majority of those were mailto: links. It's unsurprising they didn't go any where. These days they're pretty much all http: links going to botnet webhosts. Also, from the same article: "Nonetheless, the risks of responding to spammers are far from illusory, said Jeff Richards, vice president of the consulting firm ePrivacy Group. ... when he sent removal requests to spammers of the more obvious con artist variety, in particular for messages emanating from exotic locales in Eastern Europe and Asia, Richards said he frequently wound up receiving more e-mail." From my own experience with a Hotmail account a few years earlier (late '90s), I tried to unsubscribe from every single e-mail I got and went from a few dozen spams a week to several hundred very quickly. This also pre-dates organized crime becoming heavily involved, and pre- dates the obsession with browser exploits. Back then a lot of spam was sent by semi-legitimate marketers from the US. These days all the bad guys are out to get you to click on a single link. -- bk From mo.durrani at tdstelecom.com Thu Feb 26 10:03:13 2009 From: mo.durrani at tdstelecom.com (Durrani, Mo) Date: Thu, 26 Feb 2009 10:03:13 -0600 Subject: Problem With E1 In-Reply-To: <278488ECD81E6A42A7289E84524D2A257EE92E42@EVS20.ams.gblxint.com> Message-ID: <796542A6753CC54D9CA6A4EC765F43CD03F8AE57@VSM-MSG002.telecom.tds.local> If the router is cisco , you also wanna check the code and see if there are any known bugs on the code track. We had a simmiliar issu with an IOS and BGP. But , I do agree with Darel , as well. Mo Durrani >TDS Telecom >IP Network Engineering >608-664-5698 mo.durrani at tdstelecom.com -----Original Message----- From: Graham, Darel [mailto:Darel.Graham at Globalcrossing.com] Sent: Thursday, February 26, 2009 6:51 AM To: nanog at nanog.org Subject: RE: Problem With E1 Using an external CSU? Power cycle it. Using Frame Relay? Have provider check card in Frame switch, if the port reads 65535 the buffers are full. Have the provider reset the card (shared memory cards are bad). Without configuration info or other supporting info it will be difficult to tell what the underlying issues are with OSPF/Ckt. Thanks Howard for the push in the right direction. DR Graham -----Original Message----- From: Howard C. Berkowitz [mailto:hcb at netcases.net] Sent: Thursday, February 26, 2009 7:37 AM To: nanog at nanog.org Subject: RE: Problem With E1 > -----Original Message----- > From: Shivlu Jain [mailto:shivlu.jain at gmail.com] > Sent: Thursday, February 26, 2009 4:05 AM > To: nanog at nanog.org > Subject: Problem With E1 > > Since morning I am facing a issue in which one of E1 is configured > under OSPF. OSPF neighborship is up but not able to send and receive > the data. The configuration is plain vanila. Why it is happening so; I > donot know? > > -- > Thanks & Regards > shivlu jain > http://shivlu.blogspot.com/ > 09312010137 If this is an operational circuit, this is a good example of why it can extremely useful to document the working configuration of a resource, so you can compare the malfunctioning configuration. The document may well be stored as a file, and the comparison could be made with diff or a similar utility. Don't forget SNMP and NetFlow, both on the router, but also SNMP on the access device, modem, multiplexer, etc. When that circuit first came up, I probably would have captured the information from the router's equivalent of the Cisco commands: * show interface * show ip interface * show ip ospf interface * show ip ospf neigbors Possibly show ip ospf database and show ip ospf database neighbors; perhaps save the routing table when storing those displays. Even more displays could be useful, such as subinterfaces. Electrical tests, such as verifying the signal clocking and amplitude, are usually last resorts -- although do verify that no one has moved the cabling among router/CSU ports, and that everything has power. From johnl at iecc.com Thu Feb 26 10:28:14 2009 From: johnl at iecc.com (John R. Levine) Date: Thu, 26 Feb 2009 16:28:14 +0000 (GMT) Subject: Yahoo and their mail filters.. In-Reply-To: <460BAE16-1E14-4D9C-9A1E-2F426128B235@smtps.net> References: <20090226145958.84458.qmail@simone.iecc.com> <460BAE16-1E14-4D9C-9A1E-2F426128B235@smtps.net> Message-ID: > This also pre-dates organized crime becoming heavily involved, and pre-dates > the obsession with browser exploits. Back then a lot of spam was sent by > semi-legitimate marketers from the US. These days all the bad guys are out > to get you to click on a single link. Right. Back in the 90s spammers were trying to build their lists, and used fake opt outs to do so. These days through a combination of web scraping and dictionary attacks, they have more addresses than they know what to do with. My advice to people these days is to unsub if a message is from someone you've corresponded with before, or if it looks like someone who is legit but clueless. Then hit the spam button. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From schampeo at hesketh.com Thu Feb 26 10:45:31 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 26 Feb 2009 11:45:31 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <140953.1235589434@turing-police.cc.vt.edu> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> <84365D16-ED9B-43F3-A8DF-A975D5C6EB51@hopcount.ca> <49A5917D.8080301@gmail.com> <140953.1235589434@turing-police.cc.vt.edu> Message-ID: <20090226164531.GA2222@hesketh.com> on Wed, Feb 25, 2009 at 02:17:14PM -0500, Valdis.Kletnieks at vt.edu wrote: > On Wed, 25 Feb 2009 10:44:13 PST, JC Dill said: > > > Universities are often major sources of spam. Spam is sent directly > > from virus-infected student computers, > > Got any numbers to back up the claim that virus-infected student computers > are anywhere near the problem that virus-infected student's-parents computers > are? > > (I'm not saying universities are perfect - we have to nuke several users > a day because their accounts or machines fall under enemy control. But I > see a lot of people repeating the meme without any numbers to back it up) Without going into comparisons between resnets and the world at large, I will say that the resnet problem has gotten a *lot* better over the past couple of years; it used to be that every new semester saw a huge uptick in botted resnet hosts, but we haven't seen anything like that for two years or so. Good work! -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From a.harrowell at gmail.com Thu Feb 26 11:05:26 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 26 Feb 2009 18:05:26 +0100 Subject: Yahoo and their mail filters.. In-Reply-To: References: <20090226145958.84458.qmail@simone.iecc.com> <460BAE16-1E14-4D9C-9A1E-2F426128B235@smtps.net> Message-ID: On Thu, Feb 26, 2009 at 5:28 PM, John R. Levine wrote: > This also pre-dates organized crime becoming heavily involved, and >> pre-dates the obsession with browser exploits. Back then a lot of spam was >> sent by semi-legitimate marketers from the US. These days all the bad guys >> are out to get you to click on a single link. >> > > Right. Back in the 90s spammers were trying to build their lists, and used > fake opt outs to do so. These days through a combination of web scraping > and dictionary attacks, they have more addresses than they know what to do > with. > > My advice to people these days is to unsub if a message is from someone > you've corresponded with before, or if it looks like someone who is legit > but clueless. Then hit the spam button. Of course, the browsploit issue means that clicking on ANY links in dubious e-mail is highly unwise. From tme at multicasttech.com Thu Feb 26 11:16:49 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 26 Feb 2009 12:16:49 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: References: <20090226145958.84458.qmail@simone.iecc.com> <460BAE16-1E14-4D9C-9A1E-2F426128B235@smtps.net> Message-ID: On Feb 26, 2009, at 12:05 PM, Alexander Harrowell wrote: > On Thu, Feb 26, 2009 at 5:28 PM, John R. Levine > wrote: > >> This also pre-dates organized crime becoming heavily involved, and >>> pre-dates the obsession with browser exploits. Back then a lot of >>> spam was >>> sent by semi-legitimate marketers from the US. These days all the >>> bad guys >>> are out to get you to click on a single link. >>> >> >> Right. Back in the 90s spammers were trying to build their lists, >> and used >> fake opt outs to do so. These days through a combination of web >> scraping >> and dictionary attacks, they have more addresses than they know >> what to do >> with. >> >> My advice to people these days is to unsub if a message is from >> someone >> you've corresponded with before, or if it looks like someone who is >> legit >> but clueless. Then hit the spam button. > > My advice is to always check the full email headers for anything you are the least bit suspicious of. Does it appear to come from whom it purports to come from ? Is the path likely ? (Big US companies do not as a general rule forward their email through small Eastern European ISPs, for example.) If it fails this test, treat it as radioactive and don't click, respond, etc. If it passes, and if the sender is in your field, then use your judgement. (I unsubscribe to the "newsletters" that keep popping up from Chinese ethernet switch makers, for example.) Regards Marshall > Of course, the browsploit issue means that clicking on ANY links in > dubious > e-mail is highly unwise. From chort at smtps.net Thu Feb 26 12:30:08 2009 From: chort at smtps.net (Brian Keefer) Date: Thu, 26 Feb 2009 10:30:08 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: References: <20090226145958.84458.qmail@simone.iecc.com> <460BAE16-1E14-4D9C-9A1E-2F426128B235@smtps.net> Message-ID: <943967F6-A57E-4FB0-97EE-714ED915194D@smtps.net> On Feb 26, 2009, at 8:28 AM, John R. Levine wrote: >> This also pre-dates organized crime becoming heavily involved, and >> pre-dates the obsession with browser exploits. Back then a lot of >> spam was sent by semi-legitimate marketers from the US. These days >> all the bad guys are out to get you to click on a single link. > > Right. Back in the 90s spammers were trying to build their lists, > and used fake opt outs to do so. These days through a combination > of web scraping and dictionary attacks, they have more addresses > than they know what to do with. > > My advice to people these days is to unsub if a message is from > someone you've corresponded with before, or if it looks like someone > who is legit but clueless. Then hit the spam button. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet > for Dummies", > Information Superhighwayman wanna-be, http://www.johnlevine.com, ex- > Mayor > "More Wiener schnitzel, please", said Tom, revealingly. You're that confident people know the difference between a real communication from a party they conversed with before and a phish designed to look like the same thing? Anyone knowledgeable enough to determine the difference won't need to be educated, and anyone needing education is not going to be capable of reliably differentiating. The only advice that makes sense is "don't click links in e-mail". The exceptions are (expected) personal communication, or messages that you fully expected to arrive at the time and date you received them. There are all kinds of corner cases that could be argued, but I suspect this is rapidly heading off-topic. The gist of my point is that users should never be trained to trust e- mail that hasn't been authenticated. -- bk From johnl at iecc.com Thu Feb 26 13:00:44 2009 From: johnl at iecc.com (John R. Levine) Date: Thu, 26 Feb 2009 19:00:44 +0000 (GMT) Subject: Yahoo and their mail filters.. In-Reply-To: <943967F6-A57E-4FB0-97EE-714ED915194D@smtps.net> References: <20090226145958.84458.qmail@simone.iecc.com> <460BAE16-1E14-4D9C-9A1E-2F426128B235@smtps.net> <943967F6-A57E-4FB0-97EE-714ED915194D@smtps.net> Message-ID: > You're that confident people know the difference between a real communication > from a party they conversed with before and a phish designed to look like the > same thing? If it's a bank, probably not. If it's a random online store, there's about a 99.9% chance it's actual junk mail and .01% that it's anything else. R's, John From bpfankuch at cpgreeley.com Thu Feb 26 13:01:18 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Thu, 26 Feb 2009 12:01:18 -0700 Subject: Documentation of switch maps Message-ID: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> Howdy. Had a customer come to me this morning who wanted to create a document for their switching infrastructure and thought I would bounce it off the rest of the world on how you usually do this. Typically I use a spreadsheet with outlines to define the "switch" and then outlines for the ports and color coding for vlan's as well as a description of the port. Curious what other people are doing, as this would be a huge undertaking for a customer who is using an entire /19 of rfc 1918 ip addresses and has well over 150 switches and 40 active vlans. The want to be able to look at this document and pull up any switch and look at the port and be able to see what vlan the port is on, as well as what device it is connected to as well as port channel membership, trunks and other fun things like that. Needless to say their documentation is lacking on the physical connectivity however their cisco infrastructure does have labels on every port that goes to a named device outside of the DHCP pools. Thoughts? Thanks, Blake Pfankuch From dwbielawa at liberty.edu Thu Feb 26 13:06:58 2009 From: dwbielawa at liberty.edu (Bielawa, Daniel W. (NS)) Date: Thu, 26 Feb 2009 14:06:58 -0500 Subject: Documentation of switch maps In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> Message-ID: <83FBF523E7955843A01EDB632E39CDC4D57247EA@LUEMS03VS.University.liberty.edu> Hello, We use switchmap here for tracking port utilization, days inactive, and devices connected. It uses SNMP to determine the information. http://switchmap.sourceforge.net/ Thank You Daniel Bielawa Network Engineer Liberty University Information Services -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Thursday, February 26, 2009 2:01 PM To: nanog at nanog.org Subject: Documentation of switch maps Howdy. Had a customer come to me this morning who wanted to create a document for their switching infrastructure and thought I would bounce it off the rest of the world on how you usually do this. Typically I use a spreadsheet with outlines to define the "switch" and then outlines for the ports and color coding for vlan's as well as a description of the port. Curious what other people are doing, as this would be a huge undertaking for a customer who is using an entire /19 of rfc 1918 ip addresses and has well over 150 switches and 40 active vlans. The want to be able to look at this document and pull up any switch and look at the port and be able to see what vlan the port is on, as well as what device it is connected to as well as port channel membership, trunks and other fun things like that. Needless to say their documentation is lacking on the physical connectivity however their cisco infrastructure does have labels on every port that goes to a named device outside of the DHCP pools. Thoughts? Thanks, Blake Pfankuch From if at xip.at Thu Feb 26 13:11:16 2009 From: if at xip.at (Ingo Flaschberger) Date: Thu, 26 Feb 2009 20:11:16 +0100 (CET) Subject: Documentation of switch maps In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> Message-ID: Dear Blake, > Had a customer come to me this morning who wanted to create a document > for their switching infrastructure and thought I would bounce it off the > rest of the world on how you usually do this. Typically I use a > spreadsheet with outlines to define the "switch" and then outlines for > the ports and color coding for vlan's as well as a description of the > port. Curious what other people are doing, as this would be a huge > undertaking for a customer who is using an entire /19 of rfc 1918 ip > addresses and has well over 150 switches and 40 active vlans. The want > to be able to look at this document and pull up any switch and look at > the port and be able to see what vlan the port is on, as well as what > device it is connected to as well as port channel membership, trunks and > other fun things like that. Needless to say their documentation is > lacking on the physical connectivity however their cisco infrastructure > does have labels on every port that goes to a named device outside of > the DHCP pools. Thoughts? I use wiki. 1 page switch: switchname...........10.0.0.20 ----------------- 1 uplink 2 server2 . 24 donwlink 1 page vlans: 102........MYVLAN ------------------------- ip: 10.0.1.0/24 ports: sw1: 1+, 2, 3, 24+ sw2: 1+, 4, 5 + means tagged kind regards, Ingo Flaschberger From rcorbin at traffiq.com Thu Feb 26 13:11:13 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Thu, 26 Feb 2009 13:11:13 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: <18854.3219.454176.970127@world.std.com> Message-ID: $0.02 within > -----Original Message----- > From: Barry Shein [mailto:bzs at world.std.com] > Sent: Wednesday, February 25, 2009 10:29 PM > To: Suresh Ramasubramanian > Cc: nanog at nanog.org > Subject: Re: Yahoo and their mail filters.. > > > On February 26, 2009 at 06:55 ops.lists at gmail.com (Suresh Ramasubramanian) > wrote: > > On Wed, Feb 25, 2009 at 11:28 PM, Barry Shein > wrote: > > > > > I realize this is easier in theory than practice but I wonder how > much > > > better the whole AOL (et al) spam button would get if they ignored > the > > > spam button unless two (to pick a number) different customers clicked > > > the same sender (I know, forged sender etc but something like that) > as > > > spam in a reasonably short amount of time like an hour or a day at > > > most. > > > > .. and you think AOL doesnt track these? Come on, barry - try to give > > large mailops shops with massive userbases some credit for clue level. > > I have no idea what they track and it's completely irrelevant. > > We get a steady stream of "spam" complaints from the AOL feedback loop > which is virtually all either (we assume) unsubscriptions from > legitimate mailing lists or random misfires, "it was nice seeing you > and dad last week" From joe blow, To susie blow, which just probably > isn't spam. > The format is standard so you can have it automated to look for people trying to unsubscribe and simply unsubscribe them. AOL also uses a % system before initiating a block. If you send 100000 emails to them and you get 500 complaints...its not going to block you. It is more of a friendly notice of what their members are saying is spam. It isn't their responsibility to tell you what is and is not actually spam with the FBL, they are saying what the recipients of your message is spam. > Now, if you're still following, none (or a microscopic amt) of that > would pass the "complaints came from two different sources in a fairly > short amount of time" sniff test I proposed. > > If you track it and don't use it, well, tree falling in the forest and > all that. > > I can see with my own eyes that nothing like this is being done. > > As far as I can tell from here, and other sites may see it > diffferently, the feedback thing is mostly just a "please unsubscribe > me from this mailing list I subscribed to and can't remember how to > get off" and the occasional "oops, hit the spam button on mom's mail, > oh well!" > If you are getting hundreds of spam complaints you either send a large volume of email to them or something is wrong with your mailings. I know at my old company we had thousands every day coming in, but it wasn't more then 0.2% or so of the volume that was actually sent to them (they send out the alerts when you start getting to there threshold). > > You have all the clue in the world but you dont even begin to guess > > at the firehose AOL / Yahoo / we etc have to deal with. Or what we > > routinely do, as a matter of best practice. > > Nor is it my problem. > > Why should my staff and I spend valuable time subsidizing your > business model? Hire more people if you feel overloaded, but don't > pass the workload off on others, particularly others in the biz, we > have workloads too. Automate it, they are standardized reports. Separate your newsletter from all other email. > > > I wont claim perfection, infallibility etc for any of the big 3 > > (hotmail / yahoo / aol) or even for us (large enough - 76 million > > users we filter for, 40 million of which we host). But a user report > > based spam reporting system works quite well on the aggregate. > > Perhaps it works for you, but we get a non-stop stream of false > positives; unsubscribes (a lot of it), Dad's out of the hospital would > love to see you next week, and on and on. > > I was suggesting a simple improvement which would help: Don't send it > as a spam report unless you get two or more complaints about the same > msg/source within a short time period. > > It's good and valuable advice, you can send me a PO... > > The point is, I'm not complaining, I'm making what I think is a > constructive suggestion: Don't send it until you get two or more > complaints (as previously outlined.) > > > And yes, legitimate outfits can wind up blocked (universities because > > of unfiltered machines on campus, and because of nigerians / phishers > > hacking user accounts, webhosts because of hacked scripts, or because > > they end up hosting a high volume spammer in part of a /24 with legit > > customers near him ..) > > I didn't say a word about any of this... > > > One thing that may need to be improved at one place or the other is > > false positive handling - make that faster and more efficient, and > > also publish the "unblock contact path" in block messages you issue, > > and you would find a lot of the gripes getting resolved. To some > > extent anyway. > > > > Postmaster work is a place for people with decent mailops / routing > > skills, yes - but far more than that, it is for people with both soft > > skills for customer service plus a finely tuned b.s detector. It is > > complex, and far too long for nanog .. took maawg three or four > > brainstorming sessions over a year to discuss. > > Well, this is all nice, I'm sorry you entirely missed my rather simple > and straightforward suggestion, but whatever. > > > > http://www.maawg.org/about/publishedDocuments/Abuse_Desk_Common_Practices. > pdf > > > > And then some others relevant to this thread - > > > > > http://www.maawg.org/about/publishedDocuments/MAAWG_Email_Forwarding_BP.pd > f > > http://www.maawg.org/port25 > > > http://www.maawg.org/about/publishedDocuments/MAAWG_AWPG_Anti_Phishing_Bes > t_Practices.pdf > > http://www.maawg.org/about/publishedDocuments > > > > --srs > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From damin at nacs.net Thu Feb 26 13:20:07 2009 From: damin at nacs.net (Gregory Boehnlein) Date: Thu, 26 Feb 2009 14:20:07 -0500 Subject: Documentation of switch maps In-Reply-To: <83FBF523E7955843A01EDB632E39CDC4D57247EA@LUEMS03VS.University.liberty.edu> References: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> <83FBF523E7955843A01EDB632E39CDC4D57247EA@LUEMS03VS.University.liberty.edu> Message-ID: <02bd01c99847$3c48e540$b4daafc0$@net> Man.. I'd love to have this for Netgear switches! :) > -----Original Message----- > From: Bielawa, Daniel W. (NS) [mailto:dwbielawa at liberty.edu] > Sent: Thursday, February 26, 2009 2:07 PM > To: nanog at nanog.org > Subject: RE: Documentation of switch maps > > Hello, > > We use switchmap here for tracking port utilization, days > inactive, and devices connected. It uses SNMP to determine the > information. > > http://switchmap.sourceforge.net/ > > Thank You > > Daniel Bielawa > Network Engineer > Liberty University Information Services > > -----Original Message----- > From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] > Sent: Thursday, February 26, 2009 2:01 PM > To: nanog at nanog.org > Subject: Documentation of switch maps > > Howdy. > > Had a customer come to me this morning who wanted to create a document > for their switching infrastructure and thought I would bounce it off > the rest of the world on how you usually do this. Typically I use a > spreadsheet with outlines to define the "switch" and then outlines for > the ports and color coding for vlan's as well as a description of the > port. Curious what other people are doing, as this would be a huge > undertaking for a customer who is using an entire /19 of rfc 1918 ip > addresses and has well over 150 switches and 40 active vlans. The want > to be able to look at this document and pull up any switch and look at > the port and be able to see what vlan the port is on, as well as what > device it is connected to as well as port channel membership, trunks > and other fun things like that. Needless to say their documentation is > lacking on the physical connectivity however their cisco infrastructure > does have labels on every port that goes to a named device outside of > the DHCP pools. Thoughts? > > Thanks, > Blake Pfankuch > > > -- > This message has been scanned for viruses and > dangerous content by N2Net Mailshield, and is > believed to be clean. From tme at multicasttech.com Thu Feb 26 16:06:41 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 26 Feb 2009 17:06:41 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: References: <20090226145958.84458.qmail@simone.iecc.com> <460BAE16-1E14-4D9C-9A1E-2F426128B235@smtps.net> <943967F6-A57E-4FB0-97EE-714ED915194D@smtps.net> Message-ID: On Feb 26, 2009, at 2:00 PM, John R. Levine wrote: >> You're that confident people know the difference between a real >> communication from a party they conversed with before and a phish >> designed to look like the same thing? > What I worry about is when software is used to scrape lists such as this and used to create phishing based on actual emails, so you get phishes apparently from people you know using their actual words. When the botnets start doing that things could get nasty fast. Regards Marshall > If it's a bank, probably not. If it's a random online store, > there's about a 99.9% chance it's actual junk mail and .01% that > it's anything else. > > R's, > John > From lists at memetic.org Thu Feb 26 17:55:38 2009 From: lists at memetic.org (Adam Armstrong) Date: Thu, 26 Feb 2009 23:55:38 +0000 Subject: Documentation of switch maps In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> Message-ID: <49A72BFA.1070706@memetic.org> Blake Pfankuch wrote: > Howdy. > > Had a customer come to me this morning who wanted to create a document for their switching infrastructure and thought I would bounce it off the rest of the world on how you usually do this. Typically I use a spreadsheet with outlines to define the "switch" and then outlines for the ports and color coding for vlan's as well as a description of the port. Curious what other people are doing, as this would be a huge undertaking for a customer who is using an entire /19 of rfc 1918 ip addresses and has well over 150 switches and 40 active vlans. The want to be able to look at this document and pull up any switch and look at the port and be able to see what vlan the port is on, as well as what device it is connected to as well as port channel membership, trunks and other fun things like that. Needless to say their documentation is lacking on the physical connectivity however their cisco infrastructure does have labels on every port that goes to a named device outside of the DHCP pools. Thoughts? > If they're cisco or similar switches, make sure your port descriptions are correct, and keep configuration archives. Collect the port configuration/status with snmp and populate it into a database, that way you can generate whatever information you want in whatever format and it's accurate, which it won't be if you're expecting someone to update a spreadsheet. adam. From devangnp at gmail.com Thu Feb 26 18:38:18 2009 From: devangnp at gmail.com (devang patel) Date: Thu, 26 Feb 2009 17:38:18 -0700 Subject: Internet access using VRF aware NAT Message-ID: Hello, Have one question about VRF aware NAT for internet access! If we will enable the VRF aware NAT on local PE to have an internet access via central Internet PE then we will not have connectivity to any other VPN site as all local CE prefixes will be translated to the loopback IP address of the local PE. We can have route map which will match the ACL for specific CE source to specific VPN destination with deny key word and it will prevent the NAT when CE will try to communicate with other CE of same VPN or different VPN. That looks longer configuration in real world right! so is that the only way I have when I will have only one option to configure the locap PE with VRF aware NAT to gain internet access? I need to know what is the implement in real world? How service provider networks are providing internet access with MPLS VPN option? I know about customer is getting VPN connectivity on one router and service provider will give other internet connectivity link which might be terminating on same router or other router. I just want to know which is mostly used option as far as the internet access service with MPLS VPN services! thanks, Devang Patel From jdfalk-lists at cybernothing.org Thu Feb 26 19:08:27 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Thu, 26 Feb 2009 18:08:27 -0700 Subject: Yahoo and their mail filters.. In-Reply-To: <797BD373-3542-4E32-AA24-D22B787F0544@smtps.net> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> <797BD373-3542-4E32-AA24-D22B787F0544@smtps.net> Message-ID: <49A73D0B.2010706@cybernothing.org> Brian Keefer wrote: > The other options is to stuff all the spam messages in a folder and > expose them to the user, taking up a huge amount of storage space for > something the vast majority of users are never going to look at any way. Which is, in fact, what Yahoo! does by default. Users have the option to have that stuff deleted immediately, should they desire. > Blocking an entire site just because one John Doe user clicked a button > they don't even understand just does not make sense. You're right -- but Yahoo! has a sufficiently large userbase that they can count multiple complaints before blocking anything. Same story with AOL, and Hotmail, and Cloudmark, and many others who've used this technique for years. In all of those cases, they have safeguards to prevent gaming, to prevent bouncing, and pretty much everything else anyone's suggested thus far in this thread. > Last, anywhere that I've seen extensive use of forwards has had a maze > of difficult to untangle abuse problems related to forwarded spam. Any > site allowing forwarding should apply very robust filtering of outbound > mail. Very true. MAAWG published a document last year which includes some additional recommendations: http://www.maawg.org/about/publishedDocuments/MAAWG_Email_Forwarding_BP.pdf -- J.D. Falk Return Path Inc http://www.returnpath.net/ From carl.ford at gmail.com Thu Feb 26 19:35:57 2009 From: carl.ford at gmail.com (Carl Ford) Date: Thu, 26 Feb 2009 20:35:57 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> Message-ID: very old news. their filter restrictions have some very absurd rules On Tue, Feb 24, 2009 at 9:27 PM, Micheal Patterson < micheal at spmedicalgroup.com> wrote: > This may be old news, but I've not been in the list for quite some time. At > any rate, is anyone else having issues with Yahoo blocking / deferring > legitimate emails? > > My situation is that I host our corporate mx'ers on my network, one of the > companies that we recently purchased has Yahoo hosting their domains mail. > Mail traffic to them is getting temporarily deferred with the "421 4.7.0 > [TS01] Messages from xxx.xxx.xxx.xxx temporarily deferred due to user > complaints - 4.16.55.1; > see http://postmaster.yahoo.com/421-ts01.html" > > The admin of the facility has contacted Yahoo about this but their response > was for "more information" when they were told that traffic from my mx to > their domain was to being deferred. I may end up just having them migrate > to my systems just to maintain company communications if we can't clear this > up in a timely manner. > > -- > Micheal Patterson > > > > > From jdfalk-lists at cybernothing.org Thu Feb 26 19:15:08 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Thu, 26 Feb 2009 18:15:08 -0700 Subject: Yahoo and their mail filters.. In-Reply-To: <18854.5522.422745.897076@world.std.com> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> <18854.3219.454176.970127@world.std.com> <18854.5522.422745.897076@world.std.com> Message-ID: <49A73E9C.1060604@cybernothing.org> Barry Shein wrote: > I suggested that probably 99% of the false positives I see could be > avoided by just waiting until there are two or more complaints from > the same source before firing it back as spam. I've developed systems for ISPs to handle inbound complaints from AOL & such, and that's exactly what we did: multiple complaints were acted upon, single complaints only fed into the aggregate stats. On the INBOUND side. We didn't ask AOL to do that work for us. Many recipients of complaint feedback actually /want/ to receive every complaint, because -- like John Levine -- they treat those complaints as unsubscribe requests. Yours is not the common use case. -- J.D. Falk Return Path Inc http://www.returnpath.net/ From ops.lists at gmail.com Thu Feb 26 20:04:46 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 27 Feb 2009 07:34:46 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: <49A73E9C.1060604@cybernothing.org> References: <907424192-1235535975-cardhu_decombobulator_blackberry.rim.net-1193240742-@bxe1052.bisx.prod.on.blackberry> <18853.34511.349131.897690@world.std.com> <18854.3219.454176.970127@world.std.com> <18854.5522.422745.897076@world.std.com> <49A73E9C.1060604@cybernothing.org> Message-ID: On Fri, Feb 27, 2009 at 6:45 AM, J.D. Falk wrote: > Many recipients of complaint feedback actually /want/ to receive every > complaint, because -- like John Levine -- they treat those complaints as > unsubscribe requests. That's ONE use case. But we are not senders, and we do use a feedback loop because we are an ISP (like barry) but we dont have the luxury of a purely geek (so largely clean e&oe pwned systems) userbase like Barry has. In other words - we do get spammer customers. And the feedback loops provide us near real time notification of these, allowing us to terminate. > Yours is not the common use case. His IS the common use case. Just that he doesnt have the sort of userbase that will generate usable FBLs (aka no significant number of genuine spam issues on his network). For which he has to count himself lucky. From chort at smtps.net Thu Feb 26 22:17:37 2009 From: chort at smtps.net (Brian Keefer) Date: Thu, 26 Feb 2009 20:17:37 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: <49A73D0B.2010706@cybernothing.org> References: <7DDB2D20E26842B491F4D4D1C5264F77@dredster> <797BD373-3542-4E32-AA24-D22B787F0544@smtps.net> <49A73D0B.2010706@cybernothing.org> Message-ID: <257F71E4-40FF-4587-9EAD-F8988465B119@smtps.net> On Feb 26, 2009, at 5:08 PM, J.D. Falk wrote: >> Blocking an entire site just because one John Doe user clicked a >> button >> they don't even understand just does not make sense. > > You're right -- but Yahoo! has a sufficiently large userbase that > they can count multiple complaints before blocking anything. Same > story with AOL, and Hotmail, and Cloudmark, and many others who've > used this technique for years. This does not appear to be the case from external observation. It may be in some cases that multiple reports are necessary, but it certainly seems there are hair-triggers in others. For instance, see the message from Eric Esslinger. As for not black-holing anything, I haven't personally verified with Yahoo!, but others have reported that they do. It's pretty common from what I've seen to simply make very high-scored messages disappear and only send the mid-range stuff to the spam folder. Hotmail, as mentioned, does this. One of the very large hosted filtering services does as well. I'm not saying it's bad (it makes sense if you can trust your scoring algorithm), but it does happen. Just because you get _some_ stuff in your spam folder doesn't mean that's all the spam that was blocked. -- bk From jrhett at netconsonance.com Thu Feb 26 22:26:12 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 26 Feb 2009 20:26:12 -0800 Subject: Yahoo and their mail filters.. In-Reply-To: References: Message-ID: On Feb 25, 2009, at 8:14 AM, Ray Corbin wrote: > It depends on your environment. I've seen where it is helpful and > where it is overwhelming. If you are a smaller company and want to > know why you keep getting blocked then those should help. If you are > a larger company and get a several hundred a day, but you send 100k > emails to AOL then it is not as big of a deal. If you are a shared > hosting provider and you get a lot of them you should look into what > is being sent to AOL, such as forwarded spam from customers 'auto > forwards' (isolate the auto forwards to a separate IP address and > simply don't sign up for the FBL for it).... If you have a good > setup where only customer-originated email is being sent through the > IP's you have a FBL on, then it is useful and you shouldn't get as > many complaints. Ray, you don't get it. What comes from AOL is literally every step in a mother-daughter conversion. You get to read the entire thread. Loving chat, mother and daughter back and forth. But one of them is hitting SPAM on the e-mail *AFTER* replying to it and writing a nice letter back. This is abuse of the abuse department. This isn't spam. Reading through ~3k of these not-spams every day doesn't help us solve any actual abuse problems. Feedback loops will not be useful until the providers of the feedback loops accept reports about use of the spam reporting tools, and are willing to go fix their user behavior. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From rveloso at cs.ucla.edu Thu Feb 26 22:47:35 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Thu, 26 Feb 2009 20:47:35 -0800 Subject: Road Runner DNS servers Message-ID: <9F40AFA3-DABB-4DDC-8CE5-09393FF4E73A@cs.ucla.edu> Is there anyone clueful in this list from Road Runner(Time Warner Cable) that can explain what's going on with their DNS servers - just contacted their tech support and heard their DNS servers have been under attack over the last 3 days.. thanks, --Ricardo From shivlu.jain at gmail.com Fri Feb 27 00:00:54 2009 From: shivlu.jain at gmail.com (Shivlu Jain) Date: Fri, 27 Feb 2009 11:30:54 +0530 Subject: Internet access using VRF aware NAT Message-ID: Hi Devang We are using the vrf nat where the customer demands the firewall services. For implementing this we are advertising a default route and vrf nat is used per VPN basics.This is the rate services in case of whole sale. Actual implementation; we are creating a INTERNET VRF which is having a default route; In customer vrf the RT of internet route is imported and vrf is able to get the default route. For reverse traffic a ipv4 route is added at the PE towards customer interface. regards shivlu jain On Fri, Feb 27, 2009 at 10:17 AM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. RE: Documentation of switch maps (Gregory Boehnlein) > 2. Re: Yahoo and their mail filters.. (Marshall Eubanks) > 3. Re: Documentation of switch maps (Adam Armstrong) > 4. Internet access using VRF aware NAT (devang patel) > 5. Re: Yahoo and their mail filters.. (J.D. Falk) > 6. Re: Yahoo and their mail filters.. (Carl Ford) > 7. Re: Yahoo and their mail filters.. (J.D. Falk) > 8. Re: Yahoo and their mail filters.. (Suresh Ramasubramanian) > 9. Re: Yahoo and their mail filters.. (Brian Keefer) > 10. Re: Yahoo and their mail filters.. (Jo Rhett) > 11. Road Runner DNS servers (Ricardo Oliveira) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 26 Feb 2009 14:20:07 -0500 > From: "Gregory Boehnlein" > Subject: RE: Documentation of switch maps > To: "'Bielawa, Daniel W. \(NS\)'" , > > Message-ID: <02bd01c99847$3c48e540$b4daafc0$@net> > Content-Type: text/plain; charset="us-ascii" > > Man.. I'd love to have this for Netgear switches! :) > > > -----Original Message----- > > From: Bielawa, Daniel W. (NS) [mailto:dwbielawa at liberty.edu] > > Sent: Thursday, February 26, 2009 2:07 PM > > To: nanog at nanog.org > > Subject: RE: Documentation of switch maps > > > > Hello, > > > > We use switchmap here for tracking port utilization, days > > inactive, and devices connected. It uses SNMP to determine the > > information. > > > > http://switchmap.sourceforge.net/ > > > > Thank You > > > > Daniel Bielawa > > Network Engineer > > Liberty University Information Services > > > > -----Original Message----- > > From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] > > Sent: Thursday, February 26, 2009 2:01 PM > > To: nanog at nanog.org > > Subject: Documentation of switch maps > > > > Howdy. > > > > Had a customer come to me this morning who wanted to create a document > > for their switching infrastructure and thought I would bounce it off > > the rest of the world on how you usually do this. Typically I use a > > spreadsheet with outlines to define the "switch" and then outlines for > > the ports and color coding for vlan's as well as a description of the > > port. Curious what other people are doing, as this would be a huge > > undertaking for a customer who is using an entire /19 of rfc 1918 ip > > addresses and has well over 150 switches and 40 active vlans. The want > > to be able to look at this document and pull up any switch and look at > > the port and be able to see what vlan the port is on, as well as what > > device it is connected to as well as port channel membership, trunks > > and other fun things like that. Needless to say their documentation is > > lacking on the physical connectivity however their cisco infrastructure > > does have labels on every port that goes to a named device outside of > > the DHCP pools. Thoughts? > > > > Thanks, > > Blake Pfankuch > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by N2Net Mailshield, and is > > believed to be clean. > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 26 Feb 2009 17:06:41 -0500 > From: Marshall Eubanks > Subject: Re: Yahoo and their mail filters.. > To: John R. Levine > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 26, 2009, at 2:00 PM, John R. Levine wrote: > > >> You're that confident people know the difference between a real > >> communication from a party they conversed with before and a phish > >> designed to look like the same thing? > > > > What I worry about is when software is used to scrape lists such as > this and used to create > phishing based on actual emails, so you get phishes apparently from > people you know using their actual words. > When the botnets start doing that things could get nasty fast. > > Regards > Marshall > > > > If it's a bank, probably not. If it's a random online store, > > there's about a 99.9% chance it's actual junk mail and .01% that > > it's anything else. > > > > R's, > > John > > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 26 Feb 2009 23:55:38 +0000 > From: Adam Armstrong > Subject: Re: Documentation of switch maps > To: Blake Pfankuch > Cc: "nanog at nanog.org" > Message-ID: <49A72BFA.1070706 at memetic.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Blake Pfankuch wrote: > > Howdy. > > > > Had a customer come to me this morning who wanted to create a document > for their switching infrastructure and thought I would bounce it off the > rest of the world on how you usually do this. Typically I use a spreadsheet > with outlines to define the "switch" and then outlines for the ports and > color coding for vlan's as well as a description of the port. Curious what > other people are doing, as this would be a huge undertaking for a customer > who is using an entire /19 of rfc 1918 ip addresses and has well over 150 > switches and 40 active vlans. The want to be able to look at this document > and pull up any switch and look at the port and be able to see what vlan the > port is on, as well as what device it is connected to as well as port > channel membership, trunks and other fun things like that. Needless to say > their documentation is lacking on the physical connectivity however their > cisco infrastructure does have labels on every port that goes to a named > device outside of the DHCP pools. Thoughts? > > > If they're cisco or similar switches, make sure your port descriptions > are correct, and keep configuration archives. Collect the port > configuration/status with snmp and populate it into a database, that way > you can generate whatever information you want in whatever format and > it's accurate, which it won't be if you're expecting someone to update a > spreadsheet. > > adam. > > > > > ------------------------------ > > Message: 4 > Date: Thu, 26 Feb 2009 17:38:18 -0700 > From: devang patel > Subject: Internet access using VRF aware NAT > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > Have one question about VRF aware NAT for internet access! If we will > enable > the VRF aware NAT on local PE to have an internet access via central > Internet PE then we will not have connectivity to any other VPN site as all > local CE prefixes will be translated to the loopback IP address of the > local > PE. > > We can have route map which will match the ACL for specific CE source to > specific VPN destination with deny key word and it will prevent the NAT > when > CE will try to communicate with other CE of same VPN or different VPN. That > looks longer configuration in real world right! so is that the only way I > have when I will have only one option to configure the locap PE with VRF > aware NAT to gain internet access? > I need to know what is the implement in real world? How service provider > networks are providing internet access with MPLS VPN option? I know about > customer is getting VPN connectivity on one router and service provider > will > give other internet connectivity link which might be terminating on same > router or other router. I just want to know which is mostly used option as > far as the internet access service with MPLS VPN services! > > thanks, > Devang Patel > > > ------------------------------ > > Message: 5 > Date: Thu, 26 Feb 2009 18:08:27 -0700 > From: "J.D. Falk" > Subject: Re: Yahoo and their mail filters.. > To: nanog at nanog.org > Message-ID: <49A73D0B.2010706 at cybernothing.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Brian Keefer wrote: > > > The other options is to stuff all the spam messages in a folder and > > expose them to the user, taking up a huge amount of storage space for > > something the vast majority of users are never going to look at any way. > > Which is, in fact, what Yahoo! does by default. Users have the option to > have that stuff deleted immediately, should they desire. > > > Blocking an entire site just because one John Doe user clicked a button > > they don't even understand just does not make sense. > > You're right -- but Yahoo! has a sufficiently large userbase that they can > count multiple complaints before blocking anything. Same story with AOL, > and Hotmail, and Cloudmark, and many others who've used this technique for > years. > > In all of those cases, they have safeguards to prevent gaming, to prevent > bouncing, and pretty much everything else anyone's suggested thus far in > this thread. > > > Last, anywhere that I've seen extensive use of forwards has had a maze > > of difficult to untangle abuse problems related to forwarded spam. Any > > site allowing forwarding should apply very robust filtering of outbound > > mail. > > Very true. MAAWG published a document last year which includes some > additional recommendations: > > http://www.maawg.org/about/publishedDocuments/MAAWG_Email_Forwarding_BP.pdf > > -- > J.D. Falk > Return Path Inc > http://www.returnpath.net/ > > > > ------------------------------ > > Message: 6 > Date: Thu, 26 Feb 2009 20:35:57 -0500 > From: Carl Ford > Subject: Re: Yahoo and their mail filters.. > To: Micheal Patterson > Cc: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > very old news. > > their filter restrictions have some very absurd rules > > On Tue, Feb 24, 2009 at 9:27 PM, Micheal Patterson < > micheal at spmedicalgroup.com> wrote: > > > This may be old news, but I've not been in the list for quite some time. > At > > any rate, is anyone else having issues with Yahoo blocking / deferring > > legitimate emails? > > > > My situation is that I host our corporate mx'ers on my network, one of > the > > companies that we recently purchased has Yahoo hosting their domains > mail. > > Mail traffic to them is getting temporarily deferred with the "421 4.7.0 > > [TS01] Messages from xxx.xxx.xxx.xxx temporarily deferred due to user > > complaints - 4.16.55.1; > > see http://postmaster.yahoo.com/421-ts01.html" > > > > The admin of the facility has contacted Yahoo about this but their > response > > was for "more information" when they were told that traffic from my mx to > > their domain was to being deferred. I may end up just having them > migrate > > to my systems just to maintain company communications if we can't clear > this > > up in a timely manner. > > > > -- > > Micheal Patterson > > > > > > > > > > > > > ------------------------------ > > Message: 7 > Date: Thu, 26 Feb 2009 18:15:08 -0700 > From: "J.D. Falk" > Subject: Re: Yahoo and their mail filters.. > To: nanog at nanog.org > Message-ID: <49A73E9C.1060604 at cybernothing.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Barry Shein wrote: > > > I suggested that probably 99% of the false positives I see could be > > avoided by just waiting until there are two or more complaints from > > the same source before firing it back as spam. > > I've developed systems for ISPs to handle inbound complaints from AOL & > such, and that's exactly what we did: multiple complaints were acted upon, > single complaints only fed into the aggregate stats. On the INBOUND side. > We didn't ask AOL to do that work for us. > > Many recipients of complaint feedback actually /want/ to receive every > complaint, because -- like John Levine -- they treat those complaints as > unsubscribe requests. > > Yours is not the common use case. > > -- > J.D. Falk > Return Path Inc > http://www.returnpath.net/ > > > > ------------------------------ > > Message: 8 > Date: Fri, 27 Feb 2009 07:34:46 +0530 > From: Suresh Ramasubramanian > Subject: Re: Yahoo and their mail filters.. > To: "J.D. Falk" > Cc: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Fri, Feb 27, 2009 at 6:45 AM, J.D. Falk > wrote: > > Many recipients of complaint feedback actually /want/ to receive every > > complaint, because -- like John Levine -- they treat those complaints as > > unsubscribe requests. > > That's ONE use case. But we are not senders, and we do use a feedback > loop because we are an ISP (like barry) but we dont have the luxury of > a purely geek (so largely clean e&oe pwned systems) userbase like > Barry has. > > In other words - we do get spammer customers. And the feedback loops > provide us near real time notification of these, allowing us to > terminate. > > > Yours is not the common use case. > > His IS the common use case. Just that he doesnt have the sort of > userbase that will generate usable FBLs (aka no significant number of > genuine spam issues on his network). For which he has to count > himself lucky. > > > > ------------------------------ > > Message: 9 > Date: Thu, 26 Feb 2009 20:17:37 -0800 > From: Brian Keefer > Subject: Re: Yahoo and their mail filters.. > To: "J.D. Falk" > Cc: nanog at nanog.org > Message-ID: <257F71E4-40FF-4587-9EAD-F8988465B119 at smtps.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Feb 26, 2009, at 5:08 PM, J.D. Falk wrote: > >> Blocking an entire site just because one John Doe user clicked a > >> button > >> they don't even understand just does not make sense. > > > > You're right -- but Yahoo! has a sufficiently large userbase that > > they can count multiple complaints before blocking anything. Same > > story with AOL, and Hotmail, and Cloudmark, and many others who've > > used this technique for years. > > This does not appear to be the case from external observation. It may > be in some cases that multiple reports are necessary, but it certainly > seems there are hair-triggers in others. For instance, see the > message from Eric Esslinger. > > As for not black-holing anything, I haven't personally verified with > Yahoo!, but others have reported that they do. It's pretty common > from what I've seen to simply make very high-scored messages disappear > and only send the mid-range stuff to the spam folder. Hotmail, as > mentioned, does this. One of the very large hosted filtering services > does as well. I'm not saying it's bad (it makes sense if you can > trust your scoring algorithm), but it does happen. Just because you > get _some_ stuff in your spam folder doesn't mean that's all the spam > that was blocked. > > -- > bk > > > > > > > ------------------------------ > > Message: 10 > Date: Thu, 26 Feb 2009 20:26:12 -0800 > From: Jo Rhett > Subject: Re: Yahoo and their mail filters.. > To: Ray Corbin > Cc: "nanog at nanog.org" > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > On Feb 25, 2009, at 8:14 AM, Ray Corbin wrote: > > It depends on your environment. I've seen where it is helpful and > > where it is overwhelming. If you are a smaller company and want to > > know why you keep getting blocked then those should help. If you are > > a larger company and get a several hundred a day, but you send 100k > > emails to AOL then it is not as big of a deal. If you are a shared > > hosting provider and you get a lot of them you should look into what > > is being sent to AOL, such as forwarded spam from customers 'auto > > forwards' (isolate the auto forwards to a separate IP address and > > simply don't sign up for the FBL for it).... If you have a good > > setup where only customer-originated email is being sent through the > > IP's you have a FBL on, then it is useful and you shouldn't get as > > many complaints. > > > Ray, you don't get it. What comes from AOL is literally every step > in a mother-daughter conversion. You get to read the entire thread. > Loving chat, mother and daughter back and forth. But one of them is > hitting SPAM on the e-mail *AFTER* replying to it and writing a nice > letter back. > > This is abuse of the abuse department. This isn't spam. Reading > through ~3k of these not-spams every day doesn't help us solve any > actual abuse problems. > > Feedback loops will not be useful until the providers of the feedback > loops accept reports about use of the spam reporting tools, and are > willing to go fix their user behavior. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > > > > ------------------------------ > > Message: 11 > Date: Thu, 26 Feb 2009 20:47:35 -0800 > From: Ricardo Oliveira > Subject: Road Runner DNS servers > To: nanog at nanog.org > Message-ID: <9F40AFA3-DABB-4DDC-8CE5-09393FF4E73A at cs.ucla.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Is there anyone clueful in this list from Road Runner(Time Warner > Cable) that can explain what's going on with their DNS servers - just > contacted their tech support and heard their DNS servers have been > under attack over the last 3 days.. > thanks, > > --Ricardo > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 13, Issue 145 > ************************************** > -- Thanks & Regards shivlu jain http://shivlu.blogspot.com/ 09312010137 From skoal at skoal.name Fri Feb 27 01:44:27 2009 From: skoal at skoal.name (Gergely Antal) Date: Fri, 27 Feb 2009 08:44:27 +0100 Subject: Documentation of switch maps In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D7540E0F4395@CPExchange1.cpgreeley.com> Message-ID: <49A799DB.8060609@skoal.name> Hi try netdot (https://netdot.uoregon.edu/trac/) It's a pretty good stuff ,but not easy to setup Blake Pfankuch wrote: > Howdy. > > Had a customer come to me this morning who wanted to create a > document for their switching infrastructure and thought I would > bounce it off the rest of the world on how you usually do this. > Typically I use a spreadsheet with outlines to define the "switch" > and then outlines for the ports and color coding for vlan's as well > as a description of the port. Curious what other people are doing, > as this would be a huge undertaking for a customer who is using an > entire /19 of rfc 1918 ip addresses and has well over 150 switches > and 40 active vlans. The want to be able to look at this document > and pull up any switch and look at the port and be able to see what > vlan the port is on, as well as what device it is connected to as > well as port channel membership, trunks and other fun things like > that. Needless to say their documentation is lacking on the physical > connectivity however their cisco infrastructure does have labels on > every port that goes to a named device outside of the DHCP pools. > Thoughts? > > Thanks, Blake Pfankuch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From cidr-report at potaroo.net Fri Feb 27 05:00:05 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Feb 2009 22:00:05 +1100 (EST) Subject: BGP Update Report Message-ID: <200902271100.n1RB05Vv061829@wattle.apnic.net> BGP Update Report Interval: 26-Jan-09 -to- 26-Feb-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 304975 6.6% 237.3 -- SIFY-AS-IN Sify Limited 2 - AS7643 131673 2.9% 209.3 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 3 - AS30890 50431 1.1% 113.1 -- EVOLVA Evolva Telecom 4 - AS6629 49010 1.1% 754.0 -- NOAA-AS - NOAA 5 - AS17974 34251 0.7% 67.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 6 - AS35805 33756 0.7% 90.0 -- UTG-AS United Telecom AS 7 - AS27757 33625 0.7% 275.6 -- ANDINATEL S.A. 8 - AS3130 33494 0.7% 257.6 -- RGNET-3130 RGnet/PSGnet 9 - AS6458 30997 0.7% 77.1 -- Telgua 10 - AS30306 29623 0.6% 7405.8 -- AfOL-Sz-AS 11 - AS17488 27653 0.6% 16.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS5056 26401 0.6% 227.6 -- INS-NET-2 - Iowa Network Services 13 - AS30969 25108 0.5% 3138.5 -- TAN-NET TransAfrica Networks 14 - AS5050 24017 0.5% 407.1 -- PSC-EXT - Pittsburgh Supercomputing Center 15 - AS16559 22988 0.5% 2554.2 -- REALCONNECT-01 - RealConnect, Inc 16 - AS8452 22311 0.5% 15.1 -- TEDATA TEDATA 17 - AS1785 22016 0.5% 11.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 18 - AS9829 21264 0.5% 33.3 -- BSNL-NIB National Internet Backbone 19 - AS23966 19534 0.4% 52.9 -- LDN-AS-AP LINKdotNET Telecom Limited 20 - AS8103 19354 0.4% 30.3 -- STATE-OF-FLA - Florida Department of Management Services - Technology Program TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30287 8019 0.2% 8019.0 -- ALON-USA - ALON USA, LP 2 - AS30306 29623 0.6% 7405.8 -- AfOL-Sz-AS 3 - AS12500 19258 0.4% 4814.5 -- RCS-AS RCS Autonomus System 4 - AS19017 3584 0.1% 3584.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 5 - AS30969 25108 0.5% 3138.5 -- TAN-NET TransAfrica Networks 6 - AS41382 3011 0.1% 3011.0 -- TELEPORT-AS Teleport LLC Network AS 7 - AS16559 22988 0.5% 2554.2 -- REALCONNECT-01 - RealConnect, Inc 8 - AS28194 6840 0.1% 2280.0 -- 9 - AS32398 11112 0.2% 1587.4 -- REALNET-ASN-1 10 - AS5033 13944 0.3% 1549.3 -- ISW - Internet Specialties West Inc. 11 - AS25970 7572 0.2% 1262.0 -- IAC - IAC Services LLC 12 - AS46328 9254 0.2% 1028.2 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 13 - AS23917 1013 0.0% 1013.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 14 - AS29224 1964 0.0% 982.0 -- HELLMANN Hellmann Worldwide Logistics GmbH & Co KG 15 - AS46781 914 0.0% 914.0 -- ASN1 - White Nile Group, Inc. 16 - AS35335 878 0.0% 878.0 -- ESSTU-AS East-Siberian State Technological University AS 17 - AS39107 1754 0.0% 877.0 -- INTERLAN-AS Asociatia Interlan 18 - AS48144 867 0.0% 867.0 -- NETWORKTECH Network Technology 19 - AS9796 2550 0.1% 850.0 -- WIPRO Internet Service Providers 20 - AS35410 5512 0.1% 787.4 -- RU-LVS-AS LVS AS Number TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 221.134.32.0/24 33591 0.7% AS9583 -- SIFY-AS-IN Sify Limited 2 - 72.23.246.0/24 23792 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 3 - 210.214.177.0/24 21373 0.4% AS9583 -- SIFY-AS-IN Sify Limited 4 - 210.214.232.0/24 21083 0.4% AS9583 -- SIFY-AS-IN Sify Limited 5 - 210.214.132.0/24 21078 0.4% AS9583 -- SIFY-AS-IN Sify Limited 6 - 210.214.146.0/24 21041 0.4% AS9583 -- SIFY-AS-IN Sify Limited 7 - 210.214.222.0/24 20842 0.4% AS9583 -- SIFY-AS-IN Sify Limited 8 - 210.214.117.0/24 20824 0.4% AS9583 -- SIFY-AS-IN Sify Limited 9 - 210.214.184.0/24 19707 0.4% AS9583 -- SIFY-AS-IN Sify Limited 10 - 210.210.127.0/24 19020 0.4% AS9583 -- SIFY-AS-IN Sify Limited 11 - 221.135.105.0/24 18475 0.4% AS9583 -- SIFY-AS-IN Sify Limited 12 - 210.214.156.0/24 18223 0.3% AS9583 -- SIFY-AS-IN Sify Limited 13 - 190.152.103.0/24 17936 0.3% AS27757 -- ANDINATEL S.A. 14 - 192.35.129.0/24 16419 0.3% AS6629 -- NOAA-AS - NOAA 15 - 192.102.88.0/24 16235 0.3% AS6629 -- NOAA-AS - NOAA 16 - 198.77.177.0/24 16104 0.3% AS6629 -- NOAA-AS - NOAA 17 - 221.135.107.0/24 15320 0.3% AS9583 -- SIFY-AS-IN Sify Limited 18 - 212.85.223.0/24 14721 0.3% AS30306 -- AfOL-Sz-AS 19 - 212.85.220.0/24 14682 0.3% AS30306 -- AfOL-Sz-AS 20 - 190.152.100.0/24 14231 0.3% AS27757 -- ANDINATEL S.A. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 27 05:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Feb 2009 22:00:02 +1100 (EST) Subject: The Cidr Report Message-ID: <200902271100.n1RB02iT061823@wattle.apnic.net> This report has been generated at Fri Feb 27 21:15:46 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 20-02-09 287886 179242 21-02-09 287773 179438 22-02-09 287877 179384 23-02-09 287972 179485 24-02-09 288091 179449 25-02-09 288143 179301 26-02-09 288137 179706 27-02-09 288243 180010 AS Summary 30771 Number of ASes in routing system 13054 Number of ASes announcing only one prefix 4364 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89807872 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 27Feb09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 288489 180199 108290 37.5% All ASes AS6389 4364 354 4010 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4227 1822 2405 56.9% TWTC - tw telecom holdings, inc. AS209 2834 1252 1582 55.8% ASN-QWEST - Qwest Communications Corporation AS4766 1808 526 1282 70.9% KIXS-AS-KR Korea Telecom AS17488 1523 339 1184 77.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1215 234 981 80.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1018 60 958 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8452 1230 327 903 73.4% TEDATA TEDATA AS8151 1442 580 862 59.8% Uninet S.A. de C.V. AS1785 1752 909 843 48.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS11492 1199 476 723 60.3% CABLEONE - CABLE ONE, INC. AS19262 956 246 710 74.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 752 167 585 77.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1140 558 582 51.1% LEVEL3 Level 3 Communications AS7545 747 190 557 74.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS6478 1241 700 541 43.6% ATT-INTERNET3 - AT&T WorldNet Services AS2706 551 45 506 91.8% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17908 605 111 494 81.7% TCISL Tata Communications AS22047 606 117 489 80.7% VTR BANDA ANCHA S.A. AS855 620 161 459 74.0% CANET-ASN-4 - Bell Aliant AS4808 607 157 450 74.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 675 240 435 64.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1441 1007 434 30.1% ATT-INTERNET4 - AT&T WorldNet Services AS4134 927 505 422 45.5% CHINANET-BACKBONE No.31,Jin-rong Street AS4668 701 285 416 59.3% LGNET-AS-KR LG CNS AS9443 507 91 416 82.1% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 527 117 410 77.8% GIGAINFRA BB TECHNOLOGY Corp. AS7011 956 553 403 42.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS6471 438 70 368 84.0% ENTEL CHILE S.A. AS3549 675 312 363 53.8% GBLX Global Crossing Ltd. Total 37284 12511 24773 66.4% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.172.64.0/19 AS15570 Internap European Autonomous System 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 155.254.0.0/16 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.8.160.0/19 AS18109 EPOWER-TW E-Test Digital Technology Corp. 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.159.128.0/18 AS18109 EPOWER-TW E-Test Digital Technology Corp. 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.21.96.0/20 AS12006 EUREKANETWORKS-AS-12006 - eLink Communications INC. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.236.64.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 209.236.96.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet 220.247.128.0/19 AS18109 EPOWER-TW E-Test Digital Technology Corp. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From rcorbin at traffiq.com Fri Feb 27 07:34:36 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Fri, 27 Feb 2009 07:34:36 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: References: , Message-ID: I'm quite aware of what comes from AOL's feedback loops, I used it for years when I was an email administrator for a large shared webhosting company processing ~2.5million outbound emails per day. I remember getting thousand reports per day. You can automate the process and that is why they use a standard format (Parse the message and run reports on who is getting spam complaints etc etc). If you are sending them X emails per day you can expect at least 0.3% or so to be marked as spam (including forwarders). I cant imagine you receiving 'thousands' of complaints like the one you are referring to...and if you are then you are sending them a larger volume then 100,000 emails per day (non-forwarded). If the feedback loop becomes more of a burden then a helpful notification tool unsubscribe. -r ________________________________________ From: Jo Rhett [jrhett at netconsonance.com] Sent: Thursday, February 26, 2009 11:26 PM To: Ray Corbin Cc: Richey; nanog at nanog.org Subject: Re: Yahoo and their mail filters.. On Feb 25, 2009, at 8:14 AM, Ray Corbin wrote: > It depends on your environment. I've seen where it is helpful and > where it is overwhelming. If you are a smaller company and want to > know why you keep getting blocked then those should help. If you are > a larger company and get a several hundred a day, but you send 100k > emails to AOL then it is not as big of a deal. If you are a shared > hosting provider and you get a lot of them you should look into what > is being sent to AOL, such as forwarded spam from customers 'auto > forwards' (isolate the auto forwards to a separate IP address and > simply don't sign up for the FBL for it).... If you have a good > setup where only customer-originated email is being sent through the > IP's you have a FBL on, then it is useful and you shouldn't get as > many complaints. Ray, you don't get it. What comes from AOL is literally every step in a mother-daughter conversion. You get to read the entire thread. Loving chat, mother and daughter back and forth. But one of them is hitting SPAM on the e-mail *AFTER* replying to it and writing a nice letter back. This is abuse of the abuse department. This isn't spam. Reading through ~3k of these not-spams every day doesn't help us solve any actual abuse problems. Feedback loops will not be useful until the providers of the feedback loops accept reports about use of the spam reporting tools, and are willing to go fix their user behavior. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From ka at pacific.net Fri Feb 27 09:10:10 2009 From: ka at pacific.net (Ken A) Date: Fri, 27 Feb 2009 09:10:10 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: References: Message-ID: <49A80252.40401@pacific.net> Jo Rhett wrote: > On Feb 25, 2009, at 8:14 AM, Ray Corbin wrote: >> It depends on your environment. I've seen where it is helpful and >> where it is overwhelming. If you are a smaller company and want to >> know why you keep getting blocked then those should help. If you are a >> larger company and get a several hundred a day, but you send 100k >> emails to AOL then it is not as big of a deal. If you are a shared >> hosting provider and you get a lot of them you should look into what >> is being sent to AOL, such as forwarded spam from customers 'auto >> forwards' (isolate the auto forwards to a separate IP address and >> simply don't sign up for the FBL for it).... If you have a good setup >> where only customer-originated email is being sent through the IP's >> you have a FBL on, then it is useful and you shouldn't get as many >> complaints. > > > Ray, you don't get it. What comes from AOL is literally every step in > a mother-daughter conversion. You get to read the entire thread. > Loving chat, mother and daughter back and forth. But one of them is > hitting SPAM on the e-mail *AFTER* replying to it and writing a nice > letter back. > > This is abuse of the abuse department. This isn't spam. Reading > through ~3k of these not-spams every day doesn't help us solve any > actual abuse problems. > > Feedback loops will not be useful until the providers of the feedback > loops accept reports about use of the spam reporting tools, and are > willing to go fix their user behavior. > I agree that aol could do a better job of filtering the outbound, but I don't think it's a useless system. We get a few dozen from aol a day unless we have a real problem. I see the mother-daughter conversations (worst), the subscribed lazy user emails - we encourage our mailing list senders to include unsub links - partly to make it easy for _us_ to click and unsub these dummies. And we see the 'real deal' now and then; usually an exploited php script being abused by spammers, or someone who has had their password sniffed, or stolen. Most of these are users who travel and don't use secure protocols, or have a teenager in the house (the most insecure protocol is adolescence). We appreciate aol's efforts, imperfect as they are. Ken -- Ken Anderson Pacific Internet - http://www.pacific.net From cscora at apnic.net Fri Feb 27 12:15:17 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Feb 2009 04:15:17 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200902271815.n1RIFHF8019955@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Feb, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 281421 Prefixes after maximum aggregation: 133739 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 137854 Total ASes present in the Internet Routing Table: 30695 Prefixes per ASN: 9.17 Origin-only ASes present in the Internet Routing Table: 26717 Origin ASes announcing only one prefix: 12993 Transit ASes present in the Internet Routing Table: 3978 Transit-only ASes present in the Internet Routing Table: 95 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 501 Unregistered ASNs in the Routing Table: 171 Number of 32-bit ASNs allocated by the RIRs: 115 Prefixes from 32-bit ASNs in the Routing Table: 17 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 213 Number of addresses announced to Internet: 2009268672 Equivalent to 119 /8s, 195 /16s and 1 /24s Percentage of available address space announced: 54.2 Percentage of allocated address space announced: 63.4 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 75.9 Total number of prefixes smaller than registry allocations: 138384 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 65010 Total APNIC prefixes after maximum aggregation: 23348 APNIC Deaggregation factor: 2.78 Prefixes being announced from the APNIC address blocks: 61875 Unique aggregates announced from the APNIC address blocks: 28193 APNIC Region origin ASes present in the Internet Routing Table: 3541 APNIC Prefixes per ASN: 17.47 APNIC Region origin ASes announcing only one prefix: 957 APNIC Region transit ASes present in the Internet Routing Table: 542 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 403835552 Equivalent to 24 /8s, 18 /16s and 10 /24s Percentage of available APNIC address space announced: 80.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123979 Total ARIN prefixes after maximum aggregation: 65438 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 93416 Unique aggregates announced from the ARIN address blocks: 35786 ARIN Region origin ASes present in the Internet Routing Table: 12813 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix: 4929 ARIN Region transit ASes present in the Internet Routing Table: 1238 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 416285760 Equivalent to 24 /8s, 208 /16s and 4 /24s Percentage of available ARIN address space announced: 80.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 64023 Total RIPE prefixes after maximum aggregation: 37503 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 58568 Unique aggregates announced from the RIPE address blocks: 38936 RIPE Region origin ASes present in the Internet Routing Table: 12729 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 6677 RIPE Region transit ASes present in the Internet Routing Table: 1919 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 389934048 Equivalent to 23 /8s, 61 /16s and 235 /24s Percentage of available RIPE address space announced: 83.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23356 Total LACNIC prefixes after maximum aggregation: 5679 LACNIC Deaggregation factor: 4.11 Prefixes being announced from the LACNIC address blocks: 21538 Unique aggregates announced from the LACNIC address blocks: 11822 LACNIC Region origin ASes present in the Internet Routing Table: 1070 LACNIC Prefixes per ASN: 20.13 LACNIC Region origin ASes announcing only one prefix: 344 LACNIC Region transit ASes present in the Internet Routing Table: 178 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 61102208 Equivalent to 3 /8s, 164 /16s and 88 /24s Percentage of available LACNIC address space announced: 60.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4584 Total AfriNIC prefixes after maximum aggregation: 1383 AfriNIC Deaggregation factor: 3.31 Prefixes being announced from the AfriNIC address blocks: 4313 Unique aggregates announced from the AfriNIC address blocks: 1394 AfriNIC Region origin ASes present in the Internet Routing Table: 286 AfriNIC Prefixes per ASN: 15.08 AfriNIC Region origin ASes announcing only one prefix: 86 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10050048 Equivalent to 0 /8s, 153 /16s and 90 /24s Percentage of available AfriNIC address space announced: 30.0 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1684 6928 395 Korea Telecom (KIX) 17488 1517 118 101 Hathway IP Over Cable Interne 4755 1215 430 181 TATA Communications formerly 9583 1090 86 519 Sify Limited 4134 927 16239 367 CHINANET-BACKBONE 18101 754 198 28 Reliance Infocom Ltd Internet 7545 730 158 100 TPG Internet Pty Ltd 9498 691 297 53 BHARTI BT INTERNET LTD. 24560 675 228 174 Bharti Airtel Ltd. 9829 631 491 18 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4364 3688 342 bellsouth.net, inc. 209 2832 4147 615 Qwest 4323 1771 1081 377 Time Warner Telecom 1785 1752 733 139 PaeTec Communications, Inc. 20115 1608 1427 720 Charter Communications 7018 1440 5878 1003 AT&T WorldNet Services 2386 1261 681 900 AT&T Data Communications Serv 6478 1254 296 529 AT&T Worldnet Services 11492 1201 192 12 Cable One 3356 1137 10976 439 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1233 188 7 TEDATA 30890 445 88 202 SC Kappa Invexim SRL 3292 444 1762 389 TDC Tele Danmark 12479 397 578 6 Uni2 Autonomous System 3320 350 7081 293 Deutsche Telekom AG 3301 340 1669 305 TeliaNet Sweden 8866 337 109 22 Bulgarian Telecommunication C 3215 334 2978 103 France Telecom Transpac 29049 328 26 3 AzerSat LLC. 8551 313 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1441 2831 230 UniNet S.A. de C.V. 10620 791 174 98 TVCABLE BOGOTA 11830 694 299 9 Instituto Costarricense de El 22047 606 302 14 VTR PUNTO NET S.A. 7303 513 256 80 Telecom Argentina Stet-France 6471 438 95 32 ENTEL CHILE S.A. 16814 427 27 11 NSS, S.A. 11172 404 118 74 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 373 506 23 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 665 75 29 LINKdotNET AS number 20858 292 34 3 This AS will be used to conne 3741 271 857 229 The Internet Solution 2018 242 215 142 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 130 15 8 Ci Telecom Autonomous system 5536 119 7 20 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 117 523 65 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4364 3688 342 bellsouth.net, inc. 209 2832 4147 615 Qwest 4323 1771 1081 377 Time Warner Telecom 1785 1752 733 139 PaeTec Communications, Inc. 4766 1684 6928 395 Korea Telecom (KIX) 20115 1608 1427 720 Charter Communications 17488 1517 118 101 Hathway IP Over Cable Interne 8151 1441 2831 230 UniNet S.A. de C.V. 7018 1440 5878 1003 AT&T WorldNet Services 2386 1261 681 900 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2832 2217 Qwest 1785 1752 1613 PaeTec Communications, Inc. 17488 1517 1416 Hathway IP Over Cable Interne 4323 1771 1394 Time Warner Telecom 4766 1684 1289 Korea Telecom (KIX) 8452 1233 1226 TEDATA 8151 1441 1211 UniNet S.A. de C.V. 11492 1201 1189 Cable One 18566 1061 1051 Covad Communications 4755 1215 1034 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:55 /12:162 /13:317 /14:578 /15:1130 /16:10345 /17:4598 /18:7913 /19:16926 /20:19940 /21:19668 /22:24922 /23:25170 /24:147378 /25:710 /26:853 /27:586 /28:103 /29:8 /30:3 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2843 4364 bellsouth.net, inc. 209 1571 2832 Qwest 4766 1391 1684 Korea Telecom (KIX) 17488 1296 1517 Hathway IP Over Cable Interne 8452 1212 1233 TEDATA 11492 1161 1201 Cable One 1785 1158 1752 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 954 1261 AT&T Data Communications Serv 9583 942 1090 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:170 12:2203 13:2 15:20 16:3 17:4 20:35 24:1120 32:51 38:544 40:96 41:1962 43:1 44:2 47:19 52:3 55:2 56:3 57:25 58:535 59:620 60:458 61:1098 62:1108 63:2014 64:3529 65:2423 66:3548 67:1448 68:661 69:2481 70:506 71:158 72:1618 73:2 74:1429 75:201 76:311 77:786 78:559 79:325 80:971 81:834 82:548 83:415 84:586 85:1010 86:398 87:626 88:349 89:1411 90:42 91:2011 92:271 93:1128 94:1127 95:463 96:92 97:181 98:192 99:16 109:1 112:71 113:78 114:196 115:229 116:1125 117:491 118:286 119:636 120:133 121:710 122:962 123:523 124:936 125:1289 128:221 129:222 130:135 131:412 132:73 133:9 134:336 135:38 136:222 137:139 138:145 139:79 140:413 141:105 142:384 143:329 144:319 145:40 146:373 147:152 148:537 149:230 150:141 151:199 152:151 153:133 154:10 155:260 156:170 157:294 158:128 159:242 160:282 161:138 162:269 163:140 164:517 165:504 166:274 167:357 168:678 169:163 170:472 171:39 172:10 173:231 174:84 178:1 186:9 187:43 188:6 189:300 190:2614 192:5819 193:4215 194:3323 195:2716 196:1057 198:3705 199:3285 200:5497 201:1503 202:7836 203:8006 204:3943 205:2164 206:2350 207:2826 208:3850 209:3475 210:2644 211:1124 212:1504 213:1700 214:69 215:26 216:4554 217:1218 218:366 219:409 220:1217 221:453 222:319 End of report From cscora at apnic.net Fri Feb 27 12:15:17 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Feb 2009 04:15:17 +1000 (EST) Subject: [SANOG] Weekly Routing Table Report Message-ID: <200902271815.n1RIFHF8019955@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Feb, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 281421 Prefixes after maximum aggregation: 133739 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 137854 Total ASes present in the Internet Routing Table: 30695 Prefixes per ASN: 9.17 Origin-only ASes present in the Internet Routing Table: 26717 Origin ASes announcing only one prefix: 12993 Transit ASes present in the Internet Routing Table: 3978 Transit-only ASes present in the Internet Routing Table: 95 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 501 Unregistered ASNs in the Routing Table: 171 Number of 32-bit ASNs allocated by the RIRs: 115 Prefixes from 32-bit ASNs in the Routing Table: 17 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 213 Number of addresses announced to Internet: 2009268672 Equivalent to 119 /8s, 195 /16s and 1 /24s Percentage of available address space announced: 54.2 Percentage of allocated address space announced: 63.4 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 75.9 Total number of prefixes smaller than registry allocations: 138384 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 65010 Total APNIC prefixes after maximum aggregation: 23348 APNIC Deaggregation factor: 2.78 Prefixes being announced from the APNIC address blocks: 61875 Unique aggregates announced from the APNIC address blocks: 28193 APNIC Region origin ASes present in the Internet Routing Table: 3541 APNIC Prefixes per ASN: 17.47 APNIC Region origin ASes announcing only one prefix: 957 APNIC Region transit ASes present in the Internet Routing Table: 542 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 403835552 Equivalent to 24 /8s, 18 /16s and 10 /24s Percentage of available APNIC address space announced: 80.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123979 Total ARIN prefixes after maximum aggregation: 65438 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 93416 Unique aggregates announced from the ARIN address blocks: 35786 ARIN Region origin ASes present in the Internet Routing Table: 12813 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix: 4929 ARIN Region transit ASes present in the Internet Routing Table: 1238 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 416285760 Equivalent to 24 /8s, 208 /16s and 4 /24s Percentage of available ARIN address space announced: 80.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 64023 Total RIPE prefixes after maximum aggregation: 37503 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 58568 Unique aggregates announced from the RIPE address blocks: 38936 RIPE Region origin ASes present in the Internet Routing Table: 12729 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 6677 RIPE Region transit ASes present in the Internet Routing Table: 1919 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 389934048 Equivalent to 23 /8s, 61 /16s and 235 /24s Percentage of available RIPE address space announced: 83.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23356 Total LACNIC prefixes after maximum aggregation: 5679 LACNIC Deaggregation factor: 4.11 Prefixes being announced from the LACNIC address blocks: 21538 Unique aggregates announced from the LACNIC address blocks: 11822 LACNIC Region origin ASes present in the Internet Routing Table: 1070 LACNIC Prefixes per ASN: 20.13 LACNIC Region origin ASes announcing only one prefix: 344 LACNIC Region transit ASes present in the Internet Routing Table: 178 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 61102208 Equivalent to 3 /8s, 164 /16s and 88 /24s Percentage of available LACNIC address space announced: 60.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4584 Total AfriNIC prefixes after maximum aggregation: 1383 AfriNIC Deaggregation factor: 3.31 Prefixes being announced from the AfriNIC address blocks: 4313 Unique aggregates announced from the AfriNIC address blocks: 1394 AfriNIC Region origin ASes present in the Internet Routing Table: 286 AfriNIC Prefixes per ASN: 15.08 AfriNIC Region origin ASes announcing only one prefix: 86 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10050048 Equivalent to 0 /8s, 153 /16s and 90 /24s Percentage of available AfriNIC address space announced: 30.0 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1684 6928 395 Korea Telecom (KIX) 17488 1517 118 101 Hathway IP Over Cable Interne 4755 1215 430 181 TATA Communications formerly 9583 1090 86 519 Sify Limited 4134 927 16239 367 CHINANET-BACKBONE 18101 754 198 28 Reliance Infocom Ltd Internet 7545 730 158 100 TPG Internet Pty Ltd 9498 691 297 53 BHARTI BT INTERNET LTD. 24560 675 228 174 Bharti Airtel Ltd. 9829 631 491 18 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4364 3688 342 bellsouth.net, inc. 209 2832 4147 615 Qwest 4323 1771 1081 377 Time Warner Telecom 1785 1752 733 139 PaeTec Communications, Inc. 20115 1608 1427 720 Charter Communications 7018 1440 5878 1003 AT&T WorldNet Services 2386 1261 681 900 AT&T Data Communications Serv 6478 1254 296 529 AT&T Worldnet Services 11492 1201 192 12 Cable One 3356 1137 10976 439 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1233 188 7 TEDATA 30890 445 88 202 SC Kappa Invexim SRL 3292 444 1762 389 TDC Tele Danmark 12479 397 578 6 Uni2 Autonomous System 3320 350 7081 293 Deutsche Telekom AG 3301 340 1669 305 TeliaNet Sweden 8866 337 109 22 Bulgarian Telecommunication C 3215 334 2978 103 France Telecom Transpac 29049 328 26 3 AzerSat LLC. 8551 313 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1441 2831 230 UniNet S.A. de C.V. 10620 791 174 98 TVCABLE BOGOTA 11830 694 299 9 Instituto Costarricense de El 22047 606 302 14 VTR PUNTO NET S.A. 7303 513 256 80 Telecom Argentina Stet-France 6471 438 95 32 ENTEL CHILE S.A. 16814 427 27 11 NSS, S.A. 11172 404 118 74 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 373 506 23 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 665 75 29 LINKdotNET AS number 20858 292 34 3 This AS will be used to conne 3741 271 857 229 The Internet Solution 2018 242 215 142 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 130 15 8 Ci Telecom Autonomous system 5536 119 7 20 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 117 523 65 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4364 3688 342 bellsouth.net, inc. 209 2832 4147 615 Qwest 4323 1771 1081 377 Time Warner Telecom 1785 1752 733 139 PaeTec Communications, Inc. 4766 1684 6928 395 Korea Telecom (KIX) 20115 1608 1427 720 Charter Communications 17488 1517 118 101 Hathway IP Over Cable Interne 8151 1441 2831 230 UniNet S.A. de C.V. 7018 1440 5878 1003 AT&T WorldNet Services 2386 1261 681 900 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2832 2217 Qwest 1785 1752 1613 PaeTec Communications, Inc. 17488 1517 1416 Hathway IP Over Cable Interne 4323 1771 1394 Time Warner Telecom 4766 1684 1289 Korea Telecom (KIX) 8452 1233 1226 TEDATA 8151 1441 1211 UniNet S.A. de C.V. 11492 1201 1189 Cable One 18566 1061 1051 Covad Communications 4755 1215 1034 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:55 /12:162 /13:317 /14:578 /15:1130 /16:10345 /17:4598 /18:7913 /19:16926 /20:19940 /21:19668 /22:24922 /23:25170 /24:147378 /25:710 /26:853 /27:586 /28:103 /29:8 /30:3 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2843 4364 bellsouth.net, inc. 209 1571 2832 Qwest 4766 1391 1684 Korea Telecom (KIX) 17488 1296 1517 Hathway IP Over Cable Interne 8452 1212 1233 TEDATA 11492 1161 1201 Cable One 1785 1158 1752 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 954 1261 AT&T Data Communications Serv 9583 942 1090 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:170 12:2203 13:2 15:20 16:3 17:4 20:35 24:1120 32:51 38:544 40:96 41:1962 43:1 44:2 47:19 52:3 55:2 56:3 57:25 58:535 59:620 60:458 61:1098 62:1108 63:2014 64:3529 65:2423 66:3548 67:1448 68:661 69:2481 70:506 71:158 72:1618 73:2 74:1429 75:201 76:311 77:786 78:559 79:325 80:971 81:834 82:548 83:415 84:586 85:1010 86:398 87:626 88:349 89:1411 90:42 91:2011 92:271 93:1128 94:1127 95:463 96:92 97:181 98:192 99:16 109:1 112:71 113:78 114:196 115:229 116:1125 117:491 118:286 119:636 120:133 121:710 122:962 123:523 124:936 125:1289 128:221 129:222 130:135 131:412 132:73 133:9 134:336 135:38 136:222 137:139 138:145 139:79 140:413 141:105 142:384 143:329 144:319 145:40 146:373 147:152 148:537 149:230 150:141 151:199 152:151 153:133 154:10 155:260 156:170 157:294 158:128 159:242 160:282 161:138 162:269 163:140 164:517 165:504 166:274 167:357 168:678 169:163 170:472 171:39 172:10 173:231 174:84 178:1 186:9 187:43 188:6 189:300 190:2614 192:5819 193:4215 194:3323 195:2716 196:1057 198:3705 199:3285 200:5497 201:1503 202:7836 203:8006 204:3943 205:2164 206:2350 207:2826 208:3850 209:3475 210:2644 211:1124 212:1504 213:1700 214:69 215:26 216:4554 217:1218 218:366 219:409 220:1217 221:453 222:319 End of report -- This is the SANOG (http://www.sanog.org/) mailing list. From cscora at apnic.net Fri Feb 27 12:15:17 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Feb 2009 04:15:17 +1000 (EST) Subject: [SANOG] Weekly Routing Table Report Message-ID: <200902271815.n1RIFHF8019955@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Feb, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 281421 Prefixes after maximum aggregation: 133739 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 137854 Total ASes present in the Internet Routing Table: 30695 Prefixes per ASN: 9.17 Origin-only ASes present in the Internet Routing Table: 26717 Origin ASes announcing only one prefix: 12993 Transit ASes present in the Internet Routing Table: 3978 Transit-only ASes present in the Internet Routing Table: 95 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 501 Unregistered ASNs in the Routing Table: 171 Number of 32-bit ASNs allocated by the RIRs: 115 Prefixes from 32-bit ASNs in the Routing Table: 17 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 213 Number of addresses announced to Internet: 2009268672 Equivalent to 119 /8s, 195 /16s and 1 /24s Percentage of available address space announced: 54.2 Percentage of allocated address space announced: 63.4 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 75.9 Total number of prefixes smaller than registry allocations: 138384 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 65010 Total APNIC prefixes after maximum aggregation: 23348 APNIC Deaggregation factor: 2.78 Prefixes being announced from the APNIC address blocks: 61875 Unique aggregates announced from the APNIC address blocks: 28193 APNIC Region origin ASes present in the Internet Routing Table: 3541 APNIC Prefixes per ASN: 17.47 APNIC Region origin ASes announcing only one prefix: 957 APNIC Region transit ASes present in the Internet Routing Table: 542 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 403835552 Equivalent to 24 /8s, 18 /16s and 10 /24s Percentage of available APNIC address space announced: 80.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123979 Total ARIN prefixes after maximum aggregation: 65438 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 93416 Unique aggregates announced from the ARIN address blocks: 35786 ARIN Region origin ASes present in the Internet Routing Table: 12813 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix: 4929 ARIN Region transit ASes present in the Internet Routing Table: 1238 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 416285760 Equivalent to 24 /8s, 208 /16s and 4 /24s Percentage of available ARIN address space announced: 80.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 64023 Total RIPE prefixes after maximum aggregation: 37503 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 58568 Unique aggregates announced from the RIPE address blocks: 38936 RIPE Region origin ASes present in the Internet Routing Table: 12729 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 6677 RIPE Region transit ASes present in the Internet Routing Table: 1919 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 389934048 Equivalent to 23 /8s, 61 /16s and 235 /24s Percentage of available RIPE address space announced: 83.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23356 Total LACNIC prefixes after maximum aggregation: 5679 LACNIC Deaggregation factor: 4.11 Prefixes being announced from the LACNIC address blocks: 21538 Unique aggregates announced from the LACNIC address blocks: 11822 LACNIC Region origin ASes present in the Internet Routing Table: 1070 LACNIC Prefixes per ASN: 20.13 LACNIC Region origin ASes announcing only one prefix: 344 LACNIC Region transit ASes present in the Internet Routing Table: 178 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 61102208 Equivalent to 3 /8s, 164 /16s and 88 /24s Percentage of available LACNIC address space announced: 60.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4584 Total AfriNIC prefixes after maximum aggregation: 1383 AfriNIC Deaggregation factor: 3.31 Prefixes being announced from the AfriNIC address blocks: 4313 Unique aggregates announced from the AfriNIC address blocks: 1394 AfriNIC Region origin ASes present in the Internet Routing Table: 286 AfriNIC Prefixes per ASN: 15.08 AfriNIC Region origin ASes announcing only one prefix: 86 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10050048 Equivalent to 0 /8s, 153 /16s and 90 /24s Percentage of available AfriNIC address space announced: 30.0 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1684 6928 395 Korea Telecom (KIX) 17488 1517 118 101 Hathway IP Over Cable Interne 4755 1215 430 181 TATA Communications formerly 9583 1090 86 519 Sify Limited 4134 927 16239 367 CHINANET-BACKBONE 18101 754 198 28 Reliance Infocom Ltd Internet 7545 730 158 100 TPG Internet Pty Ltd 9498 691 297 53 BHARTI BT INTERNET LTD. 24560 675 228 174 Bharti Airtel Ltd. 9829 631 491 18 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4364 3688 342 bellsouth.net, inc. 209 2832 4147 615 Qwest 4323 1771 1081 377 Time Warner Telecom 1785 1752 733 139 PaeTec Communications, Inc. 20115 1608 1427 720 Charter Communications 7018 1440 5878 1003 AT&T WorldNet Services 2386 1261 681 900 AT&T Data Communications Serv 6478 1254 296 529 AT&T Worldnet Services 11492 1201 192 12 Cable One 3356 1137 10976 439 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1233 188 7 TEDATA 30890 445 88 202 SC Kappa Invexim SRL 3292 444 1762 389 TDC Tele Danmark 12479 397 578 6 Uni2 Autonomous System 3320 350 7081 293 Deutsche Telekom AG 3301 340 1669 305 TeliaNet Sweden 8866 337 109 22 Bulgarian Telecommunication C 3215 334 2978 103 France Telecom Transpac 29049 328 26 3 AzerSat LLC. 8551 313 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1441 2831 230 UniNet S.A. de C.V. 10620 791 174 98 TVCABLE BOGOTA 11830 694 299 9 Instituto Costarricense de El 22047 606 302 14 VTR PUNTO NET S.A. 7303 513 256 80 Telecom Argentina Stet-France 6471 438 95 32 ENTEL CHILE S.A. 16814 427 27 11 NSS, S.A. 11172 404 118 74 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 373 506 23 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 665 75 29 LINKdotNET AS number 20858 292 34 3 This AS will be used to conne 3741 271 857 229 The Internet Solution 2018 242 215 142 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 130 15 8 Ci Telecom Autonomous system 5536 119 7 20 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 117 523 65 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4364 3688 342 bellsouth.net, inc. 209 2832 4147 615 Qwest 4323 1771 1081 377 Time Warner Telecom 1785 1752 733 139 PaeTec Communications, Inc. 4766 1684 6928 395 Korea Telecom (KIX) 20115 1608 1427 720 Charter Communications 17488 1517 118 101 Hathway IP Over Cable Interne 8151 1441 2831 230 UniNet S.A. de C.V. 7018 1440 5878 1003 AT&T WorldNet Services 2386 1261 681 900 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2832 2217 Qwest 1785 1752 1613 PaeTec Communications, Inc. 17488 1517 1416 Hathway IP Over Cable Interne 4323 1771 1394 Time Warner Telecom 4766 1684 1289 Korea Telecom (KIX) 8452 1233 1226 TEDATA 8151 1441 1211 UniNet S.A. de C.V. 11492 1201 1189 Cable One 18566 1061 1051 Covad Communications 4755 1215 1034 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:55 /12:162 /13:317 /14:578 /15:1130 /16:10345 /17:4598 /18:7913 /19:16926 /20:19940 /21:19668 /22:24922 /23:25170 /24:147378 /25:710 /26:853 /27:586 /28:103 /29:8 /30:3 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2843 4364 bellsouth.net, inc. 209 1571 2832 Qwest 4766 1391 1684 Korea Telecom (KIX) 17488 1296 1517 Hathway IP Over Cable Interne 8452 1212 1233 TEDATA 11492 1161 1201 Cable One 1785 1158 1752 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 954 1261 AT&T Data Communications Serv 9583 942 1090 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:170 12:2203 13:2 15:20 16:3 17:4 20:35 24:1120 32:51 38:544 40:96 41:1962 43:1 44:2 47:19 52:3 55:2 56:3 57:25 58:535 59:620 60:458 61:1098 62:1108 63:2014 64:3529 65:2423 66:3548 67:1448 68:661 69:2481 70:506 71:158 72:1618 73:2 74:1429 75:201 76:311 77:786 78:559 79:325 80:971 81:834 82:548 83:415 84:586 85:1010 86:398 87:626 88:349 89:1411 90:42 91:2011 92:271 93:1128 94:1127 95:463 96:92 97:181 98:192 99:16 109:1 112:71 113:78 114:196 115:229 116:1125 117:491 118:286 119:636 120:133 121:710 122:962 123:523 124:936 125:1289 128:221 129:222 130:135 131:412 132:73 133:9 134:336 135:38 136:222 137:139 138:145 139:79 140:413 141:105 142:384 143:329 144:319 145:40 146:373 147:152 148:537 149:230 150:141 151:199 152:151 153:133 154:10 155:260 156:170 157:294 158:128 159:242 160:282 161:138 162:269 163:140 164:517 165:504 166:274 167:357 168:678 169:163 170:472 171:39 172:10 173:231 174:84 178:1 186:9 187:43 188:6 189:300 190:2614 192:5819 193:4215 194:3323 195:2716 196:1057 198:3705 199:3285 200:5497 201:1503 202:7836 203:8006 204:3943 205:2164 206:2350 207:2826 208:3850 209:3475 210:2644 211:1124 212:1504 213:1700 214:69 215:26 216:4554 217:1218 218:366 219:409 220:1217 221:453 222:319 End of report -- This is the SANOG (http://www.sanog.org/) mailing list. From shivlu.jain at gmail.com Sat Feb 28 00:18:45 2009 From: shivlu.jain at gmail.com (Shivlu Jain) Date: Sat, 28 Feb 2009 11:48:45 +0530 Subject: Problem With E1 In-Reply-To: References: Message-ID: Hi Mathew Thanks for the reply. Problem solved morning after resetting the port from Service Provider End. As per SP RCA, mux por was hanged but really we are not conveinced. regards shivlu jain On Thu, Feb 26, 2009 at 2:34 PM, Shivlu Jain wrote: > Since morning I am facing a issue in which one of E1 is configured under > OSPF. OSPF neighborship is up but not able to send and receive the data. The > configuration is plain vanila. Why it is happening so; I donot know? > > -- > Thanks & Regards > shivlu jain > http://shivlu.blogspot.com/ > 09312010137 > > -- Thanks & Regards shivlu jain http://shivlu.blogspot.com/ 09312010137 From saku+nanog at ytti.fi Sat Feb 28 07:24:12 2009 From: saku+nanog at ytti.fi (Saku Ytti) Date: Sat, 28 Feb 2009 15:24:12 +0200 Subject: 23456 without AS4_PATH? Message-ID: <20090228132412.GA5615@mx.ytti.net> Anyone else seeing this: *> 91.196.186.0/24 62.237.167.25 0 3292 3549 15703 43531 23456 i http://www.ietf.org/rfc/rfc4893.txt 6. Transition An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System number. -- ++ytti From sthaug at nethelp.no Sat Feb 28 07:52:30 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 28 Feb 2009 14:52:30 +0100 (CET) Subject: 23456 without AS4_PATH? In-Reply-To: <20090228132412.GA5615@mx.ytti.net> References: <20090228132412.GA5615@mx.ytti.net> Message-ID: <20090228.145230.41657175.sthaug@nethelp.no> > Anyone else seeing this: > *> 91.196.186.0/24 62.237.167.25 0 3292 3549 15703 43531 23456 i > > http://www.ietf.org/rfc/rfc4893.txt > 6. Transition > An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System > number. Seeing it here too. On our 4-byte capable routers: 91.196.186.0/24 *[BGP/170] 1d 13:36:53, MED 0, localpref 105, from 193.75.0.204 AS path: 16150 15703 43531 AS_TRANS I AS path: 3356 6461 15703 43531 AS_TRANS I AS path: 1299 3549 15703 43531 AS_TRANS I And on our non 4-byte capable routers it is simply shown as 23456. This ASN should not be used to originate prefixes, agreed. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From lesnix at gmail.com Sat Feb 28 10:38:31 2009 From: lesnix at gmail.com (Egor Zimin) Date: Sat, 28 Feb 2009 19:38:31 +0300 Subject: 23456 without AS4_PATH? In-Reply-To: <20090228.145230.41657175.sthaug@nethelp.no> References: <20090228132412.GA5615@mx.ytti.net> <20090228.145230.41657175.sthaug@nethelp.no> Message-ID: <49A96887.1000900@gmail.com> Take a watch on this route: show route 195.128.231.0/24 detail [..omitted..] AS path: AS2 PA[5]: 39792 35320 AS_TRANS AS_TRANS 35748 AS path: AS4 PA[4]: 35320 3.21 AS_TRANS 35748 AS path: Merged[5]: 39792 35320 3.21 AS_TRANS 35748 I [...omitted...] AS4_PATH contain AS_TRANS, it's also RFC violation, isn't it ? sthaug at nethelp.no ?????: >> Anyone else seeing this: >> *> 91.196.186.0/24 62.237.167.25 0 3292 3549 15703 43531 23456 i >> >> http://www.ietf.org/rfc/rfc4893.txt >> 6. Transition >> An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System >> number. >> > > Seeing it here too. On our 4-byte capable routers: > > 91.196.186.0/24 *[BGP/170] 1d 13:36:53, MED 0, localpref 105, from 193.75.0.204 > AS path: 16150 15703 43531 AS_TRANS I > AS path: 3356 6461 15703 43531 AS_TRANS I > AS path: 1299 3549 15703 43531 AS_TRANS I > > And on our non 4-byte capable routers it is simply shown as 23456. This > ASN should not be used to originate prefixes, agreed. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > -- ? ?????????, ???? ????? From saku+nanog at ytti.fi Sat Feb 28 10:50:22 2009 From: saku+nanog at ytti.fi (Saku Ytti) Date: Sat, 28 Feb 2009 18:50:22 +0200 Subject: MAC address confusion Message-ID: <20090228165022.GA6429@mx.ytti.net> Whic one of these, is locally assigned unicast MAC address, when talking about output format CSCO uses? 4000.0000.0000 (Local IXPs choice) 0200.0000.0000 (My money is here) http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM A0-6A-00 (hex) Verilink Corporation In either case two of the lowest or highest bits of 1st octet seems to be happily used to assign addresses. What am I missing here? -- ++ytti From sthaug at nethelp.no Sat Feb 28 11:05:34 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 28 Feb 2009 18:05:34 +0100 (CET) Subject: 23456 without AS4_PATH? In-Reply-To: <49A96887.1000900@gmail.com> References: <20090228132412.GA5615@mx.ytti.net> <20090228.145230.41657175.sthaug@nethelp.no> <49A96887.1000900@gmail.com> Message-ID: <20090228.180534.71106261.sthaug@nethelp.no> > Take a watch on this route: > > show route 195.128.231.0/24 detail > [..omitted..] > AS path: AS2 PA[5]: 39792 35320 AS_TRANS AS_TRANS 35748 > AS path: AS4 PA[4]: 35320 3.21 AS_TRANS 35748 > AS path: Merged[5]: 39792 35320 3.21 AS_TRANS 35748 I > [...omitted...] > > AS4_PATH contain AS_TRANS, it's also RFC violation, isn't it ? Agreed, that sounds wrong. However, that's not how the route appears from here: show route 195.128.231.0/24 detail | match "AS path: [0-9AM]" AS path: 9002 13249 13249 13249 6886 196629 35748 I AS path: 9002 13249 13249 13249 6886 196629 35748 I AS path: AS2 PA[5]: 3356 13249 6886 AS_TRANS 35748 AS path: AS4 PA[4]: 13249 6886 196629 35748 AS path: Merged[5]: 3356 13249 6886 196629 35748 I AS path: AS2 PA[6]: 1299 3356 13249 6886 AS_TRANS 35748 AS path: AS4 PA[4]: 13249 6886 196629 35748 AS path: Merged[6]: 1299 3356 13249 6886 196629 35748 I So in our case the AS4 path seems normal. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From saku+nanog at ytti.fi Sat Feb 28 11:15:29 2009 From: saku+nanog at ytti.fi (Saku Ytti) Date: Sat, 28 Feb 2009 19:15:29 +0200 Subject: 23456 without AS4_PATH? In-Reply-To: <20090228.180534.71106261.sthaug@nethelp.no> References: <20090228132412.GA5615@mx.ytti.net> <20090228.145230.41657175.sthaug@nethelp.no> <49A96887.1000900@gmail.com> <20090228.180534.71106261.sthaug@nethelp.no> Message-ID: <20090228171529.GB6429@mx.ytti.net> On (2009-02-28 18:05 +0100), sthaug at nethelp.no wrote: > > show route 195.128.231.0/24 detail > > [..omitted..] > > AS path: AS2 PA[5]: 39792 35320 AS_TRANS AS_TRANS 35748 > > AS path: AS4 PA[4]: 35320 3.21 AS_TRANS 35748 > > AS path: Merged[5]: 39792 35320 3.21 AS_TRANS 35748 I > > [...omitted...] > > Agreed, that sounds wrong. However, that's not how the route appears > from here: > > show route 195.128.231.0/24 detail | match "AS path: [0-9AM]" > AS path: AS2 PA[5]: 3356 13249 6886 AS_TRANS 35748 > AS path: AS4 PA[4]: 13249 6886 196629 35748 > AS path: Merged[5]: 3356 13249 6886 196629 35748 I > AS path: AS2 PA[6]: 1299 3356 13249 6886 AS_TRANS 35748 > AS path: AS4 PA[4]: 13249 6886 196629 35748 > AS path: Merged[6]: 1299 3356 13249 6886 196629 35748 I > > So in our case the AS4 path seems normal. Looks OK in cisco as-dot format too, so unlike first example, I think this may be local problem. gw.ip.fi#show ip bgp 195.128.231.0/24 BGP routing table entry for 195.128.231.0/24, version 29 Paths: (1 available, best #1, table Default-IP-Routing-Table) Multipath: eBGP Not advertised to any peer 3292 3356 13249 6886 3.21 35748, (received & used) 62.237.167.25 from 62.237.167.25 (62.236.0.5) Origin IGP, localpref 100, valid, external, best Community: 3292:1101 3292:1901 gw.ip.fi# -- ++ytti From jdfalk-lists at cybernothing.org Thu Feb 26 18:57:03 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Thu, 26 Feb 2009 17:57:03 -0700 Subject: Peering Wars of 1998 In-Reply-To: <1235585773.49a58aedc1cce@mymail.yorku.ca> References: <1235585773.49a58aedc1cce@mymail.yorku.ca> Message-ID: <49A73A5F.3070002@cybernothing.org> nancyp at yorku.ca wrote: > I'm rsrching the Peering Wars of 1998...anyone able to provide info wd be > greatly appreciated. MAE-East was knee-deep in blood. I still have nightmares. -- J.D. Falk Return Path Inc http://www.returnpath.net/ From gbonthenet at gmail.com Sat Feb 28 11:22:33 2009 From: gbonthenet at gmail.com (Grzegorz Banasiak) Date: Sat, 28 Feb 2009 18:22:33 +0100 Subject: MAC address confusion In-Reply-To: <20090228165022.GA6429@mx.ytti.net> References: <20090228165022.GA6429@mx.ytti.net> Message-ID: <98a8f3c60902280922q4b0db546ta9bcf6712553f0e9@mail.gmail.com> > Whic one of these, is locally assigned unicast MAC address, when talking about > output format CSCO uses? > > 4000.0000.0000 (Local IXPs choice) > 0200.0000.0000 (My money is here) the second one. most significant byte is on the left, but within the byte, most significant bits are on the right. so U/L bit is the second one counting from the left. > http://standards.ieee.org/regauth/oui/oui.txt > 02-07-01 ? (hex) ? ? ? ? ? ? ? ?RACAL-DATACOM good point, dunno. From steve at ibctech.ca Sat Feb 28 14:30:27 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sat, 28 Feb 2009 15:30:27 -0500 Subject: ISP network re-design feedback requested Message-ID: <49A99EE3.3050801@ibctech.ca> Hi everyone, Hopefully my question is operational 'enough' to be asked here, as I don't know of any other place to ask... Still trying to redesign (as-I-go) our ISP network, I've realized that we are not large enough to deploy a full three layer approach (core, dist, acc), so I'm trying to consolidate, with the ability to scale if necessary. I also want full network reachability if I need to take any one router off-line for upgrade or replacement purposes. Given the following diagram (forgive me, it was drafted rather quickly with Visio, and just dumped onto a web box), I'm hoping for advice on whether I'm leaning the right way. http://ibctech.ca/p-ce.html What I want: - ability to take a router off-line for upgrade, and not be concerned about reachability issues if the lab-tested procedure fails miserably on production gear - a relatively easy way to keep traffic control measures at the access/edge (ACLs, uRPF, RTBH etc) - the 'core' free of interface ACLs (if possible), only running filtering ingress to the process-switch environment - the ability to scale without having to have a full mesh with all PE routers What I have: - numerous CPE routers connected to a CE switch that multi-homes into two different routers at two different locations in our access layer - an access layer that has no routers capable of a full BGP table (well, v4 that is) - a core layer that can handle full tables - a network access layer on the north side of the diagram that you can't see, with the same type of setup, but with full v4 routing tables being announced in - the access layer provides def-orig to CPE routers - the PE protects the CE from becoming transit What I am thinking - use the core routers as route-reflectors to the PE access routers, including a def-orig where it applies (to remain scalable, until PE can be replaced to hold full routes) - the PE routers send def-orig on to the CE sites - stop thinking about every network like it is an 'enterprise' network - look at most of my ISP environment as 'access clients', instead of always seeing my ISP as everything in my buildings. See the ISP as a 'network provider', and then realize the rest are just access 'clients': -- the 'hosting provider' -- the 'collocation provider' -- the 'Internet provider' -- the 'email provider' -- ect There is much, much more, but feedback on the above setup will get me going on the proper path... Steve From jako.andras at eik.bme.hu Sat Feb 28 15:38:14 2009 From: jako.andras at eik.bme.hu (JAKO Andras) Date: Sat, 28 Feb 2009 22:38:14 +0100 (CET) Subject: MAC address confusion In-Reply-To: <20090228165022.GA6429@mx.ytti.net> References: <20090228165022.GA6429@mx.ytti.net> Message-ID: > http://standards.ieee.org/regauth/oui/oui.txt > 02-07-01 (hex) RACAL-DATACOM > A0-6A-00 (hex) Verilink Corporation > > In either case two of the lowest or highest bits of 1st octet seems to be > happily used to assign addresses. What am I missing here? After enabling DECnet routing, the interface MAC address turns to something like this: GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is aa00.0400.0a04 (bia 000b.bffd.fc1a) And you'll find AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION in the list. I don't know what 02-07-01 is, but I guess that could be something similar: The OUI belongs to a company, but they don't use the addresses to burn them into interface cards. Andras From steve at ibctech.ca Sat Feb 28 16:02:19 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sat, 28 Feb 2009 17:02:19 -0500 Subject: DPI or Flow Management In-Reply-To: References: <49A99EE3.3050801@ibctech.ca> Message-ID: <49A9B46B.8030305@ibctech.ca> Francois Menard wrote: > The Coalition of Internet Service Providers has filed a substantial > contribution at the CRTC stating: > > 1) The CRTC should forbid DPI, as it cannot be proven to be 98.5% > effective at trapping P2P, such as to guarantee congestion relief > > 2) The CRTC should allow for other forms of traffic management by ISPs, > such as Flow Management > > http://www.crtc.gc.ca/public/partvii/2008/8646/c12_200815400/1029835.zip > > This is part of the public record at the following address: > > http://www.crtc.gc.ca/PartVII/eng/2008/8646/c12_200815400.htm > > The world will see Canada taking head-on the issue of addressing the > legitimacy of DEEP PACKET INSPECTION as a mean of properly managing an > incumbent's network behind the unbundling/peering interface. > > NANOG cannot pretend that this debate does not take place and remain > silent on this. Francios; Are you responding directly to my post via an automated filter, or am I the only one seeing the hijacking of this thread? Either way, great! I thought that I'd state that I forgot to mention in my original post that I was considering running HSRP (vrrp) on my core routers, for the access-layer clients who are not multi-homed. Given my setup, does RFC3768 at the 'core' make sense? Steve From saku+nanog at ytti.fi Sat Feb 28 16:40:00 2009 From: saku+nanog at ytti.fi (Saku Ytti) Date: Sun, 1 Mar 2009 00:40:00 +0200 Subject: MAC address confusion In-Reply-To: References: <20090228165022.GA6429@mx.ytti.net> Message-ID: <20090228224000.GA9473@mx.ytti.net> On (2009-02-28 22:38 +0100), JAKO Andras wrote: Hey, > > http://standards.ieee.org/regauth/oui/oui.txt > > 02-07-01 (hex) RACAL-DATACOM > > After enabling DECnet routing, the interface MAC address turns to > something like this: > Hardware is BCM1250 Internal MAC, address is aa00.0400.0a04 (bia 000b.bffd.fc1a) > AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION > in the list. I don't know what 02-07-01 is, but I guess that could be > something similar: The OUI belongs to a company, but they don't use the > addresses to burn them into interface cards. I guess you shouldn't be able to assign 02 (or AA) to a company for ethernet number, much in the same way you shouldn't be able to assign RFC1918. However you are right, it seems that these are unexplained exceptions to rules: http://www.iana.org/assignments/ethernet-numbers 'some of the known addresses do not follow the scheme (e.g., AA0003; 02xxxx)' Would be interesting to see what are the historical reasons.Perhaps they simply predate the scheme or some might not even co-exist in ethernet network to begin with, in which case they might be better documented elsewhere. In any case, to avoid collision with history, better start with 06 which seems cruft free, instead of 02, when choosing local MAC address prefix. As a side note, the 40 prefix used as local MAC in IXP here, seems to be just mistake in assuming ethernet follows tokenring in numbering scheme. -- ++ytti From deric.kwok2000 at gmail.com Sat Feb 28 20:05:37 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sat, 28 Feb 2009 21:05:37 -0500 Subject: Can I know how this network works out? Message-ID: <40d8a95a0902281805r4faafe09se9d42e43b62a0212@mail.gmail.com> Hi all main router- 3 static routes ip route 192.168.0.0/24 10.0.0.1 (routerA) ---- ip route 192.168.1.0/24 10.0.0.2 (routerB) ----same switch ---telecom company---client request ip route 192.168.2.0/24 10.0.0.3 (routerC) ---- Diagram ======= ---routerA--- main router ---switch ---routerB--- switch ---telecom company ---routerC--- dyname ip clients ip 192.168.0.0/24 and 192.168.1.0/24 static ip clients ip 192.168.2.0/24 This setting is fine when any dynamic ip clients sent from telcom company. But When telecom company sent request from static ip client (any ip in 192.168.8.0/22) but this client is sent to in routerA, how this work out? I really don't want to have 192.168.8.0 in routerC to routerB then routerA in loop as there will have big admin work if there is more than 3 routers and have increase new static ip client for the future Thank you for your help From deric.kwok2000 at gmail.com Sat Feb 28 20:07:50 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sat, 28 Feb 2009 21:07:50 -0500 Subject: Can I know how this network works (resend)? Message-ID: <40d8a95a0902281807t6843688cw8031f65a1cc3655@mail.gmail.com> Hi all main router- 3 static routes ip route 192.168.0.0/24 10.0.0.1 (routerA) ---- ip route 192.168.1.0/24 10.0.0.2 (routerB) ----same switch ---telecom company---client request ip route 192.168.2.0/24 10.0.0.3 (routerC) ---- Diagram ======= ---routerA--- main router ---switch ---routerB--- switch ---telecom company ---routerC--- dyname ip clients ip 192.168.0.0/24 and 192.168.1.0/24 static ip clients ip 192.168.2.0/24 This setting is fine when any dynamic ip clients sent from telcom company. But When telecom company sent request from static ip client (any ip in 192.168.2.0/24) but this client is sent to in routerA, how this work out? I really don't want to have 192.168.2.0 in routerC to routerB then routerA in loop as there will have big admin work if there is more than 3 routers and have increase new static ip client for the future Thank you for your help From damin at nacs.net Sat Feb 28 23:15:34 2009 From: damin at nacs.net (Gregory Boehnlein) Date: Sun, 1 Mar 2009 00:15:34 -0500 Subject: Clueful BGP Engineers Message-ID: <070701c99a2c$c01240b0$4036c210$@net> Can someone with a clue from the following two carriers please contact me off list? XO - ASN 2828 Level 3 - ASN 3356 I am currently experiencing a UDP/DNS DOS originating from 165.194.27.159 in Aisia. We have attempted to blackhole the subnet using BGP communities, but the requests are being filtered out at the X/O and L3 interfaces. From francois at menards.ca Sat Feb 28 15:51:19 2009 From: francois at menards.ca (Francois Menard) Date: Sat, 28 Feb 2009 16:51:19 -0500 Subject: DPI or Flow Management In-Reply-To: <49A99EE3.3050801@ibctech.ca> References: <49A99EE3.3050801@ibctech.ca> Message-ID: The Coalition of Internet Service Providers has filed a substantial contribution at the CRTC stating: 1) The CRTC should forbid DPI, as it cannot be proven to be 98.5% effective at trapping P2P, such as to guarantee congestion relief 2) The CRTC should allow for other forms of traffic management by ISPs, such as Flow Management http://www.crtc.gc.ca/public/partvii/2008/8646/c12_200815400/1029835.zip This is part of the public record at the following address: http://www.crtc.gc.ca/PartVII/eng/2008/8646/c12_200815400.htm The world will see Canada taking head-on the issue of addressing the legitimacy of DEEP PACKET INSPECTION as a mean of properly managing an incumbent's network behind the unbundling/peering interface. NANOG cannot pretend that this debate does not take place and remain silent on this. Best regards, F. -- Fran?ois D. M?nard francois at menards.ca