We don't need the adminstrative headache of ICANN/ARIN/RIRs on this. Someone could just do it with a private ASN and advertise the route with an arbitrarily null routed next-hop. That doesn't solve the problem of bad filters on firewalls. The problem is lots of books/webpages/templates/etc. say filter bogons. People not smart enough to understand the responsibilities of doing so implement it and forget it. Instead of trying to beat up on the large numbers of people who lack sufficient clue, why isn't the pressure turned to the authors that are irresponsibly and blindly recommending the wide spread use of these filters? I would think we would have more success targeting the people authoring this stuff. There are at most hundreds of authors. There is at least thousands of twits... Funny the media gets all excited about BGP security and dDos attacks against a root nameserver yet no one ever seems to mention the real scalability issues like that we can't allocate large parts of the net because many network operators aren't bright enough to update filters. Frank -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Monday, March 10, 2003 8:16 PM To: nanog@merit.edu Subject: Re: 69/8...this sucks OK... I'm late to this discussion (been mostly ignoring it due to volume in other places), but, Sean's 911->855 mail makes me wonder... It seems to me that it would be relatively simple to solve this problem by doing the following: 1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE. 2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions: A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to <RIR>-BOGON. B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP. C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers. 3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers. Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. Owen
On Mon, 10 Mar 2003, Frank Scalzo wrote:
We don't need the adminstrative headache of ICANN/ARIN/RIRs on this. Someone could just do it with a private ASN and advertise the route with an arbitrarily null routed next-hop.
That's a non-solution that will never happen. How many networks are going to trust joe somebody to inject null routes into their backbone? Will UUNet/Sprint/C&W/Level3/etc. trust me or Rob to tell them what's a bogon and what's not? I really doubt it. They might have an easier time trusting their local RIR, but I wouldn't be surprised if they didn't. I realize this sort of thing worked early on with the RBL, but that was for a different purpose. For those who took the RBL via BGP, I suspect the benefit of blocking spammers from their networks outweighed the risk of RBL abuse and people trusted Vixie to be objective and honest.
That doesn't solve the problem of bad filters on firewalls.
Several people pointed that out earlier. Botched / outdated firewall configs may be a bigger problem than BGP filters. For a glimpse at why, see http://groups.google.com/groups?q=69.0.0.0%2F8&ie=UTF-8&oe=UTF-8&hl=en&btnG=Google+Search
The problem is lots of books/webpages/templates/etc. say filter bogons. People not smart enough to understand the responsibilities of doing so implement it and forget it. Instead of trying to beat up on the large
Worse is that there are pages and pages full of links to usenet posts with these outdated bogon filters. Books and web pages can be updated. The usenet archive isn't going away and won't be revised. People who don't know any better are going to continue to misconfigure bogon filters indefinitely unless something is done to periodically whack some sense into them.
Funny the media gets all excited about BGP security and dDos attacks against a root nameserver yet no one ever seems to mention the real scalability issues like that we can't allocate large parts of the net because many network operators aren't bright enough to update filters.
I know some writers watch nanog for potential stories. Wake up guys, this should be one...if not for the news value "ARIN gives out unusable IPs, future of the Net in question", then at least for the public service value of getting the word out that bogon filters need to be maintained and kept up to date or they do more harm than good. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
From: jlewis Sent: Monday, March 10, 2003 9:18 PM
I know some writers watch nanog for potential stories. Wake up guys, this should be one...if not for the news value "ARIN gives out unusable IPs, future of the Net in question", then at least for the public service value of getting the word out that bogon filters need to be maintained and kept up to date or they do more harm than good.
And, please in said story, try not to use the term bogon or at least define it. The term "bogon" gets many funny looks, even from people that have firewalls filtering them. :) -Jack
That's a non-solution that will never happen. How many networks are going to trust joe somebody to inject null routes into their backbone? Will UUNet/Sprint/C&W/Level3/etc. trust me or Rob to tell them what's a bogon and what's not? I really doubt it. They might have an easier time trusting their local RIR, but I wouldn't be surprised if they didn't.
Well... I am pretty sure Tier1 backbones are up-to-date on the bogon filters :-) As we've already discussed, it's really the smaller networks with outdated bogons or with admins who don't know what they are doing..
Several people pointed that out earlier. Botched / outdated firewall configs may be a bigger problem than BGP filters. For a glimpse at why, see http://groups.google.com/groups?q=69.0.0.0%2F8&ie=UTF-8&oe=UTF-8&hl=en&btnG=Google+Search
Yup..
I know some writers watch nanog for potential stories. Wake up guys, this should be one...if not for the news value "ARIN gives out unusable IPs, future of the Net in question", then at least for the public service value of getting the word out that bogon filters need to be maintained and kept up to date or they do more harm than good.
No kidding.. I think we are just going around the circle/preaching to the choir on the same topic here.. Is this like what... 3rd time we are discussing this whole 69/8 issue :-D? Really, someone needs to get out this 69/8 issue on the press.. Just a thought.. heh -hc
---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Monday, March 10, 2003, 7:44:43 PM, you wrote: H> Well... I am pretty sure Tier1 backbones are up-to-date on the bogon H> filters :-) H> As we've already discussed, it's really the smaller networks with outdated H> bogons or with admins who don't know what they are doing.. Bingo. No silly bgp feed will fix this problem. The problem is all of the small customer networks that have been setup where the admin at the time installed a slick firewall using what was then current information and then walked away. I only see three ways to deal with this issue: 1. Contact each customer net that we find that is filtering on outdated information. I'm sure only the operators that have been assigned 69/8 space will start doing this (and have), since we are in fact responding to customer complaints. This process should be complete in say, oh, ten years or so. That should give us enough time to track them all down. Oh while we are at that, we might want to contact every operator of websites that are displaying "sample" firewalls using ipchains, iptables or ipfw that show 69/8 as a bogon network. We'll need to get them to change those webpages to show correct information. I mean, why have that information out there so some other clueless admin can simply start a fresh problem for us. I figure a couple of years to fix this too. 2. Find a way to break all of those customers networks that filter 69/8 so that the response time to fix it is much less than the time to contact each and every operator. The only way to do that is to move something like the root servers into this space. Yes it's crazy but it's the only way to break smaller networks. But once joe sixpack wonders why he can't get to Yahoo this morning and calls his consultant, the problem would be resolved a lot faster than it will take us to track them down and do option 1. 3. Have us 69/8 address assignees simply live with the problem and stop complaining in forums such as this. We're the ones dealing with the end user complaints about lost connectivity to sites once we've renumbering a link into this range. This goes back to option number 1, we'll simply bite the bullet and live with the problem and fix them as we find them. I'll admit, I run a small network and was quite happy to receive my first ARIN assignment some months ago. I wasn't so happy to find out that once I renumbered our internal office workstations into this range I had complaints from other employees about sites they could not reach (starting with *.ca.gov). I haven't even put one customer net into this new range yet and I've already reacted to a couple of dozen problems that less than 20 employees have found. I'm honestly scared to death about renumbering all of my customers now. H> I think we are just going around the circle/preaching to the choir on the H> same topic here.. Is this like what... 3rd time we are discussing H> this whole 69/8 issue :-D? Really, someone needs to get out this 69/8 H> issue on the press.. Just a thought.. heh I had an email sent to me from a writer from circleid.com (Joe Baptista) back in late December regarding this issue when the problem first popped up on Nanog. As far as I can remember he was going to write up an article on this situation. I have no idea what became of that. Regards, Joe Boyce --- InterStar, Inc. - Shasta.com Internet Phone: +1 (530) 224-6866 x105 Email: jboyce@shasta.com
Look, there's no quick fix solution here. It's going to take real effort and real work. However, the _REASON_ all those pages reference sample bogon filters is because there isn't a global bogon filter that is dynamically updated available. If there was, and people were aware of it, they'd use it. (At least a significant percentage would). As such, is a BGP feed a panacea? No. Is it a step in the right direction? Yes. Will it solve the problem by itself? No. Will it improve the situation? Yes. Moving the root servers into that space may expidite solving the problem, but at a _VERY_ significant cost. Moving the GTLD servers might make a little more sense (at least then, you aren't requireing _EVERYONE_ to update their hint files), but I still don't think that's a good idea. Others have suggested that it needs to be available in LDAP. Some have suggested DNS. As far as I'm concerned, the same servers or some group of servers could easily be set up to publish the authoritative BOGON list via DNS, BGP, LDAP, HTTP(XML), FTP, and possibly other protocols. Getting bogged down in the protocol isn't helpful. Finding a way to make an authoritative global BOGON list (Note: BOGONS are the UNALLOCATED/UNASSIGNED/ RESERVED/INVALID _LARGE_ blocks, _NOT_ every little hole in the allocation space) that is dynamically updated _IS_ the most practical solution for the long haul. Renumbering multiple global resources every time an RIR starts issuing from a new /8 isn't feasible. Publishing the data over the net is. Owen --On Tuesday, March 11, 2003 10:06 AM -0800 Joe Boyce <jboyce@shasta.com> wrote:
Monday, March 10, 2003, 7:44:43 PM, you wrote:
H> Well... I am pretty sure Tier1 backbones are up-to-date on the bogon H> filters :-) H> As we've already discussed, it's really the smaller networks with outdated H> bogons or with admins who don't know what they are doing..
Bingo. No silly bgp feed will fix this problem. The problem is all of the small customer networks that have been setup where the admin at the time installed a slick firewall using what was then current information and then walked away.
I only see three ways to deal with this issue:
1. Contact each customer net that we find that is filtering on outdated information. I'm sure only the operators that have been assigned 69/8 space will start doing this (and have), since we are in fact responding to customer complaints. This process should be complete in say, oh, ten years or so. That should give us enough time to track them all down.
Oh while we are at that, we might want to contact every operator of websites that are displaying "sample" firewalls using ipchains, iptables or ipfw that show 69/8 as a bogon network. We'll need to get them to change those webpages to show correct information. I mean, why have that information out there so some other clueless admin can simply start a fresh problem for us. I figure a couple of years to fix this too.
2. Find a way to break all of those customers networks that filter 69/8 so that the response time to fix it is much less than the time to contact each and every operator. The only way to do that is to move something like the root servers into this space. Yes it's crazy but it's the only way to break smaller networks. But once joe sixpack wonders why he can't get to Yahoo this morning and calls his consultant, the problem would be resolved a lot faster than it will take us to track them down and do option 1.
3. Have us 69/8 address assignees simply live with the problem and stop complaining in forums such as this. We're the ones dealing with the end user complaints about lost connectivity to sites once we've renumbering a link into this range. This goes back to option number 1, we'll simply bite the bullet and live with the problem and fix them as we find them.
I'll admit, I run a small network and was quite happy to receive my first ARIN assignment some months ago. I wasn't so happy to find out that once I renumbered our internal office workstations into this range I had complaints from other employees about sites they could not reach (starting with *.ca.gov). I haven't even put one customer net into this new range yet and I've already reacted to a couple of dozen problems that less than 20 employees have found. I'm honestly scared to death about renumbering all of my customers now.
H> I think we are just going around the circle/preaching to the choir on the H> same topic here.. Is this like what... 3rd time we are discussing H> this whole 69/8 issue :-D? Really, someone needs to get out this 69/8 H> issue on the press.. Just a thought.. heh
I had an email sent to me from a writer from circleid.com (Joe Baptista) back in late December regarding this issue when the problem first popped up on Nanog. As far as I can remember he was going to write up an article on this situation. I have no idea what became of that.
Regards,
Joe Boyce --- InterStar, Inc. - Shasta.com Internet Phone: +1 (530) 224-6866 x105 Email: jboyce@shasta.com
On Tue, Mar 11, 2003 at 11:38:23AM -0800, Owen DeLong wrote:
As such, is a BGP feed a panacea? No. Is it a step in the right direction? Yes. Will it solve the problem by itself? No. Will it improve the
So, someone feel free to smack me if I'm mentioning something which has been discussed already (there isn't enough masochism in the world to make me read this entire thread), buttttt... How exactly is a BGP feed of bogons useful in any way shape form of fashion? It doesn't prevent people from announcing more specifics, it doesn't do anything about source address bogons, it can't be used to packet filter... How exactly would it do anything other than simply not having the route at all? If and when some vendor adds support for taking the routes from a bgp feed and using them in a packet filter, sign me up. Until then, I must be missing something. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On Tue, 11 Mar 2003, Richard A Steenbergen wrote:
On Tue, Mar 11, 2003 at 11:38:23AM -0800, Owen DeLong wrote:
As such, is a BGP feed a panacea? No. Is it a step in the right direction? Yes. Will it solve the problem by itself? No. Will it improve the
So, someone feel free to smack me if I'm mentioning something which has been discussed already (there isn't enough masochism in the world to make me read this entire thread), buttttt...
How exactly is a BGP feed of bogons useful in any way shape form of fashion? It doesn't prevent people from announcing more specifics, it doesn't do anything about source address bogons, it can't be used to packet filter... How exactly would it do anything other than simply not having the route at all?
I guess that emperor is a little naked after all :) Without applying hard-coded bogon filters to your peers (to prevent receiving longer prefixes in bogon space), it is essentially useless. http://www.cymru.com/Documents/secure-bgp-template.html lists a nice template. But then we're back right where we started, may as well just have a static ACL...unless you can't afford the ACL hit, in which case filtering announcements from your peers and routing everything bogon into a traffic sink would be a great solution. We're all filtering announcements from our peers anyway, right? :) Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
--On Tuesday, March 11, 2003 16:47 -0500 Randy Bush <randy@psg.com> wrote:
so let's see how much of a kludge we can make to show how clever we are.
How about if we all chip in to hire a bunch of out of work consultants to fly to the NOCs of the various backbones who are being boneheaded to educate them with a clue-by-four? Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com
To a degree the problem is ability to reach proper persons. I'd like to be able to enter as# or ip and immediatly get email for a tech who knows what to do. Radb is supposed to provide some of these functionalities, so does ip whois, so does dns whois. Usually one of these will get you what you need or if nothing else, youd'd look at AS traceroute and contact the upstream. Reality is we do have hierchical structure in ip & as assignments/allocations: IANA->RIR->LIR->ISP->END-USER but currect information exchange is only possible at one level (i.e RIR should know how to contact LIR, ISP should know how to contact END-USER). A lot smaller hierchy is with AS numbers - IANA->RIR->END-USER. I guess I forgot about all this in my proposal but I'll be sure to clarify that when new assignment is received ARIN should notify not only their IP subscriber members and end-users (ip assignments) customers but also all those listed as contacts for ASNs (removing duplicate emails gathered from all the sources, of course). Unfortunetly ASN contact information is one of the least "maintained" as far as ARIN data goes. And too bad... In my opinion fairly good way to solve the problem would be to make sure that ASN contact info is up to date for all RIRs and when new global assignments are made than IANA makes the announcement and RIRs pass it along to their AS contacts and as backup through longer ip path. I'm fairly certain if info on who to contact was up to date at RIRs, the reachibility of this would be well over 99% and number of blackholes for users of new ip block would be very small. On Tue, 11 Mar 2003, Alec H. Peterson wrote:
--On Tuesday, March 11, 2003 16:47 -0500 Randy Bush <randy@psg.com> wrote:
so let's see how much of a kludge we can make to show how clever we are.
How about if we all chip in to hire a bunch of out of work consultants to fly to the NOCs of the various backbones who are being boneheaded to educate them with a clue-by-four?
Alec
-- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com
On Tue, 11 Mar 2003 14:58:10 MST, "Alec H. Peterson" said:
How about if we all chip in to hire a bunch of out of work consultants to fly to the NOCs of the various backbones who are being boneheaded to educate them with a clue-by-four?
I suspect the problem isn't the backbones that have a NOC. The problem is small mom&pop ISPs and companies where the NOC and the senior secretary share a desk, and possibly a name.
The problem is small mom&pop ISPs and companies where the NOC and the senior secretary share a desk, and possibly a name.
maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained?
On Wed, 12 Mar 2003, Randy Bush wrote:
The problem is small mom&pop ISPs and companies where the NOC and the senior secretary share a desk, and possibly a name.
maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained?
Sure. If the NSPs would just filter the bogon routes, nobody else would have to bother. Why is it that they don't? Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
Andy Dills wrote:
On Wed, 12 Mar 2003, Randy Bush wrote:
maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained?
Sure. If the NSPs would just filter the bogon routes, nobody else would have to bother. Why is it that they don't?
Filter (public, private and transit) peers or customers...? Or themselves? I've had a few customers spontaneously (ahem) come up with remarkably "Rob Thomas" configs (if any noun can be verbed, can any name be adjectived?) -- I usually convince them to tone down the filters a bit. The funny ones are those who've signed up for a partial table or default. Then again, I suppose you can't be too careful. Peter E. Fry
On Wed, 12 Mar 2003, Peter E. Fry wrote:
Andy Dills wrote:
Sure. If the NSPs would just filter the bogon routes, nobody else would have to bother. Why is it that they don't?
Filter (public, private and transit) peers or customers...? Or themselves?
Yes. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Tue, 11 Mar 2003, Randy Bush wrote:
so let's see how much of a kludge we can make to show how clever we are.
Hey, I already came up with the slashdot idea. Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block. Like anything else, until end users complain, nothing happens. Charles
randy
Charles Sprickman wrote:
Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block.
The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. Set up a page (hopefully linked from www.google.com) that lists all of Google's present beta sites. On this page, inform the user that the beta sites are hosted on "newly allocated IP addresses" and that if the said user can't reach the beta sites, it most likely means that their ISP/Company is improperly filtering these newly valid IP addresses, Instruct these affected users to contact their IPS's support desk or their company's IS department and alert them that they need to update their IP filter set to avoid filtering newly released and valid IPs. Then also link to a site such as <http://www.cymru.com/Bogons/> which explains bogon filters, shows how to find the latest lists, and educates the filter-clueless on how to subscribe to appropriate announcement lists to become aware of updates/changes in what IPs can be safely filtered. Google could also explain that they are doing this to help the Internet community fix this problem, and perhaps explain why it is a problem. They would get tons of good press which would help advertise Google and their beta projects. Froogle is a very kewl site that gets better by the day (thanks guys, I use it all the time!), and I bet it also gets more traffic by the day. This would be a good way for Google to get free publicity for Froogle and other beta sites, and get big Internet community "good guy" points for helping fix the 69/8 bogon filter problem, without outright breaking the highly popular Google websearch site itself. Is there anyone from Google lurking here on nanog? jc (Googling on: google beta, I discovered that Google itself went beta in February of 1999, just 4 years ago. My, how time flies!)
On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote:
Charles Sprickman wrote:
Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block.
The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea:
Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably.
(Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to put random things in 69/8 space. These goals are mutually exclusive. You can't put important stuff on broken IPs, and you can't fix broken IPs by putting unimportant stuff on them. No one is going to move all of the root servers to try and fix a couple outdated filters, and no one who is still running outdated filters is going to notice it because they can't reach Google beta sites. These are not just bad ideas, they are STUPID ideas. What happened to the days when, before people posted to mailing lists, they thought "will this make me look like an idiot in front of engineers across the entire planet"? This is quickly not only becoming one of the most all-time useless threads ever, but it is continuing to repell the useful people who can no longer stand to read NANOG because of crap like this. Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 was opened up it destroyed a beautiful 64/3 filter on unallocated space, and yet somehow we all made it through just fine. The people who are stupid enough to filter IPs without a plan on keeping those filters up to date deserve their connectivity problems. Maybe next time they'll give consideration to whether they actually need unallocated bogon filters on every last linux server. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
And I'd like to add I agree. The problems were wide at first, they have definitely dropped off. Everyone important, is reachable now it seems. I can think of maybe one or two small islands who might still be unreachable but hey if I lived in the troopics I'd be outside with an umbrella drink too, not changing filters. Bottom line is that the only way to fix this problem is to move in to the space, use the space, and contact people when its broken. Nanog although perhaps not the best place for this, has helped in this goal for me at least 4 or 5 times and its fixed for everyone not just me. With all of us pounding away the problems clear quickly. ----- Original Message ----- From: "Richard A Steenbergen" <ras@e-gerbil.net> To: "JC Dill" <nanog@vo.cnchost.com> Cc: <nanog@merit.edu> Sent: Tuesday, March 11, 2003 5:17 PM Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote:
Charles Sprickman wrote:
Seriously though, somewhere there is a popular site that is non-profit
in
nature that would trade say a month of free access for the hassle of being put into a widely-blocked block.
The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea:
Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably.
(Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in)
JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to put random things in 69/8 space. These goals are mutually exclusive. You can't put important stuff on broken IPs, and you can't fix broken IPs by putting unimportant stuff on them. No one is going to move all of the root servers to try and fix a couple outdated filters, and no one who is still running outdated filters is going to notice it because they can't reach Google beta sites.
These are not just bad ideas, they are STUPID ideas. What happened to the days when, before people posted to mailing lists, they thought "will this make me look like an idiot in front of engineers across the entire planet"? This is quickly not only becoming one of the most all-time useless threads ever, but it is continuing to repell the useful people who can no longer stand to read NANOG because of crap like this.
Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 was opened up it destroyed a beautiful 64/3 filter on unallocated space, and yet somehow we all made it through just fine. The people who are stupid enough to filter IPs without a plan on keeping those filters up to date deserve their connectivity problems. Maybe next time they'll give consideration to whether they actually need unallocated bogon filters on every last linux server. :)
-- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Richard A Steenbergen wrote:
On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote:
Charles Sprickman wrote:
Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block.
The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea:
Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably.
(Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in)
Ahem. It's _MS._ Dill, thank you. Maybe next time you will stop and think "will this make me look like a sexist idiot in front of engineers across the entire planet"? before posting to a mailing list. (If the shoe fits, wear it.)
JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to put random things in 69/8 space. These goals are mutually exclusive. You can't put important stuff on broken IPs, and you can't fix broken IPs by putting unimportant stuff on them.
Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed.
no one who is still running outdated filters is going to notice it because they can't reach Google beta sites.
I'm suggesting that Google explain why they are doing this on a page linked off their homepage. If this is done, people ARE going to notice, and ARE going to find out why. When it is widely publicised, it WILL be noticed even more.
These are not just bad ideas, they are STUPID ideas.
Where is your bright suggestion?
Listen, I have space in 69/8, and it is NOT an epidemic.
So how are you solving your 69/8 filtering/connectivity problems?
Back when 64/8 was opened up it destroyed a beautiful 64/3 filter on unallocated space, and yet somehow we all made it through just fine. The people who are stupid enough to filter IPs without a plan on keeping those filters up to date deserve their connectivity problems.
OK, I'm confused. I thought that the connectivity problem was, by and large, endured by the 69/8 IP users, and not on the networks with out-of-date bogon filters. Please elaborate on how this problem is really a connectivity problem for the networks with the bad filters, and how they are experiencing and then fixing this problem. Because from all reports here, it's obvious to ME that these networks are totally unaware of the issue because it is NOT creating a problem for them! jc p.s. Please don't cc me on replies, or on replies to replies, etc. I get the list email just fine and I don't need more than one copy of any given email. Really.
On Tue, Mar 11, 2003 at 06:01:00PM -0800, JC Dill wrote:
Ahem. It's _MS._ Dill, thank you.
Woops, my apologies _MS._ Dill. The JC is ambiguous.
Maybe next time you will stop and think "will this make me look like a sexist idiot in front of engineers across the entire planet"? before posting to a mailing list. (If the shoe fits, wear it.)
Sexist? Now that's just absurd. I took a guess and lost, big deal. If anything, that proves my opinion of your idea has nothing to do with your gender. Get over it.
p.s. Please don't cc me on replies, or on replies to replies, etc. I get the list email just fine and I don't need more than one copy of any given email. Really.
I believe you'll find reply-all is commonly used, get over it. Really. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On 2003-03-11-21:01:00, JC Dill <nanog@vo.cnchost.com> wrote:
[...]
(Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in)
Ahem. It's _MS._ Dill, thank you.
Please post with a gender-specific name if you want to take offense when mis-identified.
Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed.
How do I configure my routers and web servers for that?
I'm suggesting that Google explain why they are doing this on a page linked off their homepage. If this is done, people ARE going to notice, and ARE going to find out why. When it is widely publicised, it WILL be noticed even more.
Last I checked, Google was a for-profit business, not a charity house. I'm not sure how doing something that will make them look dumb, and cost them in valuable ad revenue, etc is in their best interests. Perhaps you could fill me in here.
p.s. Please don't cc me on replies, or on replies to replies, etc.
We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary. If duplicate messages cluttering your inbox are causing you much grief, prehaps it's time to read up on message filtering using procmail, formail, and friends. Regards, -a
On Tue, 11 Mar 2003, Adam Rothschild wrote:
On 2003-03-11-21:01:00, JC Dill <nanog@vo.cnchost.com> wrote:
failure will lead to the broken networks being fixed and clue being distributed.
How do I configure my routers and web servers for that?
no ip clue-inhibit ip bgp redistribute-clue
Miss Rothschild wrote:
On 2003-03-11-21:01:00, JC Dill <nanog@vo.cnchost.com> wrote:
(Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in)
Ahem. It's _MS._ Dill, thank you.
Please post with a gender-specific name if you want to take offense when mis-identified.
It is offensive to many people (both male and female) when someone automatically assumes that an "unknown" person is male. Especially since: Females aged 2 and up accounted for 50.4 percent of U.S. Internet users in May, edging out their male counterparts, according to New York-based Internet research firms Media Metrix and Jupiter Communications [...] At Dulles-based America Online Inc., the nation's biggest online services company, 52 percent of its 23.2 million subscribers worldwide are women. [...] Some scholars believe the new-found gender parity is just another reflection of the social changes of the past few decades, when men and women found themselves on more equal footing. "That distinction has disappeared, and it is a huge revolution in society," says Michael Maccoby, an anthropologist and psychoanalyst. <http://www.washingtonpost.com/ac2/wp-dyn/A137-2000Aug9?language=printer> It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris?
Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed.
How do I configure my routers and web servers for that?
ObNanog: Assuming you don't work at Google, if you aren't blocking 69/8 then your network will not be harmed in any way by the implementation of this proposal. Thus you need to do nothing special at all. OTOH, if you are improperly blocking 69/8, obviously you need to fix that when you configure your "routers and web servers" (sic).
I'm suggesting that Google explain why they are doing this on a page linked off their homepage. If this is done, people ARE going to notice, and ARE going to find out why. When it is widely publicised, it WILL be noticed even more.
Last I checked, Google was a for-profit business, not a charity house. I'm not sure how doing something that will make them look dumb, and cost them in valuable ad revenue, etc is in their best interests. Perhaps you could fill me in here.
If you don't work at Google, then this is none of your concern.
p.s. Please don't cc me on replies, or on replies to replies, etc.
We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary.
I have no urgent need for your reply, I am happy to wait until I receive email from the list. I politely made my request very clear, both in my headers and in the body of my email. You responded by taking extra steps to do the exact opposite of what I politely requested. Then you have the gall to flame me for my polite request. This was very rude of you.
If duplicate messages cluttering your inbox are causing you much grief,
They are just an annoyance, as is being mistakenly referred to as a male. Since you seem to think that these annoyances must be accepted as part of participating on the net, be prepared to be referred to as Miss Rothschild by me, now and in the future. What goes around comes around, girlfriend. jc [1] JC Dill is my real name. It is the name on my passport and other official documents.
It is offensive to many people (both male and female) when someone automatically assumes that an "unknown" person is male.
though not offended, it does tell me a lot about the person making the assumption. and it ain't positive. but that nanog is yet another male dominated technical culture (yamdtc) should surprise no one here. on the other hand, the level of immature rudeness exhibited (remember when abha posted about the geekgirls list?) can be *extremely* embarrassing, and some folk can insist on making utter asses of themselves. but, sad to say, none of this should surprise women. not to say that women and men should not stand up against it when it occurs. we now return you to small operators trying to convince other small operators how they should run the route filters in their shops. imiho, if it is not automated by protocol, banana eaters will screw it up for sure. so, again imiho, this topic is about as likely to make progress as serious gender equity in my lifetime <sigh>. randy
On Wed, 12 Mar 2003, Randy Bush wrote:
we now return you to small operators trying to convince other small operators how they should run the route filters in their shops. imiho, if it is not automated by protocol, banana eaters will screw it up for sure. so, again imiho, this topic is about as likely to make progress as serious gender equity in my lifetime <sigh>.
Randy, you've run a huge network. I have not had that opportunity, and I don't have "banana eaters" working for me (and I'm not sure what that phrase means exactly, but I'll assume it isn't racial). I must not understand something. How would the banana eaters screw up applying the same prefix-list outbound to all neighbors? Seems like an easy protocol to follow. I could understand the problems with applying inbound filters (unique huge filter for each neighbor), but if you're willing to localize bogon routes to the border router, without redistributing them, you get the job done. So filter announcements to every neighbor. That way, only the places with lots of administration (places that will know to update filters) will need to worry about updating filters. Then, bogon traffic only flows as far as the default route takes it, without the ACL hit. I'm not telling people that this is the cure, that this is how they should run their network. I'm asking for the big operators to tell me what's wrong with this idea. In theory, it should work, but I don't have the pragmatism that comes with running a nationwide network staffed by banana eaters. If nothing else, it seems like a worthy stopgap until the next iteration of BGP comes along to really address the trust issues. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
I must not understand something. How would the banana eaters screw up applying the same prefix-list outbound to all neighbors?
Humans tend to be imprecise. Scripted actions tend to be very precise. Implementing a process by which humans manually enter configurations is prone to error and more difficult to check. Implementing a scripted, automated process that enters configurations from a text file or database is more likely to be precise and thorough. In an anecdotal case, a human going router by router to update ACL 101 is more prone to accidently skip a line in his vi list or his web list, that guides his manual logins. Another simple error that a human could make is to accidently mistakenly change cut/paste buffer. An automated computer program or script is much more likely to be precise. Notice I use the word "precise" above and not accurate. Humans may be more accurate in that they are intelligent enough to fix one-off problems. But when managing many many objects many network folks would value reliable precision over occasional accuracy. One can always manually find inaccuracies, and put algorithms for exception reports, of 'one-off situations' into a precise script. This is why many folks rightfully argue that change management should be scripted, and not entrusted to less experienced manual humans. There's a balance, and you can't have the Olivaws running amuch with their unintelligent precision. The automated processes must be well thought and audited by an intelligent, accurate human. -a
On Wed, Mar 12, 2003 at 10:22:53PM -0500, Andy Dills wrote:
Randy, you've run a huge network. I have not had that opportunity, and I don't have "banana eaters" working for me (and I'm not sure what that phrase means exactly, but I'll assume it isn't racial).
I believe he is referring to the class of people who do stuff without understand why that we sometimes call monkeys... Leave it to Randy to defend and offend in the same e-mail, but fortunately I don't think anyone is going to complain about species-ism. :)
I must not understand something. How would the banana eaters screw up applying the same prefix-list outbound to all neighbors? Seems like an easy protocol to follow. I could understand the problems with applying inbound filters (unique huge filter for each neighbor), but if you're willing to localize bogon routes to the border router, without redistributing them, you get the job done. So filter announcements to every neighbor.
Simple, apply a bogon list and then fail to update it. If you are not ready willing and able to keep your lists updated, you probably shouldn't have applied them in the first place. I routinely see people doing absurd things like applying ipfw bogon filters on individual servers to "protect against DoS" that end up costing them way more in performance than they could possibly gain from filtering the bogons. Let's keep it real folks, these filters aren't needed everywhere. Personally I don't think it's "too" hard to setup some scripts scripts which can apply updated bogon and other important prefix-list updates globally. Rancid and about 15 lines of shell script should do you just fine. If you're lucky enough to have Juniper's, you can use the same prefix-list to filter both routes and packets. That said, I'm sure we would all LOVE a protocol which can dynamically supply routes for various route and packet filter operations throughout a large network. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
From: "Richard A Steenbergen"
Simple, apply a bogon list and then fail to update it. If you are not ready willing and able to keep your lists updated, you probably shouldn't have applied them in the first place. I routinely see people doing absurd things like applying ipfw bogon filters on individual servers to "protect against DoS" that end up costing them way more in performance than they could possibly gain from filtering the bogons. Let's keep it real folks, these filters aren't needed everywhere.
You think that's bad? Try this one. Contacted network to inform them that they had an access list on a router rejecting 69/8 and that 69/8 was recently handed out, blah blah blah. Get a call back saying that they found the route for 69 and removed it. Could I please try it again. To humor said person, I tried it again and got what I expected (A). My question is, if he's running an acl with a bogon list, why does he have a route (presumably static since it was removed) for 69/8? I'm tempted to start mailing out bananas. -Jack
You think that's bad? Try this one. Contacted network to inform them that they had an access list on a router rejecting 69/8 and that 69/8 was recently handed out, blah blah blah. Get a call back saying that they found the route for 69 and removed it. Could I please try it again. To humor said person, I tried it again and got what I expected (A). My question is, if he's running an acl with a bogon list, why does he have a route (presumably static since it was removed) for 69/8? I'm tempted to start mailing out bananas.
Check out http://www.cymru.com/Documents/secure-ios-template.html All of the various Bogons, including unassigned ranges, are represented with a route to null0. Mike
From: "Michael K. Smith"
Check out http://www.cymru.com/Documents/secure-ios-template.html
All of the various Bogons, including unassigned ranges, are represented
with
a route to null0.
Nice, although it doesn't explain the purpose of having the routes if you have an acl. To keep viruses from attempting to contact bogons? To stop your internal network from surfing the bogon web which can't reply back anyways? -Jack
On 12 Mar 2003 at 22:59, Jack Bates wrote:
Nice, although it doesn't explain the purpose of having the routes if you have an acl. To keep viruses from attempting to contact bogons? To stop your internal network from surfing the bogon web which can't reply back anyways?
It's a generic config -- note the "! Default route to the Internet [...]". Saves you some microbucks on that burstable Internet link, or maybe some of that micro-upstream-bandwidth on your ADSL when you get those spoofy pings. Hey -- you asked. I recommend it myself, on a smaller scale. (Sigh.) Your ideas are nice, but I'd have to rant all over this list to keep y'all from filtering my compelling bogon content. Peter E. Fry
On Wed, 12 Mar 2003, Jack Bates wrote:
From: "Michael K. Smith"
Check out http://www.cymru.com/Documents/secure-ios-template.html
All of the various Bogons, including unassigned ranges, are represented
with
a route to null0.
Nice, although it doesn't explain the purpose of having the routes if you have an acl. To keep viruses from attempting to contact bogons? To stop your internal network from surfing the bogon web which can't reply back anyways?
I didn't look at the template recently, but I recall something like: route instead of acl... so allow the traffic in and kill it on the way out. Alternately, with uRPF inbound it'll kill the traffic on the inbound since the destination for the packet (source in this case) is invalid.
Hi, Jack. ] Nice, although it doesn't explain the purpose of having the routes if you ] have an acl. To keep viruses from attempting to contact bogons? To stop your ] internal network from surfing the bogon web which can't reply back anyways? Basically, yes. I'm not worried about folks web surfing 10/8. :) There are things that go wrong, however, and I firmly believe in filtering both on ingress and egress (at the edge, to be clear). This is an extra bit of protection in case something bad happens, be it malware, fat fingers, etc. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
If you are not ready willing and able to keep your lists updated, you probably shouldn't have applied them in the first place.
a poor but wise person who had the onerous task of managing me in the late '60s said i had a talent for stating the obvious. it was meant as a compliment. randy
RAS> Date: Wed, 12 Mar 2003 22:47:21 -0500 RAS> From: Richard A Steenbergen RAS> That said, I'm sure we would all LOVE a protocol which can RAS> dynamically supply routes for various route and packet RAS> filter operations throughout a large network. If it weren't so dangerous, I'd suggest a "hyperweight" that overrides prefix length. Hear bogons from route server, set hyperweight high enough to override longer prefixes, and set the next hop to null interface. Things like this return us to separation of routing and forwarding: Should BGP munching and fancy route-fu be performed on a flexible, customizable *ix box, then fed to the actual forwarding machines? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Thu, 2003-03-13 at 04:47, Richard A Steenbergen wrote:
Personally I don't think it's "too" hard to setup some scripts scripts which can apply updated bogon and other important prefix-list updates globally. Rancid and about 15 lines of shell script should do you just fine. If you're lucky enough to have Juniper's, you can use the same prefix-list to filter both routes and packets.
Sorry to break in here with something as inappropriate as a technical comment but... Actually, you can't. But it is a common error people do on J boxes. If you use prefix-lists in your routing policy on the Js, they will only match the exact prefix-length specified, not longer prefixes from within it. If you want to match prefixes of any given length within say, a /8 (a typical entry in a bogon list), you have to use route-lists (route-filter statements), which can not be used in your packet filters (firewall config)... /leg
How would the banana eaters screw up applying the same prefix-list outbound to all neighbors?
by spending [some small part of] their time configuring routers as opposed to building tools to configure routers demonstratably correctly. when fingers 'touch' routers, bad things are bound to happen sooner or later. randy
On Wed, 12 Mar 2003, Randy Bush wrote:
How would the banana eaters screw up applying the same prefix-list outbound to all neighbors?
by spending [some small part of] their time configuring routers as opposed to building tools to configure routers demonstratably correctly.
when fingers 'touch' routers, bad things are bound to happen sooner or later.
I wouldn't disagree with you. It would seem that the more complex the network, the more automation and abstraction is required. Few would disagree with that. But then, if configuration of routers is automated, it would seem even easier to implement the route filtering. Verio has a history of being a prefix length nazi, but were they that way about route validity? Plenty of networks are stringent on what they accept from their customers, but are they as stringent with the routes they send? As long as people continue to have unfiltered peers (save for maximum-prefix), this would seem a reasonable measure of implementing the principle of being liberal with what you accept and conservative with what you send. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
Verio has a history of being a prefix length nazi, but were they that way about route validity?
i can only speak in the quite past tense. but yes. due to limitations of routers (ever try a really long acl on a cisco?) and some large peers not registering, verio could not filter large peers inbound.
Plenty of networks are stringent on what they accept from their customers, but are they as stringent with the routes they send?
if stringent == careful, they <bleep>ing well should be. this does not imply that their inbound business policy must be the same as their outbound, e.g. customers pay to have their routes announced no matter how silly. one's peers are not obliged to listen to them. randy
On Thu, Mar 13, 2003 at 12:21:10AM -0500, Andy Dills wrote:
But then, if configuration of routers is automated, it would seem even easier to implement the route filtering. Verio has a history of being a prefix length nazi, but were they that way about route validity? Plenty of networks are stringent on what they accept from their customers, but are they as stringent with the routes they send?
Route filtering and route validation are not necessarily the same things. AFAIK, there are no scalable mechanisms for route validation deployed today. As far as route filtering is concerned, Verio currently does prefix filter many of its public peers based on IRR registrations. However, our experience to date indicates that filtering peer networks via IRR information is not a scalable solution. Some of the non-exhaustive reasons for this are: o platform performance limitations with large prefix lists (some do a better job, but they all fall short of acceptable, let alone ideal) o GIGO, aka IRR data sanity o lack of route registrations for large peer networks Due to this, our direction is to move away from IRR based peer route filtering. -dorian
Thus spake "Dorian Kim" <dorian@blackrose.org>
Route filtering and route validation are not necessarily the same things. AFAIK, there are no scalable mechanisms for route validation deployed today.
A few years ago, I saw an I-D that proposed BGP route repudiation, e.g. you can't be sure a route is _good_, but you can be sure some routes are _bad_. This seems to solve our bogon problem if not the general case. In the meantime, we're still waiting for uRPF implementations that are useful in multihomed networks -- a must-have for widespread deployment. 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
On Wed, 12 Mar 2003, Randy Bush wrote:
How would the banana eaters screw up applying the same prefix-list outbound to all neighbors?
by spending [some small part of] their time configuring routers as opposed to building tools to configure routers demonstratably correctly.
when fingers 'touch' routers, bad things are bound to happen sooner or later.
Too bad at least several of our collective favorite vendors don't seem to agree, as they don't provide very reasonable methods to update the router configuration in an automated way. Sure, there are ways to make it work but they are too complex to be useful in small networks. Iljitsch (Still waiting for vendors to support automatic filter retrieval from an LDAP server by routers...)
On Thu, 13 Mar 2003, Iljitsch van Beijnum wrote:
Too bad at least several of our collective favorite vendors don't seem to agree, as they don't provide very reasonable methods to update the router configuration in an automated way. Sure, there are ways to make it work but they are too complex to be useful in small networks.
Iljitsch
(Still waiting for vendors to support automatic filter retrieval from an LDAP server by routers...)
Will you be attending the Network Configuration BOF on Monday at the IETF in San Francisco? Configuration of networking devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed or used vendor specific mechanisms to transfer configuration data to and from a device and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. Utilities built upon tools such as Perl and "Expect" are used to control devices via the CLI, but are prone to failure due to the instability and lack of uniformity inherent in a CLI. Investigations conducted within the IETF, at OPS area meetings and in an IAB workshop over the past two years have identified operator requirements for a standard configuration protocol that: - Provides a clear separation of configuration data from non-configuration data - Is extensible enough that vendors will provide access to all configuration data on the box from a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a data representation that is easily manipulated using non-specialized text manipulation tools (perl, awk, etc.) - Supports integration with existing user authentication methods, such as RADIUS - Can be easily integrated with existing configuration database systems, such as RANCID - Provides support for multi-box configuration transactions (with locking and rollback capability) This BOF will focus on discussion of a protocol for the management of network device configuration that meets many of the operator requirements identified through these efforts. A draft that may serve as a useful starting point for this work can be found at http://www.ietf.org/internet-drafts/draft-enns-xmlconf-spec-00.txt.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of JC Dill Sent: March 12, 2003 8:37 PM To: nanog@merit.edu Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
It is offensive to many people (both male and female) when someone automatically assumes that an "unknown" person is male. Especially since: [snip] It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris?
I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree. I wonder if perhaps a solution would be doing something I saw a gentleman from China, IIRC, do on this list quite a while ago. He had added (Mr.) to his .sig to make it easy for people to figure out his gender. Perhaps this would be an easyish way to somewhat-subtly warn people of the correct gender? Vivien -- (Mr.) Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
From: "Vivien M."
I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree.
Is this a pick up list? Find the guy or gal of your dreams that can think too? I figure that you either earn people's respect or admiration or you don't. Mailing-list sex hasn't ever been an interest of mine. :) -Jack
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jack Bates Sent: March 12, 2003 9:29 PM To: nanog@merit.edu Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
From: "Vivien M."
I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree.
Is this a pick up list? Find the guy or gal of your dreams that can think too? I figure that you either earn people's respect or admiration or you don't. Mailing-list sex hasn't ever been an interest of mine. :)
Well, I've gotten [non-serious, I hope] marriage proposals from guys on Usenet before... I wouldn't go as far as Ms. Dill and saying it's offensive, but it is annoying that whenever you call some company and they look you up in their database, they say "ma'am" instead of "sir" (or, in Ms. Dill's case, presumably the opposite), and whenever you start posting in a new forum (Usenet, mailing list, etc), you inevitably have to correct the first person who refers to you with the wrong gender pronouns, etc, which is always embarassing for both you and the person who made the mistake... That said, this is getting horribly off-topic... though perhaps we should ask whether sex mailing lists are hosted on networks that filter 69/8? :) (Yes, I know, that wasn't a good attempt at being on topic...) Vivien -- (Mr.) Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
On Wed, 12 Mar 2003, JC Dill wrote:
It is offensive to many people (both male and female) when someone automatically assumes that an "unknown" person is male. Especially since:
Females aged 2 and up accounted for 50.4 percent of U.S. Internet users in May, edging out their male counterparts, according to New York-based Internet research firms Media Metrix and Jupiter Communications
[...]
At Dulles-based America Online Inc., the nation's biggest online services company, 52 percent of its 23.2 million subscribers worldwide are women.
[...]
Some scholars believe the new-found gender parity is just another reflection of the social changes of the past few decades, when men and women found themselves on more equal footing. "That distinction has disappeared, and it is a huge revolution in society," says Michael Maccoby, an anthropologist and psychoanalyst.
Got any statistics for the actual demographic in question (NANOG)? Probably not. But if you did, they'd support the assumption that an unknown person is likely male, with extreme statistical significance.
It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris?
Not be offended if somebody didn't know my gender?
p.s. Please don't cc me on replies, or on replies to replies, etc.
We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary.
I have no urgent need for your reply, I am happy to wait until I receive email from the list. I politely made my request very clear, both in my headers and in the body of my email. You responded by taking extra steps to do the exact opposite of what I politely requested. Then you have the gall to flame me for my polite request. This was very rude of you.
Well, as somebody who rudely runs a mailing list, you should be used to standard mailing list operating procedure.
If duplicate messages cluttering your inbox are causing you much grief,
They are just an annoyance, as is being mistakenly referred to as a male. Since you seem to think that these annoyances must be accepted as part of participating on the net, be prepared to be referred to as Miss Rothschild by me, now and in the future. What goes around comes around, girlfriend.
Except, you know he's male, and he didn't know you were female. So, you end up looking like a petty whiner who siezed upon the ability to be offended, even when there was no cause for it. Get over it. If my name was Andrea, I wouldn't be pissed if people assumed I was a woman. I'd correct them and move on. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Wed, 12 Mar 2003 21:27:51 EST, Andy Dills <andy@xecu.net> said:
Not be offended if somebody didn't know my gender?
Fortunately, none of the simians on the list have objected to being classified as 'banana eaters' ;)
It's probably harder for anyone on this list to take BandyRush seriously than the other posters in question. :-) Owen --On Wednesday, March 12, 2003 22:01 -0500 Valdis.Kletnieks@vt.edu wrote:
On Wed, 12 Mar 2003 21:27:51 EST, Andy Dills <andy@xecu.net> said:
Not be offended if somebody didn't know my gender?
Fortunately, none of the simians on the list have objected to being classified as 'banana eaters' ;)
Can you and he please take the gender debate off-list? Thanks, Owen --On Wednesday, March 12, 2003 17:36 -0800 JC Dill <nanog@vo.cnchost.com> wrote:
Miss Rothschild wrote:
On 2003-03-11-21:01:00, JC Dill <nanog@vo.cnchost.com> wrote:
(Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in)
Ahem. It's _MS._ Dill, thank you.
Please post with a gender-specific name if you want to take offense when mis-identified.
It is offensive to many people (both male and female) when someone automatically assumes that an "unknown" person is male. Especially since:
Females aged 2 and up accounted for 50.4 percent of U.S. Internet users in May, edging out their male counterparts, according to New York-based Internet research firms Media Metrix and Jupiter Communications
[...]
At Dulles-based America Online Inc., the nation's biggest online services company, 52 percent of its 23.2 million subscribers worldwide are women.
[...]
Some scholars believe the new-found gender parity is just another reflection of the social changes of the past few decades, when men and women found themselves on more equal footing. "That distinction has disappeared, and it is a huge revolution in society," says Michael Maccoby, an anthropologist and psychoanalyst.
<http://www.washingtonpost.com/ac2/wp-dyn/A137-2000Aug9?language=printer>
It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris?
Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed.
How do I configure my routers and web servers for that?
ObNanog: Assuming you don't work at Google, if you aren't blocking 69/8 then your network will not be harmed in any way by the implementation of this proposal. Thus you need to do nothing special at all. OTOH, if you are improperly blocking 69/8, obviously you need to fix that when you configure your "routers and web servers" (sic).
I'm suggesting that Google explain why they are doing this on a page linked off their homepage. If this is done, people ARE going to notice, and ARE going to find out why. When it is widely publicised, it WILL be noticed even more.
Last I checked, Google was a for-profit business, not a charity house. I'm not sure how doing something that will make them look dumb, and cost them in valuable ad revenue, etc is in their best interests. Perhaps you could fill me in here.
If you don't work at Google, then this is none of your concern.
p.s. Please don't cc me on replies, or on replies to replies, etc.
We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary.
I have no urgent need for your reply, I am happy to wait until I receive email from the list. I politely made my request very clear, both in my headers and in the body of my email. You responded by taking extra steps to do the exact opposite of what I politely requested. Then you have the gall to flame me for my polite request. This was very rude of you.
If duplicate messages cluttering your inbox are causing you much grief,
They are just an annoyance, as is being mistakenly referred to as a male. Since you seem to think that these annoyances must be accepted as part of participating on the net, be prepared to be referred to as Miss Rothschild by me, now and in the future. What goes around comes around, girlfriend.
jc
[1] JC Dill is my real name. It is the name on my passport and other official documents.
Thus spake "JC Dill" <nanog@vo.cnchost.com>
p.s. Please don't cc me on replies, or on replies to replies, etc. I get the list email just fine and I don't need more than one copy of any given email. Really.
1) nanog can sometimes take hours to forward posts to all members 2) the people directly involved in the thread reasonably expect to get responses immediately 3) seeing your name in the To/Cc line may attach greater importance to the message 4) duplicates can be automatically blocked by procmail with: :0 Wh:.msgid.cache.lock | formail -D 8192 .msgid.cache 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
JC Dill <nanog@vo.cnchost.com> wrote:
Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed.
With that in mind, perhaps IANA and ICANN can be persuaded to renumber into new space every time some is allocated? Or if you enjoy helpdesk staff abused by end users in their thousands, encourage the use of a .sex tld and house the root in new space. TT
On Tue, 11 Mar 2003 18:22:14 EST, Charles Sprickman said:
Hey, I already came up with the slashdot idea.
An excellent choice - the average slashdot reader would resent any implication that they were using a substandard clueless ISP, and would complain in a most vociferous manner.. ;)
* spork@inch.com (Charles Sprickman) [Wed 12 Mar 2003, 00:22 CET]:
Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block.
Apparently hack.co.za has recently been resurrected; it's within 69.3/16, owned by Cogent. (Fugly traceroute, too.) I'm sure they'll appreciate your offer of another mirror! Regards, -- Niels. -- subvertise me
On Tue, 11 Mar 2003, Randy Bush wrote:
Look, there's no quick fix solution here.
so let's see how much of a kludge we can make to show how clever we are.
Excellent point...but then, what to do? Have we given up and decided that addressing the 69/8 (and similar, future issues) is a social problem that can't be fixed via technical means? Are you ok with a solution of patiently waiting for some sort of critical mass to occur with each new /8 that gets allocated? Sooner or later, enough content will be in 69/8 (and other commonly filtered /8s) that people will be forced to fix their filters. But is that the only way? And would your answer change if you were one of the first networks to be assigned space in the new range? Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
From: "Andy Dills"
Are you ok with a solution of patiently waiting for some sort of critical mass to occur with each new /8 that gets allocated? Sooner or later, enough content will be in 69/8 (and other commonly filtered /8s) that people will be forced to fix their filters. But is that the only way?
And would your answer change if you were one of the first networks to be assigned space in the new range?
I might point out that it can even be worse. The IP addressing I was using belonged to a provider that I'd used for many, many years. They were pulling out and sending customers elsewhere, so I bit the bullet and pulled up the numbers to get my first ARIN assigned addresses. So now I have a /18 that will be at 90% utilization by the end of the month. I can't delay, as I can't request more IP addresses until I release the old networks back to the provider. In essence, I was just forced to screw all my customers. At the next meeting, might someone kindly mention to ARIN that "initial" requests, especially renumbers, should not be issued space that is less than a year off the bogon list? More than anything, this is what has pissed me off. After the renumber, I'll only have 69/8 space, which means all critical services such as my mail, dns, and web servers will all be affected. I hear it now. "I didn't receive mail from so and so!" I check the logs and don't see an established connection to my server. So, is the problem that the far mail server lost the message, the user emailed the wrong place, or my new IP addresses weren't accessible by the far mail server or the dns servers that it uses? In addition, sometimes the problem is that my user just needs to put the crack pipe down. I just don't feel comfortable with this last one anymore, though. I can't be sure it's the crack. It could be the IPs. How do I know? -Jack
In addition, sometimes the problem is that my user just needs to put the crack pipe down. I just don't feel comfortable with this last one anymore, though. I can't be sure it's the crack. It could be the IPs. How do I know?
I'm not a major router admin. I manage a couple dozen /24's and the supporting gear, but... It seems one purpose (perhaps remote) of bogon filters is security. Why not get someone like CERT to broadcast changes in allocations? I'd bet a cup of Dunkin' Donuts coffee that the news would quickly get to the "right" people. My $two_cents for very large values of $two_cents. (back to my hole) -ed ----------------- ed@the7thbeer.com
Thus spake "Jack Bates" <jbates@brightok.net>
After the renumber, I'll only have 69/8 space, which means all critical services such as my mail, dns, and web servers will all be affected. I hear it now. "I didn't receive mail from so and so!" I check the logs and don't see an established connection to my server. So, is the problem that the far mail server lost the message, the user emailed the wrong place, or my new IP addresses weren't accessible by the far mail server or the dns servers that it uses?
There's several BCPs that tell you to have at least one DNS server and at least one unfavorable MX off-site. If you did this, your mail would be safe, albeit a little slow from misconfigured sites. 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
participants (32)
-
Adam Rothschild -
Alan Hannan -
Alec H. Peterson -
Andy Dills -
Charles Sprickman -
Christopher L. Morrow -
Dorian Kim -
E.B. Dreger -
ed＠the7thbeer.com -
Frank Scalzo -
Greg Maxwell -
Haesu -
Iljitsch van Beijnum -
Jack Bates -
JC Dill -
jlewis＠lewis.org -
Joe Boyce -
Lars Erik Gullerud -
Michael K. Smith -
Niels Bakker -
Owen DeLong -
Peter E. Fry -
Randy Bush -
Richard A Steenbergen -
Rob Thomas -
Sean Donelan -
Stephen Sprunk -
tim.thorne＠btinternet.com -
Valdis.Kletnieks＠vt.edu -
Vivien M. -
william＠elan.net -
wireworks